介绍
在微服务架构中，注册中心（Service Registry）扮演着"通讯录"的角色，负责服务的注册与发现。没有它，服务之间就无法动态感知对方的存在
目前市面上主流的注册中心有 Eureka、Consul、Zookeeper 和 Nacos。如何进行选型，核心取决于你的业务场景、技术栈以及对分布式系统 CAP 定理的取舍。Consul部分了解不多，就不多做介绍了
常见注册中心
Nacos
目前国内热度极高的"双重身份"组件，不仅能做注册中心，还能做配置中心
特性：同时支持 AP（高可用）和 CP（强一致）模式（默认 AP）。支持 Dubbo 和 Spring Cloud 体系
优点：
- 功能二合一，减少运维成本。
- 支持连接数极高的长轮询机制，服务发现几乎是毫秒级。
- 提供非常友好的可视化控制台
Eureka
Spring Cloud 早期核心组件
特性：纯粹的 AP 型。去中心化架构，节点平等
优点：
- 高可用性极强：只要集群里还有一个节点活着，就能正常提供服务查询。
- 有独特的"自我保护机制"，能防止因网络抖动误杀健康的微服务实例。
缺点：
- 功能单一，不支持配置中心。
- 时效性稍差：服务上下线是通过定时轮询刷新的，存在数据延迟
ZooKeeper
原本是分布式协调组件，被大数据和早期的 Dubbo 框架广泛用作注册中心
特性：基于 Paxos 变种（ZAB 协议），属于 CP 型
优点：技术成熟
缺点：不适合大规模微服务，作为 CP 系统，当服务节点过多、频繁上下线时，ZK 会因为强一致性的同步压力（通知所有 Watcher）导致性能急剧下降，甚至引发雪崩
选型
核心指标对比横评
| 特性 / 组件 | Nacos | Eureka | ZooKeeper |
|---|---|---|---|
| CAP 架构 | AP / CP 可选 (默认 AP) | AP | CP |
| 一致性协议 | Distro (AP) / Raft (CP) | 无 (最终一致性) | ZAB |
| 健康检查 | 心跳机制 / 主动探测 | 心跳机制 | KeepAlive / 临时节点 |
| 配置中心 | 支持 (原生且强大) | 不支持 (需配合 Config) | 不支持 |
| 多数据中心 | 支持 | 支持 | 不支持 |
| 服务跨语言 | HTTP / gRPC (较好) | 主要是 Java | 依赖 SDK (较弱) |