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

01 Basic Concepts of Service Registries

1.1 What Is a Service Registry?

A service registry involves three roles:

Service Provider (RPC Server) : registers itself with the registry at startup and sends periodic heartbeats.

Service Consumer (RPC Client) : subscribes to services from the registry, caches the service node list locally, and connects to the providers.

Service Registry : stores registration information, synchronizes changes across nodes, and notifies clients to refresh their caches.

Clients select a provider from the cached list using a load‑balancing algorithm.

1.2 Functions Required by a Service Registry

The registry must implement registration, discovery, heartbeat monitoring, and client notification. (Diagram omitted.)

02 Service Registry Fundamentals

2.1 CAP Theory

CAP theory states that a distributed system can simultaneously guarantee at most two of the following:

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 to operate despite network partitions.

Choosing consistency first reduces availability, and vice‑versa; achieving all three is impossible.

2.2 Distributed System Protocols

Common consensus algorithms include Paxos, Raft, and ZooKeeper’s ZAB. Paxos requires a majority of replicas to be online; Raft simplifies Paxos for easier implementation; ZAB is a ZooKeeper‑specific adaptation of Paxos.

03 Common Service Registries

The five widely used registries are Zookeeper, Eureka, Nacos, Consul, and Etcd.

3.1 Zookeeper

Although not officially marketed as a registry, Zookeeper is often used as one in Dubbo‑based projects. It stores service nodes as znodes such as /HelloWorldService/1.0.0/100.19.20.01:16888 .

Zookeeper Implementation

Providers create a znode path /{service}/{version}/{ip:port} . Clients watch these paths; Zookeeper pushes an event type and node info (push), and the client pulls the actual change data (pull).

Why Zookeeper Is Not Ideal as a Registry

Zookeeper follows a CP model (strong consistency) which can lead to long leader election times (30‑120 s) and temporary unavailability—unacceptable for service discovery where high availability is paramount.

3.2 Eureka

Eureka Architecture

A simplified diagram shows peer‑to‑peer servers without a master/slave hierarchy.

Eureka Features

AP principle: high availability even if data is slightly stale.

Decentralized peer‑to‑peer architecture.

Automatic request switching on server failure.

Node‑level operation replication.

Automatic registration and heartbeat.

Self‑protection mode when many heartbeats are missed.

Eureka Workflow

Eureka Server starts and waits for service registration.

Clients register with the server.

Clients send heartbeats every 30 s.

If no heartbeat for 90 s, the server deregisters the instance.

Massive heartbeat loss triggers self‑protection.

Heartbeat recovery exits self‑protection.

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

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

Clients obtain target server info and invoke the service.

On shutdown, clients deregister themselves.

Eureka prioritizes availability (AP) and is suitable for multi‑data‑center scenarios.

3.3 Nacos

Nacos, an open‑source project from Alibaba, provides service discovery, health monitoring, dynamic configuration, and DNS services for cloud‑native applications.

Nacos Main Features

Service discovery & health checks (DNS & RPC based).

Dynamic configuration with UI, version tracking, canary release, and rollback.

Dynamic DNS with weighted routing and simple APIs.

Nacos supports both CP and AP modes, acting as both a service registry and a configuration center.

3.4 Consul

Consul by HashiCorp offers an all‑in‑one solution for service discovery, health checking, KV storage, and multi‑data‑center support.

Consul Call Process

Producer registers its IP and port via a POST request.

Consul performs health checks every 10 s.

Consumer retrieves the service address from Consul’s temporary table.

The table updates every 10 s, containing only healthy producers.

Consul Main Features

CP model using Raft for strong consistency.

KV store, health checks, multi‑data‑center support.

TLS certificate generation for secure communication.

HTTP and DNS APIs with a web UI.

Multi‑Data‑Center

Consul provides out‑of‑the‑box multi‑data‑center clusters; servers store data while clients handle health checks and request forwarding.

3.5 Etcd

Etcd is a Go‑based distributed key‑value store offering high availability and strong consistency via the Raft algorithm.

Etcd Features

Simple HTTP+JSON API.

Easy deployment across platforms.

Strong consistency (Raft).

High availability with fault tolerance.

Persistent storage via WAL and snapshots.

High write throughput (up to 10 K QPS).

Optional SSL client authentication.

gRPC, watch mechanism in v3.0.

Etcd Architecture

HTTP Server for API handling and inter‑node communication.

Store for transaction processing and state management.

Raft module implementing the consensus algorithm.

WAL for write‑ahead logging and persistence.

A client request passes through the HTTP Server to the Store; if the request modifies data, Raft ensures consensus before committing.

04 Comparison and Selection

4.1 Registry Comparison

Health‑check mechanisms differ (Eureka needs explicit config; Zookeeper/Etcd rely on connection loss; Consul offers detailed checks).

Multi‑data‑center support: Consul and Nacos provide it out of the box.

KV storage: All except Eureka support KV services.

CAP trade‑offs: Eureka (AP), Nacos (configurable), Zookeeper/Etcd/Consul (CP).

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

Metrics and monitoring are available in most solutions.

Spring Cloud integration via respective boot starters.

4.2 Selection Guidance

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

Match the registry’s implementation language to the project’s tech stack (Java‑based vs Go‑based).

All listed products offer high‑availability clustering options.

Consider community activity and ecosystem support.