阿里为什么造 Nacos？一个被 Spring Cloud Alibaba 官方钦定的注册中心到底什么来头

---

先看一个数字

Nacos 在 GitHub 上的 Star 数超过 30,000。

Spring Cloud Alibaba 官方文档里，服务发现和配置管理两个模块的推荐方案，都是 Nacos。

阿里内部，双11 的核心链路在跑 Nacos。

这三个事实放在一起，足够说明问题了。但很多人对 Nacos 的认知还停留在"又一个注册中心"。

这篇文章，我把 Nacos 是谁、从哪来、凭什么被选中的逻辑，一次性讲清楚。

---

Nacos 是四个单词的缩写

Naming and Configuration Service。

直译过来：动态命名与配置服务。

拆开来看更清楚：

• Naming（命名服务）：服务发现。你的订单服务要知道用户服务的实例在哪里。
• Configuration（配置服务）：配置管理。你的数据库密码改了，不用重启就能生效。
• Service（服务）：最终交付的是一个完整的平台，不是零散的组件。

命名用大白话说就是"服务发现 + 配置管理 + 动态 DNS"三者合一。

我第一次看到这个名字的时候觉得有点绕。后来理解了它的野心：它想做微服务基础设施层的一站式平台。

---

它不是凭空冒出来的

Nacos 不是阿里拍脑袋造的新轮子。它有两个"爹"。

亲爹一号：Dubbo 的注册中心需求

阿里内部大量使用 Dubbo 做 RPC 框架。Dubbo 需要一个注册中心来管理服务提供者和消费者之间的映射关系。

早年间，Dubbo 的注册中心方案是 Zookeeper。但随着集群规模膨胀，ZooKeeper 的 CP 模型开始暴露出问题——写操作太重，网络抖动时容易出现服务不可用。

同时，Dubbo 的配置管理一直在用一个叫 Diamond 的内部系统。Diamond 做得不错，但它只服务于配置管理，和服务发现是两套系统。

亲爹二号：ConfigServer 的演进

阿里还有一个内部系统叫 ConfigServer，专门做非 Dubbo 场景下的服务发现。

到了2018年，阿里决定把 Dubbo 的注册中心需求、Diamond 的配置管理能力、ConfigServer 的服务发现能力，全部整合到一个项目里。

这个项目就是 Nacos。

Nacos 不是从零开始的。它把阿里内部跑了超过10年的两套基础设施的经验，浓缩进了一个开源项目里。

---

一张图看懂 Nacos 在生态里的位置

两层能力（Naming + Config），一个平台。这是 Nacos 和其他同类产品最大的不同。

---

Nacos 在 Spring Cloud Alibaba 生态中的角色

Spring Cloud 有一套标准的服务发现抽象（DiscoveryClient）和配置管理抽象（PropertySourceLocator）。

Nacos 分别实现了这两套抽象：

// 服务发现——你连代码都不用改
@Autowired
private DiscoveryClient discoveryClient;

// 获取用户服务的所有实例
List<ServiceInstance> instances = discoveryClient.getInstances("user-service");

// 配置管理——加个注解就行
@RestController
@RefreshScope  // 配置变了自动刷新
public class OrderController {

    @Value("${order.timeout:3000}")
    private int timeout;
}

Spring Cloud Alibaba 的全家桶图大概是这样的：

• Nacos → 服务发现 + 配置管理
• Sentinel → 流量控制 + 熔断降级
• Seata → 分布式事务
• RocketMQ → 消息队列
• Dubbo → RPC 框架

Nacos 在这个生态里，是地基。没有它，Sentinel 的规则没法动态下发，Dubbo 的服务没法互相找到，Seata 的事务协调器地址不知道往哪写。

---

为什么不是 Eureka？不是 Apollo？

这个问题我被问过太多次了。简单说几个最核心的点：

Eureka 2.0 已经停止开发。 Netflix 官方宣布 Eureka 2.0 不再继续，现有版本进入维护模式。对于一个基础设施组件来说，这意味着未来不会有新功能，Bug 修复也会越来越慢。

Apollo 只做配置。 你还需要再部署一套服务发现的方案（Eureka / Consul / ZK），两套系统各自运维。接入层、鉴权、监控，全部要搞两遍。

Nacos 一套搞定两个需求。 而且在 Nacos 2.x 之后，性能上的优势已经很明显了——gRPC 长连接替代了 HTTP 短连接，注册和配置推送的延迟大幅下降。

---

Nacos 和 CNCF 的关系

2020年，Nacos 进入了 CNCF （Cloud Native Computing Foundation）的 Sandbox 项目。

这意味着它不只是阿里的项目。它的开源治理、社区运营、技术方向，都在向国际标准对齐。

截止到2026年，Nacos 在 CNCF 已经升级到了 Incubating 阶段，社区贡献者超过 500 人。

---

总结

这篇文章讲了四件事：

1. Nacos 是 Naming and Configuration Service 的缩写，定位是微服务基础设施一站式平台。
2. 它源自阿里内部超过10年的服务发现和配置管理实践经验，不是拍脑袋造出来的。
3. 在 Spring Cloud Alibaba 生态里，Nacos 是地基。
4. Eureka 停更、Apollo 只做配置，Nacos 在当前时间点是唯一一个同时搞定服务发现和配置管理的活跃开源项目。

---

如果你正在选型微服务基础设施，或者团队还在用 Eureka + Apollo 的组合，建议把这篇文章转发到技术群里。评论区告诉我你们现在用的什么方案，我帮你看看适不适合切 Nacos。