高 进阶
Nacos注册中心原理#
一句话答案#
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 特性对注册中心来说反而是劣势——分区时无法写入会导致服务注册失败
面试回答（2分钟版）
Nacos 是 Spring Cloud Alibaba 生态的核心组件，同时提供注册中心和配置中心能力。作为注册中心，Nacos 的最大特点是支持 AP 和 CP 两种模式切换：临时实例走 AP 模式使用 Distro 协议，优先保证可用性，客户端通过心跳维持注册；持久实例走 CP 模式使用 JRaft 协议，优先保证一致性。健康检查方面 Nacos 同时支持客户端心跳和服务端主动探测，比 Eureka 只有客户端心跳更可靠。服务变更通知采用推拉结合——UDP 推送加 HTTP 长轮询兜底，比 Eureka 默认 30 秒轮询实时性更好。和其他注册中心对比：Eureka 纯 AP 但 Netflix 已停止维护；ZooKeeper 纯 CP，网络分区时可能拒绝服务，对注册中心来说反而是劣势。注册中心应优先选 AP 模型，因为返回旧数据总比拒绝服务好。另外 Nacos 挂了也不影响短期服务调用，客户端有本地缓存兜底。
追问与易错
追问方向：
- “心跳检测和 Eureka 区别？”→ Nacos 支持临时实例（客户端心跳，类似 Eureka）和永久实例（服务端主动探测）；Eureka 只有客户端心跳且有自我保护机制（大面积心跳丢失时不剔除），Nacos 的健康检查更灵活
- “集群怎么部署？”→ 至少 3 个节点组成集群，通过 cluster.conf 配置节点列表；Nacos 1.x 用 MySQL + Raft 做数据一致性，2.x 用 Distro 协议（AP）处理临时实例、JRaft（CP）处理永久实例
- “实例下线但心跳还在？”→ 可能是优雅停机没做好，应用关闭前应主动调用 deregister 注销实例；或者用 Spring Cloud 的 shutdown endpoint 配合 @PreDestroy 钩子主动下线，避免流量打到已关闭的实例
易错点：
- ❌ Nacos 挂了服务不能调——客户端有本地缓存
- ❌ 混淆注册中心和配置中心