Choosing the Right Service Registry: Zookeeper, Eureka, Nacos, Consul, and Etcd Compared

01 Registry Basic Concepts

The registry has three roles: service provider (RPC Server) registers itself and sends heartbeats; service consumer (RPC Client) subscribes to services and caches the node list; registry stores provider info and synchronizes changes to consumers.

Clients select a provider from the local cache using load‑balancing algorithms.

1.2 Functions a Registry Must Implement

Key functions include service registration, heartbeat, health check, watch/notification, and client cache update.

02 Registry Fundamentals

2.1 CAP Theory

CAP consists of Consistency, Availability, and Partition tolerance. In practice only two can be guaranteed simultaneously.

Consistency: all nodes see the same data at the same time.

Availability: every request receives a response, success or failure.

Partition tolerance: the system continues operating despite network partitions.

Choosing C over A degrades performance due to synchronization; choosing A over C sacrifices strong consistency; satisfying both C and A makes partition tolerance hard.

2.2 Distributed System Protocols

Common consensus algorithms are Paxos, Raft, and ZAB (ZooKeeper Atomic Broadcast). Paxos requires a majority of replicas to be online; Raft simplifies Paxos for easier implementation; ZAB is a ZooKeeper‑specific protocol built on Paxos concepts.

03 Common Registries

3.1 Zookeeper

Although not officially a registry, Zookeeper is widely used for service registration in Dubbo environments. Providers create znodes like /service/version/ip:port. Consumers watch these paths; Zookeeper sends lightweight change events (push) and clients pull the updated data.

Zookeeper follows a CP model: strong consistency is guaranteed, but availability can suffer during leader election (30‑120 s), which is problematic for service discovery.

3.2 Eureka

Eureka adopts an AP model and a peer‑to‑peer architecture without a master. It provides automatic registration, heartbeat, self‑protection, and client‑side caching.

Workflow:

Eureka Server starts and waits for registrations.

Clients register their services.

Clients send heartbeats every 30 s.

If no heartbeat for 90 s, the instance is deregistered.

During massive heartbeat loss, the server enters self‑protection mode.

When heartbeats resume, self‑protection is disabled.

Clients periodically refresh the registry cache.

Service calls first use the local cache, falling back to the registry if needed.

Clients deregister on shutdown.

Eureka favors availability (AP) and is suitable for multi‑datacenter, high‑availability scenarios.

3.3 Nacos

Nacos, an Alibaba open‑source project, supports both DNS‑based and RPC‑based service discovery, health monitoring, dynamic configuration, and can operate in CP or AP mode.

Key features: unified health checks, real‑time configuration updates, dynamic DNS routing, and a UI for management. In short, Nacos = Spring Cloud registry + Spring Cloud config.

3.4 Consul

Consul provides a one‑stop solution for service discovery, KV storage, health checks, and multi‑datacenter support. It uses the Raft algorithm (CP) and offers TLS‑based secure communication.

Clients register via HTTP POST; Consul performs periodic health checks and maintains a temporary table of healthy instances for consumers.

3.5 Etcd

Etcd is a Go‑based distributed key‑value store that uses the Raft algorithm to guarantee strong consistency. It offers HTTP+JSON APIs, high write throughput (up to 10 K QPS), persistence via WAL and snapshots, optional SSL authentication, and a watch mechanism.

04 Registry Comparison & Selection

4.1 Comparison

Key comparison points:

Health checks: Eureka requires explicit config; Zookeeper/Etcd rely on connection loss; Consul provides detailed metrics.

Multi‑datacenter: Consul and Nacos support it out of the box.

KV store: All except Eureka expose KV services.

CAP trade‑offs: Eureka (AP) and Nacos (configurable) prioritize availability; Zookeeper, Etcd, Consul (CP) prioritize consistency.

Watch support: Zookeeper pushes changes; others use long‑polling.

Metrics: Most provide built‑in monitoring.

Spring Cloud integration: All have corresponding boot starters.

4.2 Selection Guidance

Prefer AP (Eureka, Nacos) when high availability outweighs strict consistency.

Match the registry language to your tech stack (Java‑centric: Zookeeper, Eureka, Nacos; Go‑centric: Etcd, Consul).

Consider HA clustering features, community activity, and operational complexity.