外观
一句话答案
Nacos 注册基于心跳检测，临时实例 AP 模式（Distro 协议），持久实例 CP 模式（Raft），同时支持配置管理。
核心要点
| 维度 | Nacos | Eureka | ZooKeeper |
|---|---|---|---|
| CAP 模型 | AP + CP（可切换） | AP | CP |
| 一致性协议 | Distro（AP）/ JRaft（CP） | 无，各节点平等，对等复制 | ZAB 协议（类 Paxos） |
| 健康检查 | 心跳 + 服务端主动探测 | 客户端心跳（默认 30s） | Session + 临时节点 |
| 推/拉模型 | 推（UDP）+ 拉（HTTP 长轮询） | 拉（默认 30s 轮询） | 推（Watch 机制） |
| 自我保护 | 有（Distro 协议天然容忍） | 有（Renew 比例 < 85% 进入保护模式，不剔除实例） | 无（过半节点不可用则不可写） |
| 雪崩保护 | 支持（空保护阈值） | 支持（自我保护模式） | 不支持（CP 模式下可能拒绝服务） |
| 配置中心 | 内置（Nacos Config） | 不支持（需搭配 Spring Cloud Config） | 可实现但需自行封装 |
| 多数据中心 | 支持（Group、Namespace） | 支持（Region/Zone） | 需要 Observer 模式 |
| 权重/灰度 | 支持（原生权重、元数据路由） | 不支持（需自行扩展） | 不支持 |
| 访问控制 | 支持（Namespace 级别隔离） | 不支持 | ACL |
| 社区维护 | 阿里巴巴活跃维护 | Netflix 已停更（2.x 闭源后回退 1.x） | Apache 活跃但偏底层 |
选型建议：
- Nacos：首选方案。AP/CP 可切换，同时提供配置中心，功能最全面，Spring Cloud Alibaba 生态深度集成
- Eureka：仅需 AP 模型且团队有历史积累时可用，但 Netflix 已停止维护 2.x
- ZooKeeper：Dubbo 生态首选（Dubbo 默认注册中心），但 CP 模型在网络分区时可能拒绝服务，不适合大规模微服务注册
面试要点：
- 注册中心应优先选择 AP 模型：网络分区时，宁可返回旧数据（某些实例可能已下线），也不要拒绝服务（CP 模型在分区时可能不可用）
- ZK 的 CP 特性对注册中心来说反而是劣势——分区时无法写入会导致服务注册失败
追问与易错
追问方向：
- 心跳检测和 Eureka 区别？
- 集群怎么部署？
- 实例下线但心跳还在？
易错点：
- ❌ Nacos 挂了服务不能调——客户端有本地缓存
- ❌ 混淆注册中心和配置中心
💡 记忆锚点
Nacos是注册中心里的"瑞士军刀"：临时实例走AP（Distro协议，优先可用），持久实例走CP（Raft协议，优先一致），还自带配置中心。对比：Eureka纯AP但已停更，ZK纯CP分区时拒绝服务。注册中心优先选AP——返回旧数据比拒绝服务好。