Service Registry Showdown: Zookeeper, Eureka, Nacos, Consul & ETCD

Basic Concepts of Service Registry

Service registries have three main roles: service providers (RPC servers) register themselves and send heartbeats; service consumers (RPC clients) subscribe to services and cache the service list locally; the registry stores registration information and synchronizes changes to clients.

Clients select a service instance based on load‑balancing algorithms.

Functions a Registry Must Implement

Key functions include service registration, discovery, health checking, watch/notification, and load‑balancing support.

Service Registry Basics

This section is optional for readers already familiar with the topic.

CAP Theory

CAP theory describes the trade‑offs among Consistency, Availability, and Partition tolerance in distributed systems.

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.

Only two of the three can be fully achieved simultaneously.

Distributed System Protocols

Common consensus algorithms include Paxos, Raft, and ZAB.

Raft is a simplified, easier‑to‑understand version of Paxos and is used by etcd and Kubernetes.

ZAB is ZooKeeper’s atomic broadcast protocol, derived from Paxos but tailored for ZooKeeper.

Common Service Registries

Zookeeper

Although not officially marketed as a registry, Zookeeper is widely used in Dubbo for service registration.

It stores service information as znodes, e.g., /HelloWorldService/1.0.0/100.19.20.01:16888.

Clients watch paths for changes and pull updated data, implementing a push‑pull model.

Zookeeper Not Ideal for Service Discovery

Zookeeper prioritizes strong consistency (CP) and can suffer long leader election times (30‑120 s), making it less suitable for high‑availability service discovery where availability outweighs consistency.

Eureka

Key Features

AP design: high availability, tolerates stale data.

Peer‑to‑peer architecture without a master.

Automatic request failover and self‑protection mode.

Heartbeat‑based instance expiration.

Workflow

Eureka Server starts and waits for service registration.

Clients register with the server.

Clients send heartbeats every 30 s.

Missing heartbeats for 90 s cause deregistration.

Excessive missed heartbeats trigger self‑protection.

Clients cache service data locally and refresh as needed.

Eureka sacrifices strong consistency for availability, making it suitable for multi‑datacenter scenarios.

Nacos

Content excerpted from the Nacos official documentation.

Nacos provides service discovery, health monitoring, dynamic configuration, and DNS‑based routing.

Supports both CP and AP modes.

Combines service registry and configuration center functionalities.

Consul

Consul is an all‑in‑one solution offering service discovery, health checks, KV store, multi‑datacenter support, and TLS‑based secure communication.

CP model using Raft for strong consistency.

Supports both HTTP and DNS APIs.

Multi‑Data‑Center Architecture

Consul clusters can span multiple data centers, with servers handling data replication and clients performing health checks.

ETCD

ETCD is a Go‑based distributed key‑value store that provides strong consistency via the Raft algorithm.

HTTP+JSON API, easy deployment.

High availability and fast write performance.

Supports watch mechanisms and gRPC.

Its architecture consists of an HTTP server, a store layer, the Raft consensus module, and a Write‑Ahead Log (WAL) for persistence.

Registry Comparison & Selection

Comparison

Health checks: Eureka requires explicit config; Zookeeper/ETCD rely on connection loss; Consul offers detailed checks.

Multi‑data‑center support: Consul and Nacos support it natively; others need extra work.

KV storage: All except Eureka provide KV services.

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

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

Selection Guidance

Prefer AP (Eureka, Nacos) when availability is critical.

Consider technology stack: Go‑based (ETCD, Consul) vs Java‑based (Eureka, Nacos, Zookeeper).

All listed solutions have active open‑source communities and high‑availability clustering options.