十年前的Nacos又重出江湖了

十年前与Nacos的遇见

2015年是我参加工作的第二年，那时微服务、Docker正处于如火如荼的时期。当年我在华为的DigitalView产品线，部门的目标是要建立自动化运维产品，让公司线上的项目达到7*24小时无需人员值守的目标。

由于产品线和团队都是公司新成立的，也采用了当时市面最流行的微服务架构（公司内部自研DigitalFoundary）。而Nacos没有作为微服务的注册中心，在项目中只是一个支持发布订阅的高性能开源组件。

当时的我不知道Nacos只是阿里的一个内部产品，还没有进行开源。2017年我从华为离职出去面试时，还大言不惭的跟面试官聊我们内部使用了高性能的消息中间件Nacos，把面试官都听懵了，Nacos是个啥？

Nacos的演进及火爆

“Nacos”  这个名字本身也体现了这一融合：

• Naming：命名，代表服务发现（来自 VIPServer）。
• Configuration：配置，代表配置管理（来自 Diamond）。
• Service：服务，代表其核心目标。

阶段一：前世与孵化 (2018年之前) - “阿里巴巴的内部岁月”

Nacos 并非凭空诞生，它的设计思想源于阿里巴巴长达十年的内部技术沉淀。

• ConfigServer：早期的配置管理工具。
• Diamond：淘宝的持久配置中心，奠定了 Nacos 配置管理的基础。
• VIPServer：淘系的高可用服务发现系统，解决了大规模服务注册与发现的问题。

阶段二：开源与崛起 (2018-2019) - “开启开源之路”

• 2018年6月：在 阿里巴巴首届云原生爱好者沙龙 上，Nacos 正式宣布开源，并发布了第一个版本 0.1.0。它的出现立刻引起了广泛关注，因为它提供了一个比 Netflix Eureka + Spring Cloud Config + Apollo 等组合更轻量、更简单的选择。
• 2019年：Spring Cloud Alibaba 项目正式毕业，Nacos 作为其服务发现和配置管理的核心组件，迅速被广大 Java 和 Spring Cloud 开发者所接受和采用，迎来了用户数量的暴增。
• 2019年5月：Nacos 入选 CNCF Cloud Native Landscape（云原生全景图） ，标志着其被国际云原生社区所认可。

阶段三：成熟与引领 (2020-2022) - “成为顶流，性能革命”

• 2020年5月：发布 1.0.0 GA (General Availability)  版本，标志着其已经足够稳定，可以用于大规模生产环境。

• 2021年1月：这是一个里程碑事件。Nacos 正式从 Apache 软件基金会的孵化器毕业，成为 Apache 顶级项目 (TLP) 。这意味着 Nacos 拥有了健康、开放、国际化的社区治理模式，其项目的可持续性和公信力得到了极大提升。

• 2021年12月：发布 Nacos 2.0。这是一个具有性能革命的版本。

  • 通信模型升级：将传统的 HTTP 短轮询模式升级为基于 gRPC 的长连接双向流，使得配置推送和服务心跳的性能提升了约 10 倍，支持了百万级别的服务实例。
  • 内核持续优化：在一致性协议、存储模型等方面做了大量优化，稳定性和扩展性极大增强。

至此，Nacos 无论在功能、性能还是社区生态上，都已然成为国内服务发现与配置管理领域的事实标准。

阶段四：未来与超越 (2023年至今) - “拥抱云原生与AI原生”

Nacos 并没有停止进化，而是继续向前看，拥抱新的技术浪潮。

• 深度融合 Kubernetes：积极推动 Nacos 与 K8s 生态的集成，例如通过 Nacos-Sync 实现与 K8s Service 的双向同步，让 Nacos 在混合云（虚拟机 + 容器）场景下继续发挥核心作用。

• 拥抱 AI 原生：这是 Nacos 目前最前沿的探索。从 Nacos 2.3 版本开始，支持 MCP (Model Context Protocol)  协议。

  • 新定位：Nacos 的定位从“微服务注册配置中心”升级为“微服务与AI一体化平台”。
  • 新角色：Nacos 可以作为一个 MCP Server，将其管理的服务、配置、提示词（Prompts） 、API文档等资源动态地提供给大语言模型 (LLM) ，让 AI 能够感知实时系统状态，成为真正的“智能运维大脑”。

