一、核心组件深度解析
1. ZooKeeper
定位：分布式协调服务，是 Google Chubby 的开源实现。
核心模型：基于 ZAB 协议 的 CP 系统。
✅ 适用场景
- 分布式锁：经典的分布式锁实现方案。
- 领导者选举：在多个服务实例中选主节点。
- 集群管理：确保节点上下线状态一致。
- 元数据存储：存储少量强一致性数据。
- 命名服务：统一命名注册。
⚙️ 特点
- 强一致性（C）：任何时候访问到的数据都是最新的。
- 牺牲可用性（A）：网络分区时系统可能拒绝写入。
- Ephemeral 临时节点：客户端断开后自动删除，天然适合注册发现。
- Watch 机制：监听节点变化，实现事件通知。
⚠️ 在服务发现中的问题
当网络抖动或脑裂时，ZooKeeper 为保证一致性（CP），可能“误判”节点宕机，注销健康实例，导致可用性下降。
这与微服务系统“可用优先”的原则冲突，因此不推荐将其直接用作注册中心。
2. Eureka
定位：Netflix 开源的服务发现组件，专为微服务架构设计。
核心模型：AP 系统。
✅ 适用场景
- 纯服务注册与发现。
- 容错性和可用性要求高的系统。
⚙️ 特点
- 高可用性（A）与分区容错性（P）：宁可返回旧数据，也不拒绝请求。
- 客户端缓存：即使 Server 挂掉，客户端仍可调用服务。
- 自我保护机制：防止网络异常时“误删”实例。
- 弱一致性：注册信息异步复制，节点间可能存在短暂延迟。
⚠️ 不足
- 功能单一，仅支持服务发现。
- 官方停止更新 2.0 版本（但 1.x 稳定可用）。
- 无配置管理、无 UI 管理能力。
3. Nacos
定位：阿里巴巴开源的动态服务发现、配置和服务管理平台。
核心模型：支
