La URI lb:// y el localizador de descubrimiento

Hardcoding http://10.0.0.5:8080 breaks when instances move. With service discovery the gateway can target a logical service name instead, and resolve real instances at runtime.

Prefix a route's uri with lb:// followed by the service id. The gateway hands the request to the load balancer, which picks a live instance.

At request time the gateway asks the discovery client (Eureka, Consul, etc.) for instances of order-service, then Spring Cloud LoadBalancer selects one. The lb:// host is replaced by a concrete address.

You need a discovery client and the load balancer on the classpath. With Eureka:

Instead of writing a route per service, enable the DiscoveryClient route locator. It auto-generates a route for every registered service.

By default each service is reachable at /SERVICE-ID/**. A service named order-service answers at /order-service/**, forwarded as lb://order-service.

Eureka often registers service ids in uppercase. Enable lowercasing so paths stay clean and predictable.

You can keep the discovery locator on for convenience while still defining explicit routes for services that need custom predicates or filters.

The locator exposes every service automatically, including internal ones. In production, many teams disable it and define routes explicitly for tighter control.

Because resolution happens per request, instances that deregister or fail health checks are dropped from the pool. New instances appear automatically as they register.

Enable debug logging for the load balancer to see which instance each request was routed to.

What does the lb:// prefix on a route's URI tell the gateway to do?

You connected the gateway to service discovery:

• lb://service-id resolves instances dynamically
• A discovery client and load balancer must be present
• The discovery locator auto-creates routes at /service-id/**
• Disable or scope it in production for safety

This is the backbone of dynamic, resilient routing.