Nacos 的发展历程是“站在巨人肩膀上”的创新：

1. 起源：继承了阿里内部超大规模业务场景的实战经验。
2. 崛起：通过开源和与 Spring Cloud 生态的完美集成，迅速占领市场。
3. 成熟：通过进入 Apache 和 2.0 架构升级，确立了其统治级地位。
4. 超越：积极拥抱云原生和 AI 原生，不断拓展其边界和价值。

Nacos的技术架构

Nacos 的架构设计体现了其作为“服务注册与发现”和“动态配置管理”双核心平台的理念。

架构分层与核心组件详解

1. 客户端层 (Client Layer)

• 角色：Nacos 的使用者。
• 实体：所有需要注册到 Nacos 或从 Nacos 获取配置的微服务实例。
• 通信方式：通过 SDK、OpenAPI 或控制台与 Nacos Server 交互。

2. 接入层 (Access Layer)

• 角色：对外暴露访问入口，处理客户端请求。

• 组件：

  • OpenAPI：提供 RESTful HTTP 接口，允许任何语言的服务通过 HTTP 客户端与 Nacos 交互。
  • SDK：为不同语言（主要是 Java）封装了高级 API，简化开发，内部通常使用 OpenAPI 或更高效的 gRPC 进行通信。
  • 控制台 (Console) ：提供图形化界面，方便用户进行服务管理、配置编辑、权限设置和状态监控。

3. 核心层 (Core Layer) - Nacos Server 的心脏

这是最复杂和关键的一层，实现了 Nacos 的所有核心功能。

• 命名服务模块 (Naming Service)

  • 功能：负责处理服务的注册、发现、健康检查及元数据管理。
  • 一致性协议：默认使用自研的 Distro 协议（AP 模式），保证高可用和最终一致性。对于某些需要强一致性的场景，可以切换到 Raft 协议（CP 模式）。

• 配置服务模块 (Config Service)

  • 功能：负责配置的 CRUD、版本管理、灰度发布、监听查询和动态推送。
  • 一致性协议：使用 Raft 协议（CP 模式），确保配置数据的强一致性，避免不同节点读取到不同版本的配置。

• 一致性协议层 (Consistency Module)

  • 角色：架构的基石。这是一个抽象层，将上层的业务逻辑与底层的具体一致性算法实现解耦。
  • 实现：根据数据类型和场景，选择调用 DistroConsistencyServiceImpl 或 PersistentConsistencyServiceImpl（内部基于 Raft）。

• 存储抽象层 (Storage)

  • 角色：支持多种数据存储方式。

  • 实现：

    • 服务数据：默认存储在内存中，并通过 Distro 协议在集群间同步。也可以选择集成外置 RDBMS（如 MySQL）进行持久化（企业版特性）。
    • 配置数据：必须持久化，默认使用内嵌数据库 Derby，生产环境必须切换为集群模式的外部数据库（如 MySQL）。

4. 插件层 (Plugins Layer)

• 角色：提供可扩展的增强功能，体现了 Nacos 的“架构友好”特性。

• 组件：

  • 认证授权 (Auth) ：基于 SPI 机制，可以对接公司的单点登录系统。
  • 监控 (Metrics) ：暴露大量 metrics 数据，可集成 Prometheus 等监控系统。
  • 日志 (Logging) ：记录详细的操作和系统日志。
  • 通信协议 (gRPC) ：Nacos 2.0 开始，长连接和配置监听都基于 gRPC，大幅提升了性能和解耦能力。

5. 持久化层 (Persistence Layer)

• 角色：数据的最终落地方。

• 选择：

  • Derby：内嵌数据库，适用于测试和单机模式，不适用于生产集群。
  • MySQL：生产环境的标准选择。Nacos 集群的所有节点都连接同一个 MySQL 集群，通过数据库来实现最终数据的统一。

核心交互流程

1. 服务注册：

   • 服务实例启动 → 通过 SDK 调用 Naming Service 的注册接口 → 写入内存并通过 Distro 协议异步同步到其他节点。

2. 配置获取：

   • 服务实例启动 → Config Service 从数据库拉取配置 → 初始化应用上下文。

