Week 17: Spring Cloud Microservices — Config Server, Eureka & Gateway

1. Centralized Config with Spring Cloud Config Server

With two services, each keeping its own application.properties per environment is manageable. With ten services and three environments, that's thirty separate config files to keep consistent — and a shared value (a database URL, a feature flag) that changes means editing every copy individually and hoping none were missed. Config Server centralizes this: one Git repository holds every service's configuration, and each service fetches its own config from the server at startup.

server:
  port: 8888
spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/acme/config-repo
          default-label: main

spring:
  datasource:
    url: jdbc:postgresql://prod-db:5432/tasks
resilience4j:
  circuitbreaker:
    instances:
      inventoryService:
        failureRateThreshold: 50

spring:
  application:
    name: task-service       # matches config-repo/task-service.yml
  config:
    import: "configserver:http://localhost:8888"

spring.application.name is the join key — Config Server serves task-service.yml specifically to the service that identifies itself as task-service, and a different file to every other registered service name. Because the backing store is a Git repository, every configuration change has full history, blame, and review through an ordinary pull request — the same audit trail Week 17's DevOps counterpart gets from Terraform's version control.

2. Service Discovery with Eureka

Week 9's RestClient calls used a hardcoded base URL for the downstream service. That breaks down once a service runs as multiple, dynamically-scaled instances with changing addresses — exactly the world Week 12's Kubernetes Deployments already live in, solved there by a Kubernetes Service. Eureka solves the same problem for Spring Cloud microservices directly: a registry where every service instance registers itself on startup and periodically confirms it's still alive.

server:
  port: 8761
eureka:
  client:
    register-with-eureka: false   # the server doesn't register with itself
    fetch-registry: false

spring:
  application:
    name: task-service
eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka

With both sides configured, a caller no longer needs a hardcoded URL at all — it asks Eureka for an instance of task-service by name, and Eureka returns a currently-healthy address:

@Bean
@LoadBalanced   // resolves "http://task-service" via Eureka, not DNS
RestClient.Builder loadBalancedRestClientBuilder() {
    return RestClient.builder();
}

// elsewhere
RestClient client = loadBalancedRestClientBuilder.baseUrl("http://task-service").build();
TaskResponse task = client.get().uri("/api/tasks/{id}", id)
    .retrieve().body(TaskResponse.class);

@LoadBalanced is what makes http://task-service resolve at all — without it, that's not a real hostname and the call fails outright. With it, every request is transparently routed to one of the currently-registered, healthy task-service instances, load-balanced across however many are running — the calling code never needs to change as instances scale up, scale down, or move.

3. Spring Cloud Gateway

With several services running, exposing each one's port directly to the outside world is both a security problem and an unpleasant API surface for external clients to navigate. Spring Cloud Gateway sits in front of every service as a single entry point, routing incoming requests to the right backend based on the request path — the same role Week 15's Kubernetes Ingress plays, implemented in the application layer instead of the cluster's networking layer.

spring:
  cloud:
    gateway:
      routes:
        - id: task-service
          uri: lb://task-service          # "lb" = load-balanced via Eureka
          predicates:
            - Path=/api/tasks/**
          filters:
            - StripPrefix=0
        - id: inventory-service
          uri: lb://inventory-service
          predicates:
            - Path=/api/inventory/**

lb://task-service combines both this section and the last: the lb scheme tells the Gateway to resolve task-service through Eureka and load-balance across its instances, exactly like the @LoadBalanced RestClient from Section 2 — routing and discovery composing together rather than being two unrelated concerns.

A Gateway is also the natural place to apply cross-cutting concerns once, instead of duplicating them in every service — Week 16's rate limiting, request logging, and authentication token validation can all live as Gateway filters that apply uniformly to every route, rather than being reimplemented per service.

4. Hands-on Exercise

5. Knowledge Check

Three quick questions. Expand each to check your answer.