Choosing a Service Registry: In‑Depth Comparison of Zookeeper, Eureka, Nacos, Consul, and Etcd

What Is a Service Registry?

A service registry plays three roles: the service provider registers its address and sends heartbeats, the service consumer subscribes to the registry and caches the address list, and the registry maintains the list and notifies consumers of changes.

Essential Functions of a Registry

The registry must support service registration, discovery, health checking, watch/notification mechanisms, and cluster management. (Illustrated in the accompanying diagram.)

CAP Theory Overview

Consistency, Availability, and Partition tolerance cannot all be achieved simultaneously. The article explains why choosing one property over another impacts registry design.

Prioritising consistency can degrade availability because data synchronization consumes time.

Prioritising availability may return stale data but keeps the service reachable.

Achieving both consistency and availability makes partition tolerance difficult.

Distributed Consensus Protocols

The article lists Paxos, Raft, and ZAB as the main algorithms. Paxos requires a majority of replicas to be online; Raft is a simplified, easier‑to‑implement version of Paxos; ZAB is a ZooKeeper‑specific protocol derived from Paxos.

Registry Implementations

Zookeeper

Although not marketed as a registry, Zookeeper is widely used in Dubbo‑based RPC systems. Providers create a znode such as /HelloWorldService/1.0.0/100.19.20.01:16888 for each instance. Consumers watch the parent path and receive lightweight change events, then pull the updated list.

Drawbacks: leader election can take 30–120 seconds, during which the whole cluster is unavailable; this makes Zookeeper a CP system (strong consistency, lower availability) and less suitable for pure service discovery.

Eureka

Eureka follows the AP principle: as long as one instance remains, the registry stays available, though data may be stale. It uses a peer‑to‑peer architecture without a master, supports automatic request failover, and replicates operations across peers.

Key behaviours include a 30‑second heartbeat interval, a default 90‑second lease expiration, and a self‑protection mode that suspends instance removal when >85 % of nodes miss heartbeats.

Nacos

Nacos, an Alibaba open‑source project, offers DNS‑ and RPC‑based service discovery, health monitoring, dynamic configuration, and weighted routing. It supports both CP and AP modes, provides a UI console, and integrates tightly with Spring Cloud.

Consul

Consul, from HashiCorp, provides a one‑stop solution: service registry, health checks, KV store, and multi‑data‑center support. It runs as a Go binary, uses the Raft algorithm (CP), and communicates via HTTP, DNS, and gRPC. Agents perform health checks every 10 seconds, and servers form a leader/follower cluster (recommended 3–5 nodes).

Etcd

Etcd is a Go‑based, highly available key‑value store that uses Raft for strong consistency. Features include HTTP+JSON API, watch mechanism, SSL authentication, and performance up to 10 K QPS writes. Its architecture consists of an HTTP server, a Store module, Raft, and a Write‑Ahead Log (WAL) with snapshot support.

Side‑by‑Side Comparison

Health checks: Eureka requires explicit configuration; Zookeeper/Etcd rely on lost connections; Consul offers detailed health metrics.

Multi‑data‑center support: Consul and Nacos provide native support; others need custom development.

KV storage: All except Eureka expose a KV API, enabling dynamic configuration.

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

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

Metrics: All except Zookeeper and Nacos expose built‑in metrics for monitoring.

Spring Cloud integration: Each has a corresponding boot starter.

Selection Guidance

When choosing a registry, consider:

CAP preference: If high availability is paramount, prefer AP solutions like Eureka or Nacos.

Technology stack: Go‑based projects may lean toward Etcd or Consul; Java‑centric ecosystems often use Zookeeper, Eureka, or Nacos.

High‑availability requirements: All listed products support HA clusters, but implementation details differ.

Community activity: All have active open‑source communities.

Ultimately, the author suggests picking the registry that reduces operational effort while matching the project's consistency/availability needs.