3. 配置监听与推送：

   • 服务实例启动后 → 与 Config Service 建立 gRPC 长连接 → 监听配置变化。
   • 控制台修改配置 → Config Service 通过 Raft 协议持久化到数据库 → 通知所有监听该配置的客户端 → 客户端通过长连接收到变更通知 → 拉取新配置并触发本地刷新 (@RefreshScope)。

4. 服务发现：

   • 服务消费者查询服务提供者列表 → Naming Service 返回本地内存中缓存的健康实例列表（可能不是最新，但最终一致）。

设计特点总结

• 模块化设计：核心功能（Naming/Config）、一致性协议、存储都是独立的模块，易于理解和扩展。
• 双模式一致性：根据场景灵活选择 AP 或 CP，平衡了可用性和一致性。
• 扩展性：通过 SPI 和插件机制，几乎所有组件（如认证、存储、通信）都可以被扩展和替换。
• 高性能：服务数据基于内存，配置监听基于 gRPC 长连接，极大提升了性能。
• 生态友好：提供 OpenAPI、多语言 SDK，并能轻松与 Spring Cloud、Dubbo 等主流框架集成。

这个架构使得 Nacos 能够以一个轻量级的体量，高效、稳定地承担起大规模微服务架构下的治理重任。

Nacos的AP/CP核心技术

Nacos 的 AP 和 CP 模式并不是指整个 Nacos 服务器是 AP 或 CP 系统，而是指其不同功能模块在实现分布式一致性时，针对不同的数据域（Data Domain）  采用了不同的策略，以适应不同的场景。

简单来说：

• 服务注册（Naming Service - Service）  默认采用 AP 模式，保证高可用。
• 配置管理（Config Service）  和领导者选举等核心元数据管理采用 CP 模式，保证强一致性。

1. Nacos 的 AP 模式体现：服务发现 (Service Discovery)

设计目标：  为了服务的高可用性和可扩展性。在服务发现场景下，短时间内读到旧数据（比如某个已下线的服务实例）通常比完全无法读到数据（整个注册中心挂掉）更能被接受，因为客户端通常有重试和负载均衡等容错机制。

实现方式：  Nacos 基于自研的 Distro 协议。这是一个弱一致性的、基于内存的协议。

工作流程（AP场景）：

1. 写操作（服务注册） ：一个服务实例向 Nacos 集群中的某个节点（比如 Node A）发起注册请求。
2. 异步复制：Node A 会立即将注册信息写入本地内存，并返回成功给客户端，保证快速响应。随后，Node A 会异步地将这条数据同步给集群中的其他节点（Node B, Node C）。
3. 读操作（服务发现） ：客户端可以从集群中的任意节点查询服务列表。每个节点返回的是它当前内存中的数据，这些数据可能不是最新的（例如，一个刚注册的服务，在数据同步完成前，从其他节点可能还查不到）。

AP模式的特点：

• 高可用：每个节点都能独立处理读写请求，任何一台机器宕机都不会影响整个集群的服务发现功能。
• 最终一致性：数据通过异步复制，最终所有节点会达成一致，但在同步期间存在短暂的不一致。
• 高性能：写入操作无需等待所有节点确认，延迟低，吞吐量高。

适用场景：  核心的服务注册与发现功能。这是 Nacos 最常见的用法，也是它默认的模式。

2. Nacos 的 CP 模式体现：配置管理 (Configuration Management) & 核心元数据

设计目标：  为了数据的强一致性。在配置管理场景下，所有客户端在任何节点读到的配置都必须是完全相同的。发布一个新配置，必须让所有节点都成功存储后，才认为发布成功，避免部分节点生效、部分节点未生效导致的系统行为不一致。

实现方式：  Nacos 使用标准的 Raft 协议。这是一个强一致性的分布式共识算法。

工作流程（CP场景）：

1. 写操作（发布配置） ：用户向 Nacos 集群发布一条新配置。
2. 同步复制：接收到请求的节点会作为 Leader，将这次写操作作为一条日志复制给集群中的大多数（N/2+1）节点。
3. 提交确认：只有当大多数节点都成功将日志写入磁盘后，Leader 才会提交这条日志，并将成功结果返回给客户端。
4. 读操作（获取配置） ：客户端从任意节点读取配置，由于数据是强一致的，所以读到的结果保证是最新且一致的。

CP模式的特点：

