注册中心选型（CAP 权衡与产品对比）

TL;DR（30 秒扫完）

CAP 本质：P 必选（网络分区不可避免），只能在 C 和 A 之间选
四大产品：Eureka（AP，停维护）/ Zookeeper（CP）/ Nacos（AP+CP 双模）/ Consul（AP+CP 双模）
业务场景选型：微服务→AP，DB 主从/分布式锁→CP，微服务全家桶→Nacos，多云 K8s→Consul
集群部署：至少 3 节点，Raft 需多数派，客户端配多地址，外置 MySQL

关键结论

结论 A注册中心选型的本质是 CAP 权衡，不是简单的"哪个好用"

结论 BApollo 是配置中心，不是注册中心——这个错误认知必须纠正

结论 CNacos 的 AP/CP 双模式（临时/永久实例）是相比 Eureka/ZK 最大的差异化

结论 DZookeeper 的 ZAB 协议和选主开销不适合微服务高频上下线场景

完整讲解（费曼四步）

STEP 1 · 概念

注册中心（Service Registry）是微服务架构的核心组件，提供服务实例的动态注册、发现、健康检查能力。

STEP 2 · 大白话

类比公司通讯录：员工（服务实例）入职登记（注册），离职签退（注销）；其他人想找某同事（服务调用）来通讯录查。

STEP 3 · 底层

CAP 本质：

C（Consistency）一致性：任何读都能读到最新写入
A（Availability）可用性：所有请求都能得到响应（不保证最新）
P（Partition Tolerance）分区容错：网络分区时系统仍能工作
P 必选（网络分区不可避免）→ 只能在 C 和 A 之间选

四大主流产品对比：

维度	Eureka	Zookeeper	Nacos	Consul
CAP	AP	CP	AP+CP 双模	AP+CP 双模
数据同步	客户端推送	ZAB	Distro（AP）/Raft（CP）	Raft
服务下线	15s（30s 剔除）	立即（Watch）	15s（心跳 30s 剔除）	TTL 到期
健康检查	心跳	Session 机制	心跳/TCP check	HTTP/gRPC/TCP
配置中心	无	无	有	有（KV）
生态	Spring Cloud	Dubbo 生态	Spring Cloud Alibaba	通用/多云
当前状态	已停维护（2018）	稳定	活跃	活跃

特别说明 Etcd：Kubernetes 底层组件，CP 强一致，一般不做业务注册中心。 业务场景选型决策树：

微服务无状态服务（用户/订单/支付）
  └─→ AP 优先 → Nacos（临时实例）或 Eureka

数据库主从切换 / 分布式锁 / 分布式配置
  └─→ CP 优先 → Zookeeper 或 Consul

微服务全家桶（注册 + 配置）
  └─→ Nacos（推荐，二合一）

多云、K8s 混合场景
  └─→ Consul（Serf 协议、多数据中心）

Eureka 的自我保护机制：

30 秒内，如果注册到某个 Eureka Server 的实例掉线比例超过 15%，触发自我保护
暂停剔除实例，防止网络分区导致服务被误摘除
这是 AP 系统的典型权衡：宁可短暂看到过期服务，也不误杀

为什么 Zookeeper 不适合做微服务注册中心：

ZK 是 CP，Leader 挂掉要选主（可能几十秒阻塞）
写操作需要 2/3 节点确认，性能有限
微服务高频上下线不适合强一致
老 Dubbo 生态常用，新场景不推荐

Nacos AP/CP 双模式：

临时实例走 Distro 协议（AP，异步复制）+ 客户端心跳续约
永久实例走 Raft/JRaft（CP，强一致）+ 服务端主动 check
通过实例类型切换，满足不同场景

集群高可用部署：

至少 3 节点（Raft 需要多数派）
客户端配置多地址（防单点）
外置 MySQL 存元数据（Nacos 不用 Derby）
端口：8848（HTTP）+ 9848/9849（gRPC）

STEP 4 · 简化

口诀：注册中心选型 = CAP 权衡；微服务选 AP（Nacos/Eureka），有状态选 CP（ZK/Consul）；Nacos 双模最全；集群至少 3 节点。

常见误区

只知 Eureka/ZK/Nacos，遗漏 Consul 和 Etcd

