How Eureka Powers Service Discovery in Spring Cloud: Core Concepts Explained

Eureka Working Principle

We explore Eureka to understand its core concepts and workflow.

Eureka Core Concepts

Eureka consists of two main roles: the Eureka Server (the registry) and the Eureka Client (service providers and consumers).

Eureka Server: Registry Service

The server provides three main functions:

Service registration

Providing the registry

Synchronizing status

When a service provider starts, its Eureka Client registers metadata (IP, port, health‑check URL, etc.) with the server, which stores the information in a two‑level cache.

Clients retrieve the latest registry from the server if they lack a cached copy.

Clients keep their status synchronized with the server via registration and heartbeat mechanisms.

Eureka Client: Registry Client

The Java client simplifies interaction with the server, pulling, updating, and caching registry data. If all server nodes fail, the client can still use its cache, though updates may become inconsistent.

Register: Service Registration

Providers register themselves (as Eureka Clients) by sending metadata such as IP, port, health‑check URL, and homepage to the server.

Renew: Service Renewal

Clients send a heartbeat every 30 seconds. If the server does not receive a heartbeat within 90 seconds (default), it removes the instance from the registry.

# Service renewal task interval (default 30 seconds)
eureka.instance.lease-renewal-interval-in-seconds=30

# Service expiration time (default 90 seconds)
eureka.instance.lease-expiration-duration-in-seconds=90

Eviction: Service Removal

If a client stops sending heartbeats, the server evicts the instance from the registry.

Cancel: Service Deregistration

When a client shuts down, it sends a cancel request to remove its instance from the registry.

DiscoveryManager.getInstance().shutdownComponent();

GetRegistry: Fetching Registry Information

Clients pull the registry (default every 30 seconds) and cache it locally. The registry can be exchanged in JSON or XML, with JSON compression enabled by default.

# Enable fetching registry for consumers
eureka.client.fetch-registry=true

# Registry fetch interval (seconds)
eureka.client.registry-fetch-interval-seconds=30

Self‑Protection Mechanism

If the server does not receive heartbeats from many instances within 90 seconds, it assumes a network issue and enters self‑protection, stopping instance eviction while still accepting new registrations.

Self‑protection can be toggled:

eureka.server.enable-self-preservation=true

Eureka Cluster Principle

A cluster of three Eureka Servers (e.g., in Beijing, Shenzhen, and Xi’an) forms a high‑availability setup. Nodes replicate data peer‑to‑peer without a master‑slave distinction, and each node also acts as a client.

If a node fails, clients automatically switch to another node; when the failed node recovers, it rejoins the cluster.

Eureka Partition

Eureka supports Region (geographic area) and Zone (specific data center within a region) to prioritize local communication.

Eureka Guarantees AP

The system favors availability over strong consistency: as long as at least one node is alive, registration and lookup remain functional, though data may be slightly stale.

Eureka Workflow

Eureka Server starts and awaits registrations; cluster nodes replicate registries.

Eureka Clients register with the configured server.

Clients send heartbeats every 30 seconds.

If no heartbeat is received within 90 seconds, the server evicts the instance.

Massive heartbeat loss triggers self‑protection, preventing eviction.

When heartbeats resume, the server exits self‑protection.

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

Service calls first consult the local cache; if missing, the client refreshes from the server.

The client uses the retrieved instance information to invoke the target service.

On shutdown, the client sends a cancel request, and the server removes the instance.

Summary

The article covered Eureka's core concepts, self‑protection mechanism, and clustering principles, demonstrating how its design ensures high availability and tolerates non‑strong consistency, making it suitable for multi‑region microservice architectures.