• 强一致性：所有成功返回的写操作，其后继的读操作一定能读到最新值。数据绝对一致。
• 可用性降低：在网络分区（脑裂）或节点宕机导致无法形成“大多数”时，整个系统将无法进行写操作，甚至会拒绝读操作，牺牲了部分可用性（A）来保证一致性（C）。
• 性能开销：每次写操作都需要磁盘 I/O 和多数节点的网络通信，延迟比 AP 模式高。

适用场景：

• 配置管理：必须保证所有实例拿到相同的配置。
• 核心元数据存储：如 Nacos 自身的命名空间、用户权限等信息的管理。

总结与对比

特性维度	AP 模式 (服务注册与发现)	CP 模式 (配置管理)
核心协议	Distro (Nacos 自研)	Raft (标准分布式共识算法)
一致性模型	最终一致性	强一致性
数据同步方式	异步复制、 gossip	同步复制、需多数节点确认
读写性能	高（内存操作，无需等待）	相对较低（需磁盘IO和网络同步）
可用性	高（任何节点宕机不影响整体服务）	较低（发生网络分区时，少数派节点不可用）
设计目标	保障服务注册发现的高可用和分区容错	保障配置数据的全局强一致
典型应用	微服务的实例注册、健康检查、服务查询	应用配置的动态管理、全局开关

Nacos和Spring家族的集成

核心组件角色说明

组件	角色说明
Microservice A/B	业务微服务，既是服务提供者，也是消费者。
Spring Cloud Application	微服务应用的 Spring Cloud 框架层。
SCA Nacos Client	Spring Cloud Alibaba 提供的客户端，是集成 Nacos 的核心。
Nacos Server Cluster	Nacos 服务端集群，提供高可用的服务注册中心和配置中心功能。
MySQL	外部数据库，用于持久化 Nacos 中的配置数据（服务数据默认使用 Raft 协议存储，无需数据库）。

流程一：服务注册与发现 (对应图中蓝色路径)

1. 服务注册 (Registration) :

   • 微服务 A (Provider) 启动，其内部的 SCA Nacos Discovery Client 自动将自身的服务名 (spring.application.name)、IP、端口等元数据发送给 Nacos Server 注册中心。
   • 微服务 B 同样执行此注册过程。

2. 服务发现与订阅 (Discovery & Subscription) :

   • 微服务 B (Consumer) 在需要调用微服务 A 时，其 SCA Nacos Discovery Client 会向 Nacos Server 查询名为微服务 A 的健康实例列表。
   • 微服务 B 会订阅微服务 A 的变更。Nacos Server 会记录这个订阅关系。

3. 变更推送 (Notification) :

   • 如果微服务 A 的实例发生变更（如实例下线、新实例上线、健康状态变化），Nacos Server 会主动推送这个变更事件给所有订阅了微服务 A 的消费者（如微服务 B）。
   • 微服务 B 收到通知后，会更新本地的服务实例缓存，确保后续调用基于最新的列表。

4. 远程调用 (Invocation) :

   • 微服务 B 通过 OpenFeign 或  @LoadBalanced RestTemplate 发起调用。
   • Spring Cloud LoadBalancer 会从微服务 B 本地的服务实例缓存中，根据负载均衡策略选择一个微服务 A 的健康实例，直接发起 HTTP 调用

流程二：配置管理 (对应图中绿色路径)

1. 启动拉取 (Bootstrap) :

   • 在微服务 A 应用启动的最初阶段（在初始化 Spring Environment 时），SCA Nacos Config Client 会根据配置的规则（如 {spring.application.name}-{profile}.yaml）向 Nacos Config Server 发起请求，拉取远端的配置。
   • 拉取到的配置会用来初始化应用的上下文。这意味着配置信息在应用启动时就已就绪。

2. 动态监听 (Listening) :

   • 应用启动成功后，SCA Nacos Config Client 会与 Nacos Config Server 建立一个长轮询连接，持续监听自己所使用的配置是否发生了变更。

3. 配置变更 (Change) :

   • 运维人员在 Nacos 控制台上修改并发布了新的配置。
   • Nacos Config Server 会检测到配置的 dataId 发生了变更。

4. 配置推送 (Push) :

   • Nacos Config Server 会向所有正在监听这个 dataId 的 Client 推送配置变更事件。
   • Client 收到事件后，会重新拉取最新的配置内容。

