Nacos 与 Eureka、ZooKeeper 的区别是什么？

面试考察点

1. 注册中心选型能力：面试官不仅仅是想知道这三个组件的功能差异，更是想考察你是否理解 CAP 理论在注册中心中的应用，能否根据业务场景做出合理的技术选型。

2. 分布式理论深度：这道题的背后是 CAP 定理和 BASE 理论，面试官想知道你是否理解 "一致性" 和 "可用性" 在注册中心场景下的权衡。

3. 生产实践经验：能否结合实际使用经验，说出不同注册中心在生产环境中的优缺点和踩坑经历。

核心答案

Nacos、Eureka、ZooKeeper 都可以用来做服务注册中心，但它们的设计理念、CAP 模型和功能范围有本质区别。

对比维度	Nacos	Eureka	ZooKeeper
开发方	阿里巴巴	Netflix	Apache
CAP 模型	AP + CP 可切换	AP	CP
一致性协议	Raft（CP）/ Distro（AP）	无协议（Peer-to-Peer 复制）	ZAB 协议
健康检查	主动探测（TCP/HTTP/MySQL）	心跳（客户端续约）	会话保持（长连接 + Session）
配置管理	✅ 内置	❌ 无	✅ 有（但功能较弱）
服务发现	✅ 支持	✅ 支持	✅ 支持（需自己实现）
雪崩保护	✅ 有	✅ 有	❌ 无
跨注册中心同步	✅ 支持	❌ 不支持	❌ 不支持
实例上下线感知	实时（长轮询推送）	延迟（30s 拉取）	实时（Watch 机制）
维护状态	活跃开发中	停更（维护模式）	活跃开发中
适用场景	微服务注册 + 配置中心	简单服务注册	分布式协调（非主要做注册中心）

一句话总结：Nacos 功能最全（注册中心 + 配置中心，AP/CP 可切换），Eureka 简单但已停更，ZooKeeper 本质是分布式协调工具，不适合做大规模注册中心。

深度解析

一、CAP 模型对比（面试重点）

这是三者最核心的区别，也是面试官最想听到的内容。

上图展示了三者在 CAP 模型中的定位。关键要点：

• ZooKeeper（CP）：优先保证一致性。当 Leader 节点挂了，集群需要重新选举，选举期间整个集群不可用（约 30~120s）。对于注册中心来说，短暂不可用意味着服务无法注册和发现，这在微服务场景下是不可接受的。

• Eureka（AP）：优先保证可用性。各节点平等，任何一个节点挂了都不影响服务注册和发现。但它牺牲了一致性——服务端返回的实例列表可能不是最新的（有 30s 的延迟）。

• Nacos（AP + CP 可切换）：支持根据实例类型自动选择一致性模型。临时实例（ephemeral，大多数微服务）使用 AP 模式，持久实例（persistent，数据库等）使用 CP 模式。这是 Nacos 最灵活的地方。

二、健康检查机制对比

健康检查直接决定了 "服务下线感知的速度"，是注册中心的核心能力。

上图对比了三种健康检查机制。关键要点：

• Eureka：客户端每 30s 发一次心跳，服务端 90s 没收到心跳才剔除实例。这意味着一个服务挂了，最多需要 90 秒 才能被感知到，而且 Eureka 不会主动探测服务的真实健康状态（可能心跳还在，但服务已经 "假死"）。

• ZooKeeper：基于 TCP 长连接 + 临时节点（EPHEMERAL），Session 断开时临时节点自动删除。感知速度很快，但问题是 网络抖动 也可能导致 Session 断开，触发不必要的 "下线-上线" 抖动。

• Nacos：临时实例使用客户端心跳（类似 Eureka），持久实例使用服务端主动探测（TCP / HTTP / MySQL 等多种方式），兼顾了实时性和准确性。

三、Nacos 的核心优势

Nacos 相比 Eureka 和 ZooKeeper，最大的优势在于 功能全面：

能力	说明
注册中心 + 配置中心	一个组件搞定两个核心需求，不需要额外引入 Spring Cloud Config 或 Apollo
AP / CP 可切换	临时实例 AP，持久实例 CP，自动选择，不需要人工干预
多语言支持	提供 gRPC、HTTP、DNS 等多种接入方式
服务分组 & 命名空间	支持多环境隔离（dev / test / prod）、多租户隔离
权重路由	实例级别的权重配置，支持灰度发布
跨注册中心同步	支持 Nacos 集群间的数据同步，方便多数据中心部署

四、为什么 ZooKeeper 不适合做注册中心？

虽然 ZooKeeper 也能做服务注册，但在大规模微服务场景下有以下问题：

• CP 模型不适合：Leader 选举期间集群不可用，微服务场景下 "注册中心不可用" 是致命的——新服务无法注册，消费端无法发现新实例。
• 性能瓶颈：ZooKeeper 将所有数据放在内存中，服务实例数量多时（上万实例），每次变更都要通知所有 Watch，对性能压力很大。
• 设计初衷不同：ZooKeeper 本质是 分布式协调工具（分布式锁、Leader 选举、配置同步），不是专门为服务注册发现设计的。

阿里内部早期使用 ZooKeeper 做 Dubbo 的注册中心，后来因为上述问题，转而自研了 Nacos。

面试高频追问

1. 追问一：Nacos 的 AP 和 CP 模式是怎么切换的？

   • 不是手动切换，而是根据实例类型自动选择。注册临时实例（默认）时使用 AP 模式（Distro 协议），注册持久实例时使用 CP 模式（Raft 协议）。通过 spring.cloud.nacos.discovery.ephemeral=false 可以将实例设为持久实例。

2. 追问二：Nacos 的配置中心怎么保证配置的实时性？

   • 客户端通过 长轮询（Long Polling） 机制监听配置变化。客户端发起一个长连接请求，服务端发现配置变化时立即返回，否则保持连接直到超时（默认 30s），然后客户端再次发起请求。这样既保证了实时性，又不会频繁轮询。

3. 追问三：如果 Nacos 集群挂了，微服务还能正常调用吗？

   • 可以。消费端会缓存已拉取的服务实例列表在本地，Nacos 挂了之后，消费端仍然可以使用本地缓存进行调用。只是无法感知新的服务上下线变化，直到 Nacos 恢复。

常见面试变体

• 变体一："为什么 Nacos 能替代 Eureka？"
• 变体二："CAP 理论在注册中心中是怎么体现的？"
• 变体三："Nacos 2.x 相比 1.x 有什么改进？"
• 变体四："注册中心怎么选型？"

记忆口诀

ZooKeeper 重一致（CP），Eureka 重可用（AP），Nacos 两手抓：ZooKeeper 是 CP 模型，Leader 选举期间不可用；Eureka 是 AP 模型，牺牲一致性保可用性；Nacos 最灵活，临时实例走 AP、持久实例走 CP，还自带配置中心。新项目无脑选 Nacos 就对了。

总结

Nacos、Eureka、ZooKeeper 的核心区别在于 CAP 模型的选择：ZooKeeper 走 CP 路线（强一致但可能不可用），Eureka 走 AP 路线（高可用但数据可能不一致），Nacos 则支持 AP/CP 动态切换，并且集注册中心 + 配置中心于一体。新项目推荐直接使用 Nacos，功能全面、社区活跃、阿里生产验证。