What is Netflix Eureka, and what do @EnableEurekaServer and @EnableEurekaClient do?
answer
- registry = name -> live instances
- server annotation vs client starter
- @EnableEurekaClient (Eureka) vs @EnableDiscoveryClient (portable)
- app name is the lookup key
- annotations optional since starter auto-configures
basics
~20 sEureka is a service registry: services register themselves so others can find them by name instead of a hardcoded address. @EnableEurekaServer starts the registry server; @EnableEurekaClient makes an app register with and query that registry.
solid answer
~40 sEureka (from Spring Cloud Netflix) is a service-discovery registry. Instead of hardcoding host:port, each service registers itself under a logical name and looks others up by that name, which enables dynamic scaling and location transparency. @EnableEurekaServer, on a Spring Boot app with the eureka-server starter, turns it into the registry that holds the list of all instances. @EnableEurekaClient (or the generic @EnableDiscoveryClient) marks a service as a client: on startup it registers its own instance (app name, IP, port, health URL) with the server and periodically fetches the registry so it can resolve other services. In modern Spring Cloud the annotation is optional — just having the Eureka client starter on the classpath auto-configures registration and discovery.
code
java · 26 lines// --- Registry server ---
@SpringBootApplication
@EnableEurekaServer
public class RegistryApplication {
public static void main(String[] args) {
SpringApplication.run(RegistryApplication.class, args);
}
}
// application.yml (server)
// server.port: 8761
// eureka.client.register-with-eureka: false
// eureka.client.fetch-registry: false
// --- A service that registers ---
@SpringBootApplication
@EnableDiscoveryClient // portable; @EnableEurekaClient also works, and even this is optional
public class PaymentServiceApplication {
public static void main(String[] args) {
SpringApplication.run(PaymentServiceApplication.class, args);
}
}
// application.yml (client)
// spring.application.name: payment-service <-- the discovery key
// eureka.client.service-url.defaultZone: http://localhost:8761/eureka/go deeper
Know Eureka is a phone book of services; server vs client roles; app name is the key.
Explain that annotations are optional (starter auto-configures) and the difference between @EnableEurekaClient and @EnableDiscoveryClient.
Tie discovery to client-side load balancing and standalone/HA server config (register-with-eureka/fetch-registry).
Discuss when Eureka is redundant (Kubernetes native discovery) and the operational cost of running/maintaining a registry cluster.
## The problem Eureka solves In a microservice system, service A must call service B. Hardcoding B's `host:port` breaks the moment B scales out, moves, or restarts on a new port (common in containers/cloud). **Service discovery** replaces fixed addresses with a logical name (e.g. `payment-service`) resolved at runtime. **Netflix Eureka** is the registry that Spring Cloud Netflix wraps. ## Two roles - **Eureka Server** — the registry itself: an in-memory map of `service name -> list of live instances`. You create it by putting `spring-cloud-starter-netflix-eureka-server` on the classpath and annotating the main class with **`@EnableEurekaServer`**. - **Eureka Client** — any service that registers with and/or queries the server. You add `spring-cloud-starter-netflix-eureka-client`. Historically you annotated with **`@EnableEurekaClient`** (Eureka-specific) or **`@EnableDiscoveryClient`** (discovery-implementation-agnostic — works for Eureka, Consul, Zookeeper). ## The annotations are largely optional now Since Spring Cloud Greenwich, **auto-configuration activates purely from the client starter being on the classpath** — you don't strictly need `@EnableEurekaClient`/`@EnableDiscoveryClient`. They remain as explicit intent/documentation. `@EnableEurekaClient` is Eureka-specific; `@EnableDiscoveryClient` is the portable choice. ## What registration carries When a client registers it sends an **instance** descriptor: the **application name** (`spring.application.name`, used as the lookup key, uppercased as VIP), an **instance id**, **IP/hostname and port**, a **health-check/status URL**, and arbitrary **metadata**. Consumers fetch this list and pick an instance (usually via a client-side load balancer like Spring Cloud LoadBalancer). ## Typical config ```yaml eureka: client: service-url: defaultZone: http://localhost:8761/eureka/ ``` The server itself is just a Boot app on port 8761 (by convention) that usually sets `register-with-eureka: false` and `fetch-registry: false` for a standalone node. ## Gotchas - The **app name** (not the instance id) is the discovery key; two instances of the same service share one name. - A bare Eureka server is still a Eureka client of itself by default — disable self-registration for standalone dev, or point peers at each other for HA. - `@EnableEurekaServer` and the client starter are different dependencies; don't confuse them. ## When to use Use Eureka when you run multiple, dynamically-scaled service instances and want name-based, client-side load-balanced calls without an external DNS/load-balancer per service. For pure Kubernetes deployments, native K8s DNS/Services often replace Eureka.
- What is the difference between @EnableEurekaClient and @EnableDiscoveryClient?@EnableEurekaClient is Eureka-specific; @EnableDiscoveryClient is discovery-implementation-agnostic (Eureka, Consul, Zookeeper). Both are largely optional today because the client starter auto-configures registration/discovery — the difference is really about portability of intent.
- How does a consumer actually call a service by name?It resolves the name against the client's cached registry, then a client-side load balancer (Spring Cloud LoadBalancer, formerly Ribbon) picks an instance. With a load-balanced RestTemplate/WebClient or an OpenFeign client you just use http://payment-service/... and the name is expanded to a real address.