微服务服务发现全解析：Eureka、Nacos 与 ZooKeeper 对比与选型指南

一、核心组件深度解析

1. ZooKeeper

定位：分布式协调服务，是 Google Chubby 的开源实现。
核心模型：基于 ZAB 协议 的 CP 系统。

✅ 适用场景

1. 分布式锁：经典的分布式锁实现方案。
2. 领导者选举：在多个服务实例中选主节点。
3. 集群管理：确保节点上下线状态一致。
4. 元数据存储：存储少量强一致性数据。
5. 命名服务：统一命名注册。

⚙️ 特点

• 强一致性（C）：任何时候访问到的数据都是最新的。
• 牺牲可用性（A）：网络分区时系统可能拒绝写入。
• Ephemeral 临时节点：客户端断开后自动删除，天然适合注册发现。
• Watch 机制：监听节点变化，实现事件通知。

⚠️ 在服务发现中的问题

当网络抖动或脑裂时，ZooKeeper 为保证一致性（CP），可能“误判”节点宕机，注销健康实例，导致可用性下降。
这与微服务系统“可用优先”的原则冲突，因此不推荐将其直接用作注册中心。

2. Eureka

定位：Netflix 开源的服务发现组件，专为微服务架构设计。
核心模型：AP 系统。

✅ 适用场景

1. 纯服务注册与发现。
2. 容错性和可用性要求高的系统。

⚙️ 特点

• 高可用性（A）与分区容错性（P）：宁可返回旧数据，也不拒绝请求。
• 客户端缓存：即使 Server 挂掉，客户端仍可调用服务。
• 自我保护机制：防止网络异常时“误删”实例。
• 弱一致性：注册信息异步复制，节点间可能存在短暂延迟。

⚠️ 不足

• 功能单一，仅支持服务发现。
• 官方停止更新 2.0 版本（但 1.x 稳定可用）。
• 无配置管理、无 UI 管理能力。

3. Nacos

定位：阿里巴巴开源的动态服务发现、配置和服务管理平台。
核心模型：支