5. 动态刷新 (Refresh) :

   • SCA Nacos Client 在拿到新配置后，会触发 Spring Cloud 的 RefreshScope 机制。
   • 所有被 @RefreshScope 注解的 Bean（或其内部使用 @Value 注入的配置）会被重新创建，业务逻辑中用到的最新配置值即刻生效，整个过程无需重启应用。

Nacos和AI大模型的集成

Nacos 2.3 版本开始引入的对 MCP (Model Context Protocol) 协议支持的架构设计。这是一个非常前沿且重要的特性，标志着 Nacos 从传统的微服务治理中心向 AI 原生时代的一体化治理平台演进的关键一步。

核心概念：什么是 MCP？

MCP 是一个由 Google 等公司提出的开放协议，全称为 Model Context Protocol。它的核心目标是标准化 AI 模型与外部工具/数据源之间的通信方式。

你可以把它想象成 AI 世界的  “服务发现”  或  “配置管理”  协议：

• 在微服务中，应用需要从 Nacos 动态地发现服务和获取配置。
• 在 AI 应用中，大语言模型 (LLM) 需要动态地获取工具（Tools/Functions） 、知识（Knowledge/Context）  和 提示词（Prompts）  来更好地完成任务。
• MCP 就是让 LLM（客户端）能够从各种资源服务器（Server）动态发现和获取这些资源的标准协议。

Nacos 作为 MCP Server 的架构设计

Nacos 对 MCP 的支持，其本质是将自身重塑为一个 MCP 资源服务器（MCP Server） ，将其管理的服务、配置、元数据等资源暴露给 AI 客户端（如 LLM、AI 应用平台）。其整体架构如下所示：

架构核心组件详解

1. MCP 客户端 (MCP Clients)

• 角色：资源的消费者。
• 实体：这可以是 大型语言模型 (LLM) （如 Gemini、DeepSeek等）、AI 应用平台（如 Dify, LangChain）、或自定义的 AI Agent。
• 行为：它们通过 MCP 协议与 Nacos Server 建立连接，查询、订阅所需的资源（如：“给我获取一下用户服务的API文档”、“获取一下最新的产品列表配置”）。

2. Nacos MCP Server 适配层 (Nacos MCP Server Adapter)

• 角色：这是整个架构的核心创新点和协议转换枢纽。它本质是一个嵌入在 Nacos Server 中的协议适配器。

• 功能：

  • 协议实现：实现 MCP 协议规范，包括连接管理（如通过 WebSocket 或 SSE）、请求/响应模型、双向通信等。

  • 资源抽象与映射：将 Nacos 内部的核心数据模型抽象并映射为 MCP 协议定义的资源（Resources）  和工具（Tools） 。

    • 服务 (Services)  -> nacos://services/{serviceName}：将注册的服务实例列表作为资源暴露。
    • 配置 (Configurations)  -> nacos://configs/{dataId}：将配置内容作为资源暴露。
    • 提示词 (Prompts)  -> nacos://prompts/{promptName}：新增，将存储在 Nacos 中的提示词模板作为资源管理。

  • 权限控制：集成 Nacos 的 Auth 模块，对 MCP 客户端的请求进行认证和授权。

3. Nacos 核心模块 (Nacos Core)

• 角色：资源的存储和管理中心，能力提供者。
• 行为：Nacos MCP Server 适配层并不直接存储数据，而是作为一层代理，接收来自 MCP 客户端的请求，然后调用 Nacos Core 的现有能力（如 namingModule 和 configModule）来获取或修改数据。这保证了功能的复用性和一致性。

4. 资源变更通知机制

• 这是 MCP 协议的一个强大功能：服务器可以向客户端主动推送资源变更。

• 工作流程：

  1. AI 客户端通过 resources.subscribe 方法订阅它关心的某个 Nacos 资源（如一个配置项）。
  2. 当该配置在 Nacos 控制台上被修改并发布时，Nacos Core 会触发一个变更事件。
  3. Nacos MCP Server 适配层捕获到这个事件，并通过 MCP 协议立即将变更通知给所有订阅了该资源的 AI 客户端。
  4. AI 客户端收到通知后，可以实时更新其上下文或知识，无需轮询，保证 AI 永远基于最新的信息进行决策和回答。