Choosing the Right Service Discovery: ZooKeeper vs Eureka vs Nacos

Core Component Deep Dive

ZooKeeper

Positioning : Distributed coordination service, the open‑source implementation of Google Chubby.

Core Model : Based on the ZAB protocol, a CP system.

Applicable Scenarios

Distributed lock : Classic implementation.

Leader election : Selecting a master among service instances.

Cluster management : Keeping node up/down status consistent.

Metadata storage : Storing a small amount of strongly consistent data.

Naming service : Unified name registration.

Features

Strong consistency (C) : Data is always the latest.

Availability sacrifice (A) : May reject writes during network partitions.

Ephemeral nodes : Auto‑deleted when client disconnects, ideal for registration/discovery.

Watch mechanism : Listens to node changes for event notification.

Issues in Service Discovery

When network jitter or split‑brain occurs, ZooKeeper may misjudge a node as dead to preserve consistency, causing health instances to be deregistered and reducing availability, which conflicts with the microservice principle of "availability first"; therefore it is not recommended as a direct registration center.

Eureka

Positioning : Netflix's open‑source service discovery component, designed for microservice architectures.

Core Model : AP system.

Applicable Scenarios

Pure service registration and discovery.

Systems with high fault‑tolerance and availability requirements.

Features

High availability (A) & partition tolerance (P) : Returns stale data instead of rejecting requests.

Client cache : Services remain callable even if the server crashes.

Self‑protection : Prevents accidental instance removal during network anomalies.

Weak consistency : Registration info is asynchronously replicated, causing short delays.

Limitations

Single function – only service discovery.

Official updates stopped at version 2.0 (1.x remains stable).

No configuration management or UI capabilities.

Nacos

Positioning : Alibaba's open‑source dynamic service discovery, configuration and service management platform.

Core Model : Supports both AP and CP modes.

Applicable Scenarios

Service registration & discovery (alternative to Eureka).

Dynamic configuration center (alternative to Spring Cloud Config).

Service metadata & traffic governance.

Multi‑environment isolation (Namespace + Group).

Features

Dual‑mode :

Service discovery defaults to AP mode.

Configuration module can switch to CP mode (Raft).

Mode can be changed dynamically via command.

All‑in‑one : One component solves registration and configuration.

Eco‑friendly : Seamlessly compatible with Spring Cloud, Dubbo, K8s; UI is user‑friendly.

Dynamic config refresh : Supports push, gray release and rollback.

Comparison and Selection in the Spring Cloud Ecosystem

Consistency protocol : ZooKeeper – CP (ZAB); Eureka – AP (custom); Nacos – AP + CP (Raft/Distro).

Health check : ZooKeeper – TCP; Eureka – client heartbeat; Nacos – TCP/HTTP/client heartbeat.

Configuration management : ZooKeeper – ZNode (basic); Eureka – not supported; Nacos – native support.

Service discovery : ZooKeeper – supported but not core; Eureka – core feature; Nacos – richer core feature.

Ease of use : ZooKeeper – complex; Eureka – simple; Nacos – simple with UI.

Community & ecosystem : ZooKeeper – mature but low‑level; Eureka – stagnant yet stable; Nacos – active, backed by Alibaba.

Architectural Evolution Perspective

Early stage : ZooKeeper (CP) used by Hadoop, Kafka; suffers from poor scalability and split‑brain.

Mid stage : Eureka (AP) adopted by Spring Cloud Netflix; lacks configuration management.

Modern stage : Nacos (AP + CP) in Spring Cloud Alibaba; provides registration, configuration, multi‑environment isolation, but introduces higher functional complexity.

Technical Implementation Differences

Data synchronization : ZooKeeper – ZAB log replication; Eureka – asynchronous replication; Nacos – Distro (AP) / Raft (CP).

Heartbeat mechanism : ZooKeeper – server push; Eureka – client report; Nacos – flexible (HTTP/TCP/client).

Service storage : ZooKeeper – memory + disk tree; Eureka – memory only; Nacos – MySQL + memory hybrid.

Notification : ZooKeeper – watch; Eureka – pull (periodic refresh); Nacos – push (long connection).

Operational Best Practices

Nacos High‑Availability Deployment

# Production recommended cluster structure
3 Nacos Server + external MySQL

Enable cluster.conf mode.

Expose a unified access point via Nginx or K8s Service.

Persist registration data to avoid loss on restart.

ZooKeeper Common Issues

Split‑brain leading to abnormal node status.

Too many watches causing performance degradation.

Cluster expansion must be performed carefully to avoid election anomalies.

Eureka Self‑Protection Misjudgment

Container‑environment heartbeats may be lost.

Solution: increase eureka.instance.lease-renewal-interval-in-seconds.

Relationship with Kubernetes

Service discovery : K8s handles pod/service layer; Nacos operates at the application layer.

Configuration management : K8s uses ConfigMap/Secret; Nacos offers dynamic refresh, gray release, rollback.

Multi‑environment isolation : K8s – Namespace; Nacos – Namespace + Group.

Traffic governance : K8s requires Istio; Nacos provides built‑in weight and health policies.

Future Trend Outlook

Service Mesh Fusion : Nacos 2.x supports gRPC registration, enabling integration with Istio/Envoy.

Multi‑cloud & hybrid cluster sync : Supporting CRD/Helm Operator for cross‑cluster service synchronization.

Lightweight Edge Mode : Upcoming Edge Nacos for IoT and small‑cluster scenarios.

Final Selection Recommendations

New Spring Cloud projects – Nacos .

Distributed lock / leader election / coordination – ZooKeeper .

Legacy Netflix‑based systems – keep Eureka (maintenance only).

Kubernetes environments – use K8s + Nacos as a configuration center, not as a CoreDNS replacement.

Conclusion : ZooKeeper excels at coordination, Eureka at discovery, Nacos at governance; choose based on consistency requirements and deployment context.