Consul/Eureka 与 Nacos 对比（简述各自特点）
只装过 Nacos 的人容易把"注册中心"理解成唯一形态。实际上 Eureka、Consul、Nacos 三家的设计取向差别很大，了解差异才能理解自己项目的选型，以及为什么有些公司长期停留在 Eureka。本章做横向对比，内容以三家官方文档为准。
Eureka：Netflix 时代的经典
Eureka 是 Netflix 开源、由 Spring Cloud Netflix 集成的注册中心。它的设计目标是"服务注册表永远可读"：实例只向注册中心上报状态，注册中心之间相互复制，集群内部分区时宁可保留过期数据也不拒绝查询，属于典型的 AP 风格。客户端缓存能力强，即使 Eureka Server 短暂不可用，调用方仍可基于本地缓存继续工作。Eureka Server 与 Client 都是 Spring 生态内的 Java 工程，通过 eureka-server 依赖自建服务端、eureka-client 接入即可。需要说明的是，Netflix 相关组件早已停止大规模演进，Spring Cloud Netflix 中的 Eureka 目前处于维护状态：能用、文档全、新特性少，适合存量系统。
Consul：基础设施派的选择
Consul 是 HashiCorp 用 Go 写的服务网格基础设施，Spring Cloud 通过 consul-discovery 接入。它走 CP 路线：以 Raft 保证一致性，写入需要多数节点确认，分区时更重视"不错"而非"不停"。与 Eureka 相比，Consul 自带能力更全：服务注册、健康检查（HTTP/TCP/脚本）、Key/Value 配置存储、多数据中心，甚至内置 DNS 接口，非 Spring 的异构服务也能接入。代价是需要独立运维 Consul 集群，且注册表读写一致性开销更大，跨数据中心同步要额外设计。
Nacos：注册 + 配置一体的后起之秀
Nacos 由 Alibaba 开源，与 Spring Cloud Alibaba 深度集成。它最突出的特点是"一个产品两件事"：注册中心与配置中心天然一体（第 11 章直接复用），省去单独部署配置中心的成本。模型上支持临时实例（AP 模式，客户端心跳上报，适合弹性伸缩的微服务）与持久实例（CP 模式，服务端主动探测，适合数据库类有状态服务），并支持权重路由、命名空间、分组等贴近国内多环境实践的特性。健康检查、控制台、文档的中文生态也相对完整。Nacos 3.x 起架构与部署方式有调整，新项目建议直接采用 3.x，存量 2.x 按官方升级文档迁移。
横评一览
从六个维度对比，可得到一张速查表：
| 维度 | Eureka | Consul | Nacos |
|---|---|---|---|
| 一致性取向 | AP | CP | AP/CP 可切换 |
| 健康检查 | 客户端心跳 | 服务端主动探测为主 | 心跳/主动探测按实例类型 |
| 配置中心 | 无 | 自带 KV | 自带，一体 |
| 多环境支持 | 弱 | 一般 | 命名空间/分组成熟 |
| 生态整合 | 维护状态 | 官方 starter | SCA 深度集成 |
| 运维成本 | 低 | 中（需集群运维） | 中（可单机起步） |
存量迁移与多套并存
现实中常常不是"选一个"，而是"正在换"。存量 Eureka 体系切到 Nacos 时，常见顾虑是注册数据能否迁移、客户端依赖怎么替换、是否要停机。务实的迁移节奏是按服务分批推进：把各服务客户端的 eureka 依赖换成对应的 discovery starter，应用逐批重启接入新注册中心；过渡期新旧注册中心并存时，跨中心的调用要通过网关路由或双注册方案衔接（同一应用同时注册到两套注册中心的官方支持程度不同，过渡方案以官方文档为准）。切换期的验证重点有三项：
- 依赖与配置替换干净：eureka 专属配置删除，服务名、健康检查、元数据逐项对齐；
- 服务列表完整：新旧实例数量一致、健康状态正常；
- 调用链验证：先单服务、再完整链路，最后灰度放量。
一个务实的选型建议
把决策简化为三个问题：现有技术栈是否有强绑定（有则沿用或渐进迁移）；是否需要注册与配置一体化（是则 Nacos 优先）；是否有异构服务或多数据中心诉求（是则认真评估 Consul）。注册中心是基础设施，切换成本远高于其边际收益，除非有明确痛点，否则"用熟不用生、能渐进不推倒"通常是最优解。
常见认知纠偏
对比三家时，几个高频误解值得澄清：
- "注册中心就是配置中心"：Eureka 只有注册表；Consul 自带 KV 但定位是基础设施存储；只有 Nacos 把注册与配置做成一体的产品能力，这也是它"省一套中间件"卖点的来源；
- "AP 一定会读到脏数据"：AP 允许短暂读到过期实例，但配合客户端缓存与自我保护，多数场景体感无损，代价只体现在极端分区时刻；
- "CP 一定更可靠"：一致性有代价，分区时 CP 注册中心可能拒绝写入，可靠性是场景相关的，没有免费的午餐；
- "注册成功就能接流量"：注册只代表实例上报成功，能不能接流量取决于健康检查粒度与调用方缓存，两者要分开看待。
商业与授权因素
选型进入企业决策层面，还有一层非技术因素：各项目的开源协议、商业版本策略与社区治理模式各不相同且会演进（例如 Consul 曾调整其开源授权条款）。大型组织应把授权条款、支持渠道与版本生命周期纳入评估清单，以各项目官方声明为准，避免"技术合适、法务不过"的尴尬。
健康检查方式决定故障感知速度
三种注册中心探测实例存活的方式不同，直接影响"宕机后多久能被摘除"：
- Eureka：客户端周期性上报心跳，服务端记账，宕机感知依赖心跳超时，通常较慢但实现简单；
- Consul：服务端主动发起 HTTP/TCP 探测，感知快、探活主动，但要求注册中心能访问到业务实例，网络规划时要留通；
- Nacos：临时实例走客户端心跳，持久实例走服务端主动探测，两种模型按实例类型切换。
选型时别忽略这一点：如果注册中心与业务网络隔离（如跨机房不通），主动探测型会把健康实例误判下线，需要结合部署拓扑选择心跳型或打通探测路径。
如何选择
存量 Netflix 体系或对"注册表可用性优先"有强诉求，可继续 Eureka；已经有 Consul 集群或需要异构服务与多数据中心能力，Consul 合适；国内新项目、且希望注册与配置一套搞定，优先 Nacos。若公司要求注册中心可观测、可治理并接入服务网格，则需另行评估 Istio 等方案，这已超出本教程范围。
小结
三者本质是同一问题（实例地址的存储、健康与分发）的不同取舍：Eureka 求可用、Consul 求一致、Nacos 求一体与灵活。选型没有绝对最优，关键是匹配团队运维能力与存量技术栈。本章之后回到主线：用 OpenFeign 把服务调用做得更工程化。