Why ZooKeeper Is Not the Best Choice for Service Discovery: Design Considerations for a Registration Center

Based on more than ten years of Alibaba's production practice, the article revisits the evolution of internal service‑registration projects—from the 2008 "Five‑Color Stone" refactoring that birthed ConfigServer, through Yahoo's ZooKeeper adoption, to Dubbo's integration with ZooKeeper as a registration backbone.

It frames a registration center as a simple query function Si = F(service-name) , returning the list of available endpoints (ip:port) . Using CAP theory, the author argues that for service discovery the system should favor availability (A) over strong consistency (C), accepting eventual consistency because traffic can quickly converge within SLA limits.

Network‑partition scenarios are examined: when a data‑center becomes isolated, ZooKeeper may remain operational but writes become unavailable, breaking intra‑zone service calls—an unacceptable violation of the principle that a registry must never disrupt service connectivity. Hence the design should be AP‑oriented.

The necessity of persistent storage is questioned. While ZooKeeper logs every write (ZAB protocol), the real‑time address list of services does not require durability; however, metadata such as version, group, weight, and auth policies does, and must be persisted and searchable.

Health‑check mechanisms that rely solely on ZooKeeper session liveness and ephemeral nodes are critiqued. A robust registry should allow services to define custom health logic rather than a one‑size‑fits‑all TCP‑ping approach.

Disaster‑recovery considerations emphasize that client libraries must cache registry data (client snapshot) and operate with weak dependency on the registry, ensuring that service calls continue even if the registry is completely down.

Exception handling is highlighted as a major pain point. Developers must understand ZooKeeper's client/session state machine, handling recoverable errors like ConnectionLossException and non‑recoverable ones like SessionExpiredException , and design idempotent operations accordingly.

Alibaba maintains one of the world’s largest ZooKeeper clusters (nearly a thousand nodes) and a custom branch called TaoKeeper. The author concludes that ZooKeeper excels in coordination tasks for big‑data workloads (distributed locks, leader election) but is ill‑suited for high‑TPS service‑discovery and health‑monitoring scenarios.

Ultimately, the recommendation is to treat ZooKeeper as a coordination tool for big‑data, while designing registration centers that prioritize availability, tolerate inconsistency, and provide richer health‑check and disaster‑recovery capabilities.