Understanding Eureka: Service Registration and Discovery in Spring Cloud

Eureka Definition

Eureka is the service registry component of the Spring Cloud framework, comparable to Zookeeper in the Dubbo framework.

Eureka Functions

The main functions of Eureka are service registration and service discovery.

Service registration: a service provider registers its address with the registry.

Service discovery: a service consumer retrieves other services from the registry.

All services can register with Eureka by providing a service name; consumers then obtain the provider's real address from Eureka to invoke it.

Eureka Basic Architecture

The diagram shows that Eureka consists of three roles:

Service Provider: the side that exposes services.

Service Consumer: the side that calls remote services.

Eureka Server: the service registration and discovery center.

Eureka Operational Principles

1. Register Instance

When a service provider starts, it sends a request to the registry to register its instance.

2. Pull Services

Consumers pull the entire registry from the server and cache it locally; when a service is needed, they call it directly using the cached information.

3. Periodic Update

Consumers send heartbeats to the registry at intervals; the registry maintains a mapping of instances to addresses.

Eureka consumers pull the registry every 30 seconds, updating the local cache.

4. Self‑Protection

In unstable network conditions, if 85% of servers miss heartbeats within 15 seconds, the registry enters self‑protection mode, preserving all registration information and not deleting instances even after multiple missed heartbeats. The registry exits this mode automatically when heartbeats resume.

Eureka Workflow

The complete Eureka workflow consists of ten steps:

Eureka Server starts and waits for service registrations; if clustered, servers synchronize registries via Replicate.

Eureka Client starts and registers with the configured Eureka Server.

Eureka Client sends a heartbeat to the server every 30 seconds to indicate it is alive.

If the server does not receive a heartbeat from a client within 90 seconds, it deregisters that instance.

If many clients miss heartbeats (85% within 15 seconds), the server assumes a network issue and activates self‑protection.

When heartbeats resume, the server automatically exits self‑protection mode.

Clients periodically fetch the full or incremental registry and cache it locally.

When invoking a service, the client first checks the local cache; if missing, it refreshes the cache from the server before calling.

The client uses the retrieved server information to make the service call.

When the client shuts down, it sends a cancellation request, and the server removes the instance from the registry.

-end-