Consul 在多云/K8s 场景常用，Etcd 是 K8s 底层组件

不做 CAP 权衡直接推荐

先说 CAP 本质（P 必选，选 A 还是 C），再按场景选型

忽略集群部署要求

至少 3 节点 + Raft 需多数派 + 外置 MySQL

延伸追问

Eureka 的自我保护机制是什么？什么时候会触发？

要点：30 秒内，如果注册到某个 Eureka Server 的实例掉线比例超过 15%，触发自我保护，暂停剔除实例，防止网络分区导致服务被误摘除。

为什么 Zookeeper 不适合做微服务注册中心？

要点：ZK 是 CP，Leader 挂掉要选主（可能几十秒阻塞）；写操作需要 2/3 节点确认，性能有限；微服务高频上下线不适合强一致。

Nacos 集群挂了服务还能通信吗？

要点：能，客户端本地有缓存，服务列表最近一次快照能读；已建立连接不受影响；但新的实例变化感知不到，健康状态不更新。

生产环境 Nacos 如何做高可用？

要点：至少 3 节点，客户端配多地址；外置 MySQL 存元数据；监听端口 8848（HTTP）+ 9848/9849（gRPC）；定期备份 MySQL。

Nacos 2.x 相比 1.x 有哪些改进？

要点：长轮询改为 gRPC 长连接，降低网络开销、支持大流量推送；性能提升 10 倍；支持 Raft/JRaft 实现 CP 一致性；提供 Raft 集群容灾能力。

速查表

CAP 本质：P 必选，只能选 A 或 C
四大产品：Eureka（AP，停维护）/ ZK（CP）/ Nacos（AP+CP 双模）/ Consul（AP+CP 双模）
选型：微服务→AP；DB 主从/分布式锁→CP；全家桶→Nacos；多云 K8s→Consul
Etcd：K8s 底层组件，一般不做业务注册中心
Eureka 自我保护：30s 内 15% 掉线不摘除
ZK 不适合微服务：ZAB+选主阻塞+性能有限
集群部署：至少 3 节点 + Raft 需多数派 + 客户端配多地址 + 外置 MySQL
Apollo：配置中心，不是注册中心（严重易错点）

Anki 候选卡片

Q: 注册中心选型本质是什么？

A: CAP 权衡；P 必选（网络分区不可避免），只能在 C（一致性）和 A（可用性）之间选

Q: 四大主流注册中心及其 CAP 属性？

A: Eureka（AP，停维护）/ Zookeeper（CP）/ Nacos（AP+CP 双模）/ Consul（AP+CP 双模）

Q: 业务场景选型决策树？

A: 微服务无状态→AP（Nacos/Eureka）；DB 主从/分布式锁→CP（ZK/Consul）；微服务全家桶→Nacos；多云 K8s→Consul

Q: Eureka 的自我保护机制？

A: 30 秒内注册实例掉线比例超过 15%，触发自我保护，暂停剔除实例，防网络分区误摘

Q: 为什么 Zookeeper 不适合做微服务注册中心？

A: ZK 是 CP，Leader 挂要选主（几十秒阻塞）；写操作需 2/3 节点确认；微服务高频上下线不适合强一致

Q: Apollo 是注册中心吗？

A: 不是！Apollo 是配置中心（携程出品），和注册中心是两种完全不同的东西

Q: Nacos 生产部署要点？

A: 至少 3 节点（Raft 需多数派）+ 客户端配多地址 + 外置 MySQL（不用 Derby）+ 端口 8848/9848/9849

关联题目

[x] 《注册中心如何选型？》—— 2026-09-27 Round 1 Q10, 评分 ⭐⭐⭐

关联知识

CAP 权衡本质；Eureka/ZK/Nacos/Consul 对比；Nacos 双模最全

✦ 记忆口诀 ✦

CAP 权衡 / Nacos 双模 / 集群 3 节点+外置MySQL

关键可视化

暂无可视化

知识关系

⬆️ 前置（Prerequisite）

暂无

🔄 延伸（Extends）

暂无

⚡ 对比（Contrast）

暂无

🎯 概念 📏 规则 ⚠️ 误区 🔍 追问 ✨ 口诀共 0 张卡，点击翻面