Java: What is Service Discovery?

Service Discovery — a mechanism that allows services to dynamically find and communicate with each other without hardcoded network locations. In a microservices environment where instances are created and destroyed dynamically, service discovery is essential.

System Design Context: In traditional architectures, service URLs were static and configured in properties files. With auto-scaling, container orchestration, and rolling deployments, service instances have dynamic IPs and ports. Service discovery solves this by maintaining a registry of available instances.

Why Service Discovery is Needed:

• Services have dynamic IPs and ports — containers get new IPs on restart.
• Auto-scaling changes the number of instances continuously.
• Rolling deployments replace instances one at a time.
• Manual configuration is error-prone and doesn't scale.
• Load balancing requires knowing all available instances.

Discovery Patterns:

• Client-Side Discovery — client queries the registry and picks an instance (Eureka, Consul).
• Server-Side Discovery — a load balancer queries the registry and routes traffic (Kubernetes Services, AWS ELB).

Eureka (Netflix OSS) — Production Setup:

1// Eureka Server
2@SpringBootApplication
3@EnableEurekaServer
4public class EurekaServerApp {
5    public static void main(String[] args) {
6        SpringApplication.run(EurekaServerApp.class, args);
7    }
8}
9
10// application.yml for Eureka Server
11// server:
12//   port: 8761
13// eureka:
14//   instance:
15//     hostname: eureka-server
16//   client:
17//     register-with-eureka: false
18//     fetch-registry: false
19//   server:
20//     eviction-interval-timer-in-ms: 60000
21
22// Eureka Client (Service)
23@SpringBootApplication
24@EnableDiscoveryClient
25public class UserServiceApp {
26    public static void main(String[] args) {
27        SpringApplication.run(UserServiceApp.class, args);
28    }
29}
30
31// application.yml for Eureka Client
32// spring:
33//   application:
34//     name: user-service
35// eureka:
36//   client:
37//     service-url:
38//       defaultZone: http://localhost:8761/eureka/
39//   instance:
40//     prefer-ip-address: true
41//     lease-renewal-interval-in-seconds: 30
42//     lease-expiration-duration-in-seconds: 90
43
44// Consuming discovered services
45@Service
46public class OrderService {
47    @Autowired private RestTemplate restTemplate;
48
49    public User getUser(Long userId) {
50        // "user-service" is resolved via Eureka
51        return restTemplate.getForObject(
52            "http://user-service/api/users/{id}", User.class, userId);
53    }
54}

Alternatives:

• Consul — HashiCorp, supports health checks, KV store.
• ZooKeeper — Apache, strong consistency (CP).
• Kubernetes DNS — built-in service discovery in K8s.
• etcd — distributed KV store used by Kubernetes.

Production Configuration:

• Health checks — services must report liveness and readiness.
• Lease duration — how long an instance stays registered without renewal.
• Eviction interval — how often the server removes dead instances.
• Self-preservation mode — Eureka stops evicting instances if too many are lost (network partition protection).

Common Pitfalls:

• Stale registrations — service crashes but registry still has it. Fix: aggressive health checks, short lease times.
• Split brain — multiple Eureka servers with network partition. Fix: peer awareness, proper quorum.
• DNS caching — clients cache resolved IPs. Fix: use service names, not IPs.

Monitoring:

• Track registered instance count vs expected count.
• Monitor heartbeat failure rate.
• Alert on service deregistration storms (mass evictions).
• Dashboard: Eureka Admin, Consul UI.

Benefits:

• Dynamic scaling without configuration changes.
• Load balancing across instances.
• Fault tolerance — dead instances are automatically removed.
• Zero-downtime deployments.