Eureka、Zookeeper、Nacos、Consul 的区别？
- 标签：后端、Spring Cloud、微服务
🏛 业务架构师
四者的区别我抓三个本质维度：一致性取舍（AP/CP）、健康检查方式、生态定位：
| 维度 | Eureka | Zookeeper | Nacos | Consul |
|---|---|---|---|---|
| 一致性 | AP（自我保护） | CP（ZAB） | AP/CP 可切 | CP（Raft） |
| 健康检查 | 客户端心跳 | 会话存活（无健康语义） | 心跳 + 服务端探测双模 | HTTP/TCP/脚本多探针 |
| 附加能力 | 无 | 分布式协调（锁/选举） | 注册+配置二合一 | K/V、多数据中心 |
| 现状 | 停更 | 注册场景边缘化 | 国内主流 | 多语言场景主流 |
架构师视角的解读（比表格更重要）：
- AP vs CP 的业务判断：注册中心的首要职责是"别把注册表搞丢搞空"——网络分区时，Eureka/Nacos（临时实例 AP 模式）宁可返回略有陈旧的列表，配合客户端重试熔断兜底；ZK 分区时少数派不可服务，注册不可用会放大故障。所以微服务场景 AP 是主流选择；
- 健康检查的语义差距：ZK 只知道"会话在不在"，不知道"服务能不能处理请求"——真正健康检查（业务就绪探针）才是摘流量的依据；
- 我的选型：Java + Spring Cloud Alibaba → Nacos（一个集群两用，运维成本减半）；多语言/HashiCorp 生态 → Consul；K8s 全托管环境 → 先评估平台原生发现，可能一个都不用引。
结论句：注册中心选型的本质是"一致性语义 + 运维归属"的组织决策。
🏗 系统架构师
表格先行：
| 维度 | Eureka | ZooKeeper | Consul | Nacos |
|---|---|---|---|---|
| CAP | AP | CP | CP | AP/CP 可切 |
| 健康检查 | 客户端心跳 | session 临时节点 | Agent 多种探测 | 心跳/服务端探测 |
| 一致性 | 最终一致 | ZAB 强一致 | Raft | Distro/Raft |
| 控制台 | 弱 | 无 | 好 | 好（中文） |
| 附加能力 | 无 | 通用协调 | KV/mesh/多DC | 配置中心一体 |
| 现状 | 维护模式 | 中间件协调用 | 活跃（BUSL） | 国内主流 |
架构选型逻辑：
- 注册中心要 AP 加客户端缓存：分区时「拿旧列表调用加重试熔断兜底」优于「注册中心不可写导致服务无法上线」——Eureka 与 Nacos AP 模式的哲学；
- ZK 的强一致在注册场景反成负担（leader 选举期间不可用 30s 级），运维也重，现在主要服务 Kafka 系；
- Nacos 胜在整合：注册加配置加控制台，一套组件少一半运维；
- K8s 全托管场景：直接用平台 Service/DNS，应用层注册中心只服务跨集群、混合部署、多语言非 mesh 场景——这是我做选型的第一问。
💻 全栈开发专家
| 维度 | Eureka | Zookeeper | Nacos | Consul |
|---|---|---|---|---|
| CAP | AP | CP | AP/CP 可切换 | CP |
| 一致性协议 | 无（异步复制） | ZAB | Distro（AP）/Raft（CP） | Raft |
| 健康检查 | 客户端心跳 | 会话保持 | 临时心跳 + 服务端探测 | HTTP/TCP/Script 多样 |
| 控制台 | 简陋 | 无 | 完善（中文） | UI 一般 |
| 配置中心 | 无 | 需自建 | 有 | KV 可凑 |
| 现状 | 停更 | 存量 | 活跃（国内主流） | 活跃（海外主流） |
关键认知：注册中心主流观点选 AP——网络分区时 CP 系统（ZK/Consul）会拒绝发现查询，整个调用体系瘫痪；AP 拿到过期列表，靠客户端超时 + 熔断兜底，代价可控。Nacos 的取巧：临时实例走 AP Distro（服务发现主力场景），持久实例/配置走 CP Raft。
健康检查的实操差异：Eureka 心跳只能说明"进程活着"；Consul/Nacos 的 HTTP 探测能表达"活着但不健康（依赖挂了）"——就绪语义靠后者，或 K8s readinessProbe 顶上。