Nacos是什么-平芜编程栈

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

先看一个数字

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

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

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

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

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

Nacos 是四个单词的缩写

Naming andConfigurationService。

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

拆开来看更清楚：

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 分别实现了这两套抽象：

// 服务发现——你连代码都不用改@AutowiredprivateDiscoveryClientdiscoveryClient;// 获取用户服务的所有实例List<ServiceInstance>instances=discoveryClient.getInstances("user-service");// 配置管理——加个注解就行@RestController@RefreshScope// 配置变了自动刷新publicclassOrderController{@Value("${order.timeout:3000}")privateinttimeout;}