Unravel › Java concepts › Cloud and operations
Service discovery and central config (Spring Cloud)
In a microservice system, instances start and stop all the time.
Learn these first
At a glance
A company phone directory.
- 1Each service registers its name and address with a registry (Eureka, Consul, Kubernetes) on start and sends heartbeatsA call to http://inventory/stock is resolved to one live instance.
- 2@LoadBalanced on a RestTemplate or WebClient.Builder makes it understand service names and spread calls over instances (client-side load balancing)
- 3A Config Server (@EnableConfigServer) serves application.yml files from a Git repository, by application name and profileClients load them at startup via spring.config.import.
- 4@RefreshScope beans are rebuilt when /actuator/refresh is called, so changed properties apply without restart
- On Kubernetes, the platform already gives you service discovery (DNS) and config (ConfigMaps and Secrets)
- Registries are eventually consistent: a stopped instance can remain listed until its lease expires, so clients need retries and timeouts rather than assuming a resolved address is alive
- The client library runs a background thread that fetches the registry (a cached snapshot) every 30 seconds and sends a renewal lease every 30 seconds
@Configurationpublic class ClientConfig { @Bean @LoadBalanced public RestTemplate restTemplate() { return new RestTemplate(); }}String stock = restTemplate.getForObject("http://inventory-service/stock/" + sku, String.class);- line 4 uses LoadBalanced, the core of Service discovery and central config (Spring Cloud)
Read the full explanation (about 2 min)
In a microservice system, instances start and stop all the time. A registry lets services find each other by name instead of by address, and a config server hands out shared settings that can change without redeploying.
A mental model
A company phone directory. You look up "billing" instead of memorising a desk number, and when billing moves offices the directory is updated, not every colleague.
How it works
Each service registers its name and address with a registry (Eureka, Consul, Kubernetes) on start and sends heartbeats. A call to http://inventory/stock is resolved to one live instance.
@LoadBalanced on a RestTemplate or WebClient.Builder makes it understand service names and spread calls over instances (client-side load balancing).
A Config Server (@EnableConfigServer) serves application.yml files from a Git repository, by application name and profile. Clients load them at startup via spring.config.import.
@RefreshScope beans are rebuilt when /actuator/refresh is called, so changed properties apply without restart.
Going deeper
On Kubernetes, the platform already gives you service discovery (DNS) and config (ConfigMaps and Secrets). Adding Eureka and a Config Server on top is often unnecessary complexity.
Registries are eventually consistent: a stopped instance can remain listed until its lease expires, so clients need retries and timeouts rather than assuming a resolved address is alive.
Never keep secrets in plain config repositories; use encryption or a secret manager, and secure the config server like the keys to the building.
Under the hood
The client library runs a background thread that fetches the registry (a cached snapshot) every 30 seconds and sends a renewal lease every 30 seconds. The load balancer picks from that local cache with round-robin or a configured algorithm, so lookups never call the registry on the request path.
Common mistakes
- Hard-coding host names in a system that has discovery.
- No retry or timeout for stale registry entries.
- Secrets in a plain Git config repo.
- Refreshing beans that hold open connections without cleanup.
How Unravel recognises it
When you paste code, Unravel looks for these signs of service discovery and central config (spring cloud). Spotting them yourself is a good habit when you read unfamiliar code:
- Annotations:
@EnableDiscoveryClient@EnableEurekaClient@EnableEurekaServer@EnableConfigServer@RefreshScope@LoadBalanced@LoadBalancerClient - Types:
DiscoveryClientLoadBalancerClientServiceInstanceEurekaClientReactorLoadBalancerExchangeFilterFunctionRefreshEndpointConfigServicePropertySourceLocatorServiceInstanceListSupplier
Part of a learning path
- Cloud-native Java · previous: Structured logging and correlation ids (MDC) · next: API gateways (Spring Cloud Gateway)
Related concepts
Frequently asked questions
What is Service discovery and central config (Spring Cloud)?
In a microservice system, instances start and stop all the time. A registry lets services find each other by name instead of by address, and a config server hands out shared settings that can change without redeploying.
What are the most common mistakes with Service discovery and central config (Spring Cloud)?
Hard-coding host names in a system that has discovery. No retry or timeout for stale registry entries. Secrets in a plain Git config repo. Refreshing beans that hold open connections without cleanup.
How can I see Service discovery and central config (Spring Cloud) in real code?
Paste your own Java into Unravel and it will point out where service discovery and central config (spring cloud) appears, explain how it works at the detail level you choose, and draw the flow of the code around it.