面经策

Spring Cloud 有哪些注册中心？ ​

  • 标签：注册中心、Spring Cloud、微服务

🏛 业务架构师 ​

Spring Cloud 生态可用的注册中心，我按"2026 年还值不值得选"给出真实判断：

  1. Nacos（国内首选，事实标准）：注册中心 + 配置中心二合一，AP/CP 可切换，支持 DNS-F 与 gRPC 长连接，Spring Cloud Alibaba 生态核心。活跃度、中文社区、文档都最好。运维上一个集群解决两个问题，中小团队的性价比之王；

  2. Eureka（历史主角，已停更）：AP 系统（自我保护机制牺牲一致性保可用性），Netflix 套件成员，2.x 闭源停更后只做维护。新项目不应选择，面试价值在于理解 AP 设计取舍；

  3. Consul（多语言/HashiCorp 生态）：CP（Raft），带 K-V 配置、健康检查、Service Mesh 集成能力，多语言技术栈（Go/Python 服务混合）的团队常见选择；

  4. Zookeeper（重型，已边缘化）：CP 强一致（ZAB 协议），原本是 Hadoop 生态协调器。运维复杂（需要专人）、客户端复杂、没有健康检查语义（只有会话存活），如今选它做注册中心的场景很少；

  5. etcd / Kubernetes Service：K8s 原生环境可直接用平台能力——上 K8s 后"去注册中心化"是真实的架构趋势（Service + DNS + Endpoint 自动发现）。

我的选型决策树：

  • Spring Cloud Alibaba 技术栈 → Nacos，没有第二答案；
  • 多语言、无 Spring 绑定 → Consul；
  • 全 K8s 环境 → 优先评估用平台自带发现，砍掉自建注册中心（少一个组件少一份运维与故障面）。

面试加分句：注册中心是基础设施，选择标准是"组织运维能力 + 已有技术栈"，而不是特性清单对比。

🏗 系统架构师 ​

可选清单与现状：

  • Nacos：国内绝对主流（AP/CP 可切、注册加配置一体）；
  • Eureka：Netflix 系，2.x 闭源后进入维护模式——存量多、新项目不选；
  • Consul：Hashi 栈，多数据中心强；注意 2023 年转 BUSL 许可的组织接受度问题；
  • ZooKeeper：CP 强一致（临时节点加 session），Kafka/Hadoop 系遗产，运维门槛高，新项目少用作注册中心；
  • etcd：K8s 原生，多用于自研平台；
  • K8s Service/DNS：全量上云后平台本身即注册中心——我优先推荐。

选型维度（注册中心的架构特性）：

  1. CAP 取向：注册场景要 AP 加客户端缓存——分区时保可用，宁可列表略旧；
  2. 健康检查模型：客户端心跳 TTL（推）还是服务端主动探测（拉）；
  3. 推送实时性：长轮询/gRPC 推送还是定时轮询；
  4. 运维成本与生态整合（与配置中心是否合一）。

趋势判断：注册发现作为应用层组件正被平台（K8s）与网格吸收；它的独占价值收缩到跨集群、混合部署、多语言非 mesh 场景。

💻 全栈开发专家 ​

生态内主流：

  • Nacos：注册 + 配置一体，支持 AP/CP 切换（临时实例 AP/Distro 协议，持久实例 CP/Raft），2.x gRPC 长连接，控制台好用——当前国内默认选择
  • Eureka：Netflix 出品，AP 型 + 自我保护机制，2.x 停止维护，存量仍在跑
  • Zookeeper：CP（ZAB 协议）强一致；做注册中心要处理会话过期抖动、分区时整体不可用，运维偏重
  • Consul：HashiCorp，CP（Raft），健康检查方式最丰富（HTTP/TCP/Script），自带 KV 和多数据中心
  • etcd：CP（Raft），K8s 的底座，裸做业务注册中心少
  • Spring Cloud Kubernetes：直接用 K8s Service/DNS 做发现，云原生纯血方案

选型三问：AP 还是 CP——注册中心主流选 AP：宁可拿到过期实例靠调用方超时/熔断兜底，也别让注册中心分区时整体瘫（ZK 分区时发现全挂的教训）；要不要配置中心一体（Nacos 省一套运维）；K8s 化深度（深度 K8s 可直接下沉 Service）。