5 个维度拆完 Nacos、Eureka、Consul：选错注册中心，后面三年都在填坑

真实的菜 · 2026-07-02 14:42:44 发布

2019 年用 Eureka。Spring Cloud 全家桶标配，配合 Ribbon 做负载均衡，很稳。2020 年业务大了，开始需要配置中心。Eureka 只做注册，配不了。于是引入 Apollo。又多了一套部署。

2021 年团队觉得维护两套太累，调研了一圈选了 Consul——心想它能同时做注册和配置，还有健康检查，还有 KV 存储。结果 Consul 的配置管理用的是 KV 模型，没有版本回滚、没有灰度发布、没有变更审计。运维疯了。

2022 年全面切到 Nacos。Eureka 那三台机器和 Apollo 那两台回收了。只剩 Nacos 的三节点集群，注册 + 配置都在一套系统里。

这个团队的路径很典型——不是因为某个注册中心不好，而是注册中心的功能边界和选型判断标准本身就是随着业务在变的。这篇文章从五个维度把 Nacos、Eureka、Consul 拆开对比。每个维度给一个结论，最后给一张决策树。

三个选手的核心差异：Eureka 单一功能但简单，Consul 功能多但偏 DevOps，Nacos 在注册和配置之间取了一个平衡。

🔗 这套对比是站在应用开发角度看的。如果你关注配置中心本身，下一篇单独拆 Nacos vs Apollo：Nacos vs Apollo——配置中心选型，5 个场景告诉你谁更适合

	Eureka	Consul	Nacos
设计目标	AP	CP（强一致）	AP + CP（可切换）
写可用性	任一节点可写	只有 Leader 可写，Leader 挂了要等选举	临时实例任一节点可写，持久化实例只有 Leader 可写
网络分区时	各分区独立工作，恢复后合并	少数派分区的节点不可用	临时实例各分区独立工作，持久化实例少数派不可用
一致性模型	最终一致	强一致	看实例类型

Eureka 是纯 AP。网络分区时每一边都能独立注册和发现服务。代价是一致性——可能拿到过期的实例列表。Eureka 的自我保护机制就是 AP 的体现：宁可给你一个可能不健康的实例，也不踢掉它。

Consul 是纯 CP。写入要过半数节点确认。网络分区时少数派那一侧的节点不可用——写不进去也查不到最新的。这适合对一致性有要求但对可用性容忍度高的场景。如果服务注册发现的主要需求是"别拿到下线实例"，Consul 是更好的选择。

Nacos 给出了一条折中路径：同一个集群里，临时实例走 AP，持久化实例走 CP。 你在第五篇 5.4 里看过那 3 行 if 怎么分叉的。大部分微服务的服务发现场景用临时实例就够了——心跳断了自动清理，挂了也不会影响调用方（负载均衡会跳过不健康的实例）。

功能	Eureka	Consul	Nacos
服务注册发现	✅	✅	✅
健康检查	客户端心跳	✅ 内嵌多种检查	✅ 客户端心跳 + 服务端探测
配置中心	❌ 需要 Apollo 等补充	✅ KV 存储	✅ 专业配置管理
配置版本回滚	❌	❌	✅
配置灰度发布	❌	❌	✅（通过 group 分层）
DNS 服务发现	❌	✅ 原生支持	✅（nacos-dns）
Raft 协议	❌	✅	✅
gRPC 协议	❌	✅（v1.14+）	✅（2.x 全链路）

Eureka 的定位非常克制——只做注册发现。好处是简单，代码量不到 Nacos 的四分之一。坏处是你要自己另外搭配置中心。

Consul 的配置管理是 KV 存储模型。key-value 对的方式存配置，没有泛型、没有版本历史、没有回滚。运维用它存配置勉强可以，但做不了精细的配置治理——灰度、回滚、审计跟踪都不支持。

Nacos 的配置管理是一个完整的产品。有版本历史，能一键回滚；有 group 分层，能做灰度；有 @RefreshScope 动态刷新。这是它跟 Consul 在配置侧的最大区别。

实测数据（3 节点集群，1000 个服务，每服务 10 个实例 = 10000 个实例）：

指标	Eureka	Consul	Nacos
注册 TPS	~2000/s	~800/s	~1500/s（临时实例）
查询延迟	<5ms（本地缓存）	~20ms（需 Raft 读取）	<5ms（本地缓存）
通知推送延迟	30s（轮询窗口）	~5s（阻塞查询）	10ms（gRPC Push）
控制台操作响应	简单页面，<200ms	<300ms	<200ms
内存占用（3节点）	~600MB/节点	~500MB/节点	~1.2GB/节点（2.x）

Eureka 和 Nacos 的查询都有客户端缓存——本地有一份服务列表的副本，读操作不走网络。所以查询延迟都是毫秒级的。

Consul 的查询默认走 Raft，强一致读要等 Leader 确认。所以延迟比前两者高。可以开 stale read 模式降延迟，但牺牲一致性。

Nacos 1.x 的推送延迟跟 Eureka 差不多（轮询 1-30 秒），2.x 切到 gRPC 双向流之后降到 10ms。这是三家里最低的。如果业务对配置变更的实时性有严格要求（比如风控规则变更），Nacos 2.x 有明显优势。

运维动作	Eureka	Consul	Nacos
部署方式	jar 包启动	单二进制文件	jar/Source 两种格式
集群搭建	互配 peer 地址	自动加入（gossip）	cluster.conf 手动配置
节点替换	改 peer 列表，逐个重启	gossip 自动发现	改 cluster.conf，滚动重启
控制台	简单 dashboard	内置 Web UI	完整管理控制台
监控告警	需自建	内置 Agent 检查	Prometheus endpoint
跨数据中心	❌	✅ 原生支持	✅（通过 cluster-to-cluster）

Consul 的运维最省心。一个二进制文件，consul agent -server 就起来了。新节点加入通过 gossip 协议自动发现，不需要手动配 peer 列表。跨数据中心也是原生支持——在 consul join 指定 WAN 地址就行。

Eureka 的运维也简单，但功能少。没有控制台能做的事情除了看注册列表几乎没有别的。

Nacos 运维最重——需要 MySQL，cluster.conf 要手动维护（除非用 k8s Headless Service 自动注入），2.x 还多了一个 gRPC 端口 9848。但功能也最多。控制台能发布配置、管理服务、查看日志、操作集群。运维的成本换的是功能。

生态	Eureka	Consul	Nacos
Spring Cloud	✅ 原生集成	✅ spring-cloud-consul	✅ spring-cloud-alibaba
Spring Boot 原生	✅ @EnableEurekaClient	✅ @EnableDiscoveryClient	✅ @NacosInjected
Kubernetes	需要 sidecar/agent	✅ 官方 Helm + 自动加入	✅ StatefulSet + Headless Service
Go SDK	❌	✅ 官方 Go SDK	✅ nacos-sdk-go
REST API	✅	✅ HTTP + DNS	✅ OpenAPI v2
Dubbo	❌	❌	✅ 原生支持