Integrasi dengan Eureka/Consul

In a microservices architecture, services are often dynamic. They can scale up or down, and their network locations (IP addresses, ports) can change frequently.

Service discovery is a mechanism that helps applications and services find each other without needing to hardcode their network locations. It's like a dynamic phone book for your services!

A service registry is a central server that maintains a list of available service instances and their network locations.

• Netflix Eureka: A very popular choice, especially within the Spring Cloud ecosystem. Services register themselves with Eureka.
• HashiCorp Consul: Another robust option, offering service discovery along with a distributed key-value store and health checks.

Both allow services to register themselves and discover others.

Spring Cloud Gateway acts as the entry point to your microservices.

Instead of configuring routes with fixed URLs for each backend service, the Gateway can query a service registry:

• "Where is the 'user-service' running right now?"
• "Give me an available instance of 'product-service'."

This enables flexible, dynamic, and resilient routing, as the Gateway doesn't need to know service locations upfront.

First, let's look at how a simple Spring Boot service is configured to register itself with a Eureka server.

We'll use a service named hello-service. Its application.yml will point to the Eureka server's default zone.

To make our hello-service actually register with Eureka, we need to add the @EnableEurekaClient annotation to its main application class.

This annotation activates the Eureka Discovery Client functionality.

Now, let's configure our Spring Cloud Gateway to connect to the same Eureka server. The Gateway itself also acts as a Eureka client to discover other services.

Its application.yml will specify the Eureka server URL and its own application name.

Similar to the backend service, the Gateway's main application class needs an annotation to enable its discovery capabilities.

Use @EnableDiscoveryClient to tell Spring Boot to activate the discovery client for the Gateway.

With discovery enabled, we can define Gateway routes using a service's registered ID instead of a fixed URL.

The lb:// prefix (for 'load balancer') tells the Gateway to use its discovery client to find instances of the specified service name (e.g., hello-service) and then route the request.

Let's trace a request to http://localhost:8080/hello:

1. The Gateway (listening on port 8080) receives the request.
2. It matches the /hello/** path predicate to the hello_route.
3. The Gateway uses its Eureka client to look up an available instance of hello-service.
4. Eureka returns the address of an instance (e.g., localhost:8081).
5. The Gateway forwards the request to http://localhost:8081/hello.
6. The hello-service processes the request and returns a response, which the Gateway then sends back to the client.

While Eureka is widely used, Consul by HashiCorp is another powerful service discovery and configuration management tool.

To use Consul, you'd typically add the Spring Cloud Consul Discovery dependency and configure your Gateway/services to point to the Consul agent (usually running on port 8500).

The principle remains the same: the Gateway uses service IDs (e.g., lb://my-service) to dynamically discover and route to services registered in Consul.

In this lesson, you learned about:

• The importance of service discovery in dynamic microservice environments.
• How Eureka and Consul serve as central service registries.
• Configuring both backend services and Spring Cloud Gateway as discovery clients.
• Defining Gateway routes using service IDs (e.g., lb://service-name) for dynamic routing.

This integration is fundamental for building scalable and resilient microservice architectures. Next, we'll explore more dynamic routing rules and predicates.