---
title: 注册中心选型（CAP 权衡与产品对比）
type: concept
domain: microservice
tags: [microservice, registry, eureka, zookeeper, nacos, consul, etcd, cap, raft, zab]
status: mastered
created: 2026-09-27
last_reviewed: 2026-09-27
method: feynman
related_questions:
  - "注册中心如何选型？"
related_knowledge:
  - ./nacos-core.md
  - ./microservice-architecture.md
anki_cards: 7
interview_rounds:
  - "2026-09-27-round-1-Q10"
---

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

> 注册中心选型的本质是 **CAP 权衡**：微服务无状态场景选 AP（Nacos/Eureka），有状态节点（DB 主从、分布式锁）选 CP（Zookeeper/Consul）。

## 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 权衡，不是简单的"哪个好用"
- **结论 B**：Apollo 是**配置中心**，不是注册中心——这个错误认知必须纠正
- **结论 C**：Nacos 的 AP/CP 双模式（临时/永久实例）是相比 Eureka/ZK 最大的差异化
- **结论 D**：Zookeeper 的 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 不适合做微服务注册中心**：
1. ZK 是 CP，Leader 挂掉要选主（可能几十秒阻塞）
2. 写操作需要 2/3 节点确认，性能有限
3. 微服务高频上下线不适合强一致
4. 老 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 节点。

## 常见误区（从面试记录提炼）

- **误区 1（严重错误）**："Apollo 是注册中心"→ 正确：Apollo 是**配置中心**（携程出品），和注册中心是两种完全不同的东西
- **误区 2**：只知 Eureka/ZK/Nacos，遗漏 Consul 和 Etcd→ 正确：Consul 在多云/K8s 场景常用，Etcd 是 K8s 底层组件
- **误区 3**：不做 CAP 权衡直接推荐→ 正确：先说 CAP 本质（P 必选，选 A 还是 C），再按场景选型
- **误区 4**：忽略集群部署要求→ 正确：至少 3 节点 + Raft 需多数派 + 外置 MySQL

## 延伸追问（面试追问预演）

1. **Eureka 的自我保护机制是什么？什么时候会触发？**
   - 要点：30 秒内，如果注册到某个 Eureka Server 的实例掉线比例超过 15%，触发自我保护，暂停剔除实例，防止网络分区导致服务被误摘除。
2. **为什么 Zookeeper 不适合做微服务注册中心？**
   - 要点：ZK 是 CP，Leader 挂掉要选主（可能几十秒阻塞）；写操作需要 2/3 节点确认，性能有限；微服务高频上下线不适合强一致。
3. **Nacos 集群挂了服务还能通信吗？**
   - 要点：能，客户端本地有缓存，服务列表最近一次快照能读；已建立连接不受影响；但新的实例变化感知不到，健康状态不更新。
4. **生产环境 Nacos 如何做高可用？**
   - 要点：至少 3 节点，客户端配多地址；外置 MySQL 存元数据；监听端口 8848（HTTP）+ 9848/9849（gRPC）；定期备份 MySQL。
5. **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：配置中心，不是注册中心（严重易错点）
```

## 关联题目（题库）

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

## 关联知识

- [Nacos 核心机制](./nacos-core.md)
- [微服务架构演进与特征](./microservice-architecture.md)

## Anki 候选卡片

1. **正**：注册中心选型本质是什么？**反**：CAP 权衡；P 必选（网络分区不可避免），只能在 C（一致性）和 A（可用性）之间选
2. **正**：四大主流注册中心及其 CAP 属性？**反**：Eureka（AP，停维护）/ Zookeeper（CP）/ Nacos（AP+CP 双模）/ Consul（AP+CP 双模）
3. **正**：业务场景选型决策树？**反**：微服务无状态→AP（Nacos/Eureka）；DB 主从/分布式锁→CP（ZK/Consul）；微服务全家桶→Nacos；多云 K8s→Consul
4. **正**：Eureka 的自我保护机制？**反**：30 秒内注册实例掉线比例超过 15%，触发自我保护，暂停剔除实例，防网络分区误摘
5. **正**：为什么 Zookeeper 不适合做微服务注册中心？**反**：ZK 是 CP，Leader 挂要选主（几十秒阻塞）；写操作需 2/3 节点确认；微服务高频上下线不适合强一致
6. **正**：Apollo 是注册中心吗？**反**：不是！Apollo 是配置中心（携程出品），和注册中心是两种完全不同的东西
7. **正**：Nacos 生产部署要点？**反**：至少 3 节点（Raft 需多数派）+ 客户端配多地址 + 外置 MySQL（不用 Derby）+ 端口 8848/9848/9849

---

*最后更新：2026-09-27*