注册中心如何选型？Nacos、Consul、ZooKeeper、Eureka 有何区别？
结论先行：注册中心的核心职责是服务注册、服务发现与健康检查，选型的本质是在 CAP 之间做取舍。服务发现领域普遍倾向于 AP（注册信息允许短暂不一致，但不能整体不可用），所以 Eureka、Nacos（AP 模式）更契合；强一致场景（如选主、分布式锁配套）才选 ZooKeeper/Consul 这类 CP 实现。
一、主流注册中心对比
| 维度 | Eureka | ZooKeeper | Consul | Nacos |
|---|---|---|---|---|
| 一致性 | AP | CP | CP | AP/CP 可切换 |
| 健康检查 | 客户端心跳 | 客户端心跳（临时节点） | 服务端主动探测 | 心跳 + 主动探测 |
| 服务发现方式 | 客户端拉取 + 缓存 | Watcher 通知 | HTTP/DNS | 客户端拉取 + 推送 |
| 配置中心 | 无 | 可自建 | 支持 KV | 内置且成熟 |
| 生态 | Spring Cloud Netflix | 通用分布式协调 | 多语言、多数据中心 | Java 系 + 多语言 SDK |
| 现状 | 2.0 停止开发 | 适合协调类场景 | 需独立部署集群 | 国内互联网主流 |
二、健康检查方式对比
- 心跳上报：客户端周期性上报（Eureka、ZK 临时节点），实现简单但对网络分区不敏感，可能误判；
- 主动探测：注册中心主动发起 TCP/HTTP/gRPC 检查（Consul、Nacos 持久实例），判断更准但增加中心压力；
- 实际工程常两者结合：临时实例走心跳，持久实例走主动探测；
- 摘除与剔除：健康检查失败后实例先被标记不健康并摘除流量，客户端缓存仍可能短暂残留，需要客户端主动剔除配合。
三、选型建议
- Java 微服务且需要配置中心一体：Nacos 最顺滑，社区活跃、功能全；
- 强一致协调诉求（分布式锁、选主）：ZooKeeper 或 etcd；
- 多数据中心、多语言、对 CP 有要求：Consul；
- 存量 Spring Cloud Netflix 体系：Eureka 仍可维护，新项目不建议再引入；
- 规模与容量：实例量达万级以上时，全量拉取与心跳会成为瓶颈，需评估推送与增量同步能力；
- 可观测性与高可用：注册中心自身要跨可用区部署，并暴露注册成功率、心跳延迟等指标。
四、选型速记
- 一体两用省事选 Nacos，强一致协调选 ZooKeeper，多数据中心 CP 选 Consul，存量 Netflix 选 Eureka；
- 判断口诀：先问要不要 CP、要不要配置中心、是否多语言多机房，三个问题即可圈定候选。
常见追问 / 记忆点
- 追问：注册中心为什么一般选 AP？答：服务发现追求可用性，注册信息短暂不一致可通过客户端重试自愈，而注册中心整体不可用会让全链路瘫痪。
- 追问：Nacos 的 AP 与 CP 模式怎么切换？答：临时实例走 AP（distro 协议），持久实例走 CP（JRaft），可按实例类型混用。
- 追问：服务下线后还能被调用到吗？答：健康检查与客户端缓存有延迟窗口，服务端摘除 + 客户端主动剔除可缩小窗口。
- 记忆点：Eureka 是 AP 心跳派、ZK/Consul 是 CP 强一致派、Nacos 一鱼多吃（注册 + 配置 + AP/CP 双模）。