Comparison of Service Discovery Tools: Zookeeper, etcd, and Consul

The article provides a practical comparison of three widely used service discovery tools—Zookeeper, etcd, and Consul—focusing on their types (general vs. dedicated), consistency models (CP, AP, Raft, Paxos), supported languages, dependencies, and integration approaches.

ZooKeeper offers a rich set of features beyond service discovery, including configuration storage, naming, distributed synchronization, and group services. It requires a heavyweight client SDK, uses a watcher mechanism for real‑time updates, and relies on the Paxos algorithm for consistency, but lacks built‑in health checks and multi‑data‑center support.

etcd is a lightweight, HTTP‑based distributed key‑value store written in Go. It is often used as the backing store for Kubernetes service discovery but needs additional tools (e.g., Registrator, confd) to provide full discovery capabilities. It uses the Raft consensus algorithm, offers simple HTTP APIs, but does not include health checking or multi‑data‑center features.

Consul integrates common service‑discovery requirements out of the box: DNS/HTTP service lookup, health checking, KV store, and multi‑data‑center support. It operates via a local agent on each node, requires no SDK, and communicates through HTTP or DNS. Consul uses Raft for consistency and provides a web UI, though it lacks real‑time change notifications compared to ZooKeeper’s watcher.

The concluding table summarizes the advantages and disadvantages of each tool. The author recommends adopting Consul for future projects to support multiple data centers and various programming languages, while acknowledging the need to mitigate its less‑instantaneous service‑state updates.