注册中心与配置中心怎么选型？Nacos、Consul、ZooKeeper、etcd 怎么对比？
结论先行：注册中心解决“服务在哪、活着没有”，配置中心解决“配置统一管理与动态推送”。选型看两点：一是 CAP 取舍——注册发现适合 AP（可用性优先，读到已下线节点可容忍），配置下发要可靠送达；二是生态——Java 系常用 Nacos 一站式解决注册 + 配置，云原生/K8s 生态常用 etcd/Consul。
一、两个中心的职责
| 中心 | 核心职责 | 数据特点 |
|---|
| 注册中心 | 注册、发现、心跳续约、故障摘除 | 数据量大但简单，短暂不一致可容忍 |
| 配置中心 | 配置存储、变更推送、版本回滚、灰度 | 变更低频，但要求可靠送达 |
二、四款组件对比
| 对比项 | Nacos | Consul | ZooKeeper | etcd |
|---|
| 语言/生态 | Java/Spring 系 | Go/多语言 | Java/Hadoop 系 | Go/K8s 系 |
| CAP 侧重 | 注册 AP、配置可调 | AP（注册） | CP（强一致） | CP（强一致） |
| 注册+配置一体 | 是 | 是（可配 KV） | 弱 | KV 可当配置用 |
| 健康检查 | 心跳 + 可扩展 | HTTP/gRPC 探活 | 会话超时 | lease 续约 |
| 运维成本 | 低（开箱即用） | 中 | 高（ZK 集群运维） | 中（随 K8s 部署） |
三、设计要点（无论选哪个）
- 注册数据用心跳续约 + 超时摘除，服务实例要区分临时与持久。
- 客户端要有本地缓存与容灾：注册中心不可用时仍可用最后一次快照继续服务。
- 配置变更推拉结合：长连接推送为主、定期轮询兜底；变更留审计与回滚。
- 订阅模型统一：变更通知到达后再拉全量，避免推送风暴。
- 环境隔离：不同环境用命名空间/分组隔离，避免实例误发现、配置误覆盖。
四、注册发现的典型时序
服务启动 → 注册（IP/端口/元数据）→ 开启心跳续约
消费方订阅服务名 → 收到实例变更推送 → 本地缓存 + 定期刷新兜底
实例下线 → 主动反注册或心跳超时被摘除 → 消费方列表动态更新
常见追问与记忆点
- 追问：为什么注册中心倾向 AP、配置中心倾向 CP？注册短暂读到下线节点顶多多打一次，可用性优先；配置推错影响面大，要保可靠。
- 追问：Nacos 2.x 与 1.x 的差别？2.x 用 gRPC 长连接，服务发现推送更快，更适合大规模集群。
- 记忆点：Java 生态默认 Nacos 注册 + 配置一体化；etcd 绑定 K8s，Consul 偏多语言；CAP 取舍决定选型。