3、主流注册中心对比：Eureka、Consul、Zookeeper、Nacos
好，咱们进入第三章。这一章我打算聊聊注册中心的选择问题。
说实话，每次做技术选型，注册中心都是个绕不开的坎。我见过不少团队，上来就拍脑袋选一个，结果后面踩坑踩得欲哭无泪。你想想看，注册中心要是挂了，整个微服务体系基本就瘫痪了——服务调用找不到地址，流量全打水漂。
所以今天我把四个最主流的选手拉出来遛遛：Eureka、Consul、Zookeeper、Nacos。咱们从原理、一致性、可用性、运维成本几个维度，掰开揉碎了讲。
3.1 先看CAP理论：你选CP还是AP？
在对比之前，我得先提一嘴CAP理论。这是分布式系统的“宪法”。
简单说：C（一致性）、A（可用性）、P（分区容错性），三者最多同时满足两个。网络分区是必然发生的，所以P必须选。剩下的，你只能在C和A之间二选一。
嗯，这里要注意：Zookeeper和Consul是CP系统，Eureka是AP系统，Nacos两者都支持（切换模式）。
我在项目中遇到过，有人把Zookeeper当注册中心用，结果网络抖动时整个注册服务不可写，服务发现直接卡死。这就是CP的代价——为了强一致性，牺牲了可用性。
核心结论：
- 如果你追求高可用，容忍短暂的不一致 → 选AP（Eureka、Nacos AP模式）
- 如果你追求强一致，能接受短暂不可用 → 选CP（Zookeeper、Consul、Nacos CP模式）
3.2 Eureka：老牌AP选手，但已进入维护期
Eureka是Netflix开源的产品，也是Spring Cloud早期的标配。说白了，它就是为“最终一致性”设计的。
它的设计哲学很直接：只要集群里还有一个节点活着，就能提供服务注册和发现。哪怕数据不一致，也比挂了强。
我记得有一次线上故障，Eureka集群里两个节点网络不通，但每个节点依然能独立提供服务。客户端虽然拿到的是部分服务列表，但调用没断。这就是AP的好处。
个人经验：Eureka的自我保护机制（Self Preservation）是个双刃剑。网络抖动时它会保留所有服务实例，不剔除。好处是防止误杀，坏处是可能把已宕机的服务留在列表里。我曾经因为这个问题，导致调用方一直往死节点发请求，直到超时。建议生产环境关闭自我保护，或者配合健康检查一起用。
Eureka的优缺点：
- 优点：简单、成熟、社区文档多、AP高可用
- 缺点：2.0版本已停止开发，进入维护期；不支持多数据中心；没有自带控制台
3.3 Consul：CP选手，自带健康检查和KV存储
Consul是HashiCorp家的产品。它用的是Raft协议，保证强一致性。
我刚开始用Consul时，觉得它比Eureka重不少。但用久了发现，它内置了健康检查、KV存储、多数据中心支持，这些东西在大型微服务体系里非常实用。
举个例子：Consul的健康检查可以执行脚本、HTTP请求、TCP连接。你可以写个脚本检查服务进程是否存活，比Eureka的心跳机制灵活多了。
避坑指南：我曾经在Consul集群里遇到脑裂问题。因为Raft要求多数节点存活才能选举Leader，如果机房网络分区，少数派那边的服务注册会全部失败。所以Consul集群至少部署3个节点，最好5个。别省机器钱。
Consul的优缺点：
- 优点：强一致性、健康检查丰富、支持多数据中心、自带DNS接口
- 缺点：运维复杂、网络分区时可用性下降、学习曲线陡
3.4 Zookeeper：分布式协调的老大哥，但别当注册中心用
Zookeeper是Apache的顶级项目，基于ZAB协议实现强一致性。很多中间件（Kafka、Dubbo）都依赖它。
但说实话，我不建议把Zookeeper直接当注册中心用。为什么？
Zookeeper的设计目标是分布式协调，不是服务发现。它的节点（ZNode）是临时节点，客户端断开连接后自动删除。这听起来很适合注册中心对吧？但问题在于：Zookeeper在写操作时性能较差，而且网络抖动会导致大量临时节点被删除，引发“惊群效应”。
我记得有个项目，服务实例上千个，Zookeeper集群在高峰期频繁触发Leader选举，整个注册服务卡了十几秒。那场面，真是惨不忍睹。
我的建议：如果非要用Zookeeper做注册中心，一定要控制服务实例数量，并且做好客户端重试和缓存。否则，你可能会被它的性能坑哭。
Zookeeper的优缺点：
- 优点：强一致性、成熟稳定、生态广泛
- 缺点：写性能差、不适合大规模服务发现、运维复杂（需要Java环境）
3.5 Nacos：后起之秀，AP/CP一键切换
Nacos是阿里巴巴开源的产品，也是我目前最推荐的一个。它支持AP和CP两种模式，你可以根据业务场景动态切换。
说白了，Nacos把Eureka和Consul的优点合二为一了。它既支持AP的高可用，也支持CP的强一致。而且它原生支持配置管理，一个组件搞定注册中心和配置中心。
我在项目中用Nacos替换了Eureka，迁移过程很平滑。Nacos的RESTful API和Eureka兼容，客户端基本不用改代码。
个人习惯：我一般把Nacos部署成AP模式，用于服务发现；配置管理用CP模式，保证配置的强一致。这样既保证了注册中心的高可用，又保证了配置数据的准确性。一举两得。
Nacos的优缺点：
- 优点：支持AP/CP切换、自带配置中心、控制台功能丰富、性能好
- 缺点：社区相对年轻、文档质量参差不齐、大规模集群需要调优
3.6 横向对比表格
为了方便你选型，我整理了一个对比表：
| 特性 | Eureka | Consul | Zookeeper | Nacos |
|---|---|---|---|---|
| CAP模型 | AP | CP | CP | AP/CP可切换 |
| 一致性协议 | 无（最终一致） | Raft | ZAB | Distro（AP）/ Raft（CP） |
| 健康检查 | 客户端心跳 | 多种方式（脚本、HTTP、TCP） | 临时节点（连接断开即删除） | 客户端心跳 + 主动探测 |
| 多数据中心 | 不支持 | 支持 | 不支持 | 支持 |
| 配置管理 | 不支持 | 支持（KV存储） | 不支持 | 支持（原生） |
| 控制台 | 简陋 | 一般 | 无（需第三方工具） | 丰富 |
| 运维复杂度 | 低 | 中 | 高 | 中 |
| 社区活跃度 | 低（已维护） | 中 | 高 | 高 |
3.7 选型建议
最后，我给出一些实际场景的选型建议：
- 中小型项目，追求简单快速 → 选Nacos。一个组件搞定注册和配置，省心。
- 已有Spring Cloud生态，不想大改 → 选Eureka。虽然进入维护期，但够用。
- 对强一致性有硬性要求 → 选Consul。比如金融、交易类场景。
- 已有Zookeeper基础设施，服务量不大 → 可以继续用Zookeeper。但别超过几百个实例。
总结一句话：我个人最推荐Nacos。它灵活、功能全、性能好。如果你还在纠结，不妨先拿Nacos试试，反正切换成本也不高。
好了，这一章就到这里。下一章咱们聊聊服务发现的具体实现——客户端发现和服务端发现，这两种模式有什么区别，各自适合什么场景。到时候见。