Understanding Eureka Registry: Client Fetch Process and Server-side Cache
This article explains how Eureka's service registry works, detailing the client’s initial full‑registry fetch during startup, the server’s two‑level caching strategy, and how both sides store and retrieve registration information for efficient service discovery.
Hello, I'm Wukong. This article continues the series on the Eureka registration center, summarizing previous posts and focusing on the client’s initial registry fetch and the server‑side cache mechanism.
The registry is crucial for service discovery; services obtain other services' IP and port from it. Traditional direct HTTP calls are replaced by a centralized registry.
When a Eureka client registers, the server stores the registry in a ConcurrentHashMap . To obtain other services' information, the client fetches the full registry during initialization.
Client fetch logic checks shouldFetchRegistry and whether the local registry is empty; if so, it calls fetchRegistry which ultimately invokes getAndStoreFullRegistry() and getApplications() via a Jersey REST call.
On the server side, the registry is cached in two levels: a read‑only cache and a read‑write cache. Requests first consult the read‑only cache, fall back to the read‑write cache, update the read‑only cache if found, or return null.
After fetching, the client stores the registry in its local localRegionApps variable for subsequent lookups.
In summary, the server uses multi‑level caching to serve registry queries efficiently, while the client performs a full fetch on first contact and keeps a local copy for fast access.
Wukong Talks Architecture
Explaining distributed systems and architecture through stories. Author of the "JVM Performance Tuning in Practice" column, open-source author of "Spring Cloud in Practice PassJava", and independently developed a PMP practice quiz mini-program.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.