作者：杨翊（席翁），柳遵飞（翼严），罗鑫（子葵）

Nacos/nɑ:kəʊs/是 Dynamic Naming and Configuration Service 的首字母简称，随着 Nacos 3.0 的发布，定位由“更易于构建云原生应用的动态服务发现、配置管理和服务管理平台”升级至“ 一个易于构建 AI Agent 应用的动态服务发现、配置管理和 AI 智能体管理平台”。

Nacos 从 2018 年 7 月宣布开源以来，已经走过了第六个年头，在这六年里，备受广大开源用户欢迎，收获许多社区大奖。Nacos 在社区共同的建设下不断成长，逐步开始帮助用户解决实际问题，助力企业数字化转型，目前已经广泛使用在国内的公司中，根据微服务领域调查问卷，Nacos 在注册配置中心领域已经成为国内首选，占有 50%+国内市场 份额，被各行各业的头部企业广泛使用。在此期间，Nacos 的部署包下载量突破 300w 次，官网每年访问用户数超过 90w 人，被国内各主流云厂商托管服务。

随着 AI 时代到来以及 Nacos 3.0 版本的正式发布，Nacos 未来的演进目标以及架构也会随之升级。本文会对比 Nacos 3.0 与 Nacos 2.0 的架构异同，对 Nacos 3.0 的主要功能原理进行介绍。

1. Nacos 2.0 架构回顾

Nacos 2.0 的架构主要聚焦对性能和可扩展性进行优化和提升。

对于性能升级，Nacos 2.0 通过将通信模型从 HTTP 升级至 gRPC，从短连接模型升级到长连接模型，使得 Nacos 的通信吞吐量中极大提升；同时配合数据存储和数据结构模型的升级，进一步减少核心操作所涉及的步骤和链路，最终实现性能的 10 倍提升。

关于可扩展性升级，Nacos 2.0 通过将一些具有个性化需求的通用能力进行抽象，进行插件化改造的方式，允许 Nacos 用户和运维人员能够开发自定义插件，适配个人或企业的个性化需求。

虽然 Nacos 2.0 在性能和可扩展性实现了一些突破，但仍然还存在一些挑战。

其中一个主要的挑战就是 Nacos 的安全风险。比如：Nacos 2.0 中所有的 HTTP API 均使用 8848 端口，这其中及包含了 1.X 客户端使用的 API，也包含了运维人员以及控制台的 API。不同类型的 API，对于权限的需求其实是不同的，对于网络访问的连通性要求也是不同的。使用单端口并且使用唯一的鉴权开关，导致了网络的访问控制，以及鉴权控制都不是很灵活。许多用户为了方便使用，将此端口暴露在办公网甚至公网环境，同时未开启鉴权，这就造成了安全风险。

另一个问题就是默认命名空间的使用，Nacos 最初的版本中定义了命名空间作为数据资源的强隔离属性，不同命名空间之间的服务和配置不能互相发现和获取；但在最初版本中因为历史原因，注册中心和配置中心对于默认命名空间的处理方式有一定的不统一，这导致了许多用户在使用默认命名空间时经常配置错误或者出现疑惑；并且在 Nacos 2.0 提供各种插件能力之后，许多插件实现时需要额外工作进行适配，严重阻碍了插件的开发以及插件的稳定性。

随着 AI 时代来临，AI Agent 应用的部署形态在之前云原生可弹性可伸缩的基础上，要求更加轻量，更加弹性，例如 FC 场景；在这种要求下，我们需要考虑 Nacos 之前的服务发现和配置管理的能力是否还能承载 AI Agent 的应用的部署。同时，随着越来越多的 AI Agent 的应用贯穿业务全线，Nacos 能否帮助更好地管理 AI Agent 的应用，是 Nacos 在当前的挑战，同时也是新的机遇。

为了应对这些挑战以及机遇，Nacos 3.0 架构也做了对应的升级。目标是在 AI 时代成为更安全的 Registry。设计理念也由之前的一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台升级为一个易于构建 AI Agent 应用的动态服务发现、配置管理和 AI 智能体管理平台。

2. Nacos 3.0 架构

2.1 Nacos 3.0 整体架构解析

Nacos 3.0 升级后的整体架构仍然以一致性协议、通信模块、其他模块等通用功能模块为基座，承载出注册中心、配置中心、AI Registry、协议增强等功能；同时通过各类多语言 SDK，桥接各个生态组件。架构的左右两侧，分别是 Nacos 的插件以及 Nacos 的一些拓展组件，它们一起构成了 Nacos 3.0 的整体架构。

我们来重点关注 Nacos 3.0 的新增能力，即图中绿色和棕色的部分。

这其中既包括对原本注册配置中心的增强功能，即模糊订阅，也包括了对 AI 相关能力的实现和规划，如 MCP 和管理，MCP Router，动态 Prompt 及 A2A 协议支持；同时也通过支持 xDS 协议及 Nacos Controller 继续加强和探索 Mesh 生态。

2.2 Nacos 3.0 AI Registry 架构

了解完 Nacos 3.0 的整体架构，接下来我们来看 Nacos AI 中心（AI Registry）的架构设计。作为 Nacos 3.0 规划中最重要的能力，Nacos AI Registry 的架构被分为 3 个层次，分别是模型层、工具层和应用层。

在模型层中，主要通过对 AI 模型中一些常用的动态参数，比如 Prompt、学习率、联网参数等进行管理，采取复用在云原生应用中配置动态管理和分发能力的方式，帮助 AI 智能体在模型层进行快速调整及试错。

模型层之上是工具层，工具层主要帮助 LLM 模型和提供数据的 MCP 工具之间进行自动的发现、注册以及检索等能力，复用在云原生应用中服务的动态注册、管理、发现的能力，帮助 AI 智能体应用快速及便捷地发现 MCP 工具，同时快速过滤无关工具，减少 Token 损耗。

最顶层是 Agent 的应用层，实现 AI 应用与 AI 应用之间的发现与协作。目前规划是通过支持 A2A 等社区标准协议，同时配合 Spring AI Alibaba 等 AIAgent 应用框架，帮助 AIAgent 应用便捷的自动注册自身 AI 应用，同时发现其他 AI 应用，并能够像云原生应用一样，进行任务的分发以及结论的构成。

如果从功能视角出发，Nacos AI Registry 又可被分为针对大模型 LLM 的模型动态配置调优，针对 AI 应用平台的应用开发管理以及针对 AI Agent 应用的运行时能力增强。Nacos 希望通过不同的功能点，帮助 AI 应用像微服务云原生应用一样，能动态的调整 Prompt，学习率等参数，无需重新发布，从而帮助 AI 应用简化开发，调试过程中的繁琐操作，提高 AI 应用的开发和运行效率。

2.3 Nacos 3.0 安全架构

Nacos 2.0 中面临的一个主要的风险就是 Nacos 所有的 HTTP OpenAPI 均通过统一的端口进行暴露，同时使用了统一的鉴权开关，这使得使用者必须在便捷性和安全性中作出取舍，导致在许多部署的环境中可能存在安全风险。

Nacos 3.0 为了解决这个问题，从 Nacos 的部署架构上作出演进，独立控制台部署，拆分鉴权开关，分类 API 并默认开启控制台及管控类 API 的鉴权。

同时配合配置加密插件，TLS 传输，来实现 Nacos 3.0 的零信任安全架构。

除了针对 Nacos 自身的安全零信任架构外，Nacos 3.0 还将与 Druid，Spring AI Alibaba/Spring Cloud Alibaba 等开源社区，及 KMS 等安全云产品合作，提供面向应用侧的数据源运行期动态轮转方案。

在这套解决方案中，数据源的凭据始终由 KMS 等凭据托管平台和系统保存，全程无人工传递和配置的过程。用户可以设置定期进行凭据的自动轮转，或在怀疑密钥泄漏时手动触发凭据轮转；触发后会通过 Nacos 动态无损的将新的加密凭据通知到 Druid 或 Spring AI Alibaba/Spring Cloud Alibaba，进行凭据的动态刷新和无损替换。这种方式极大降低了凭据泄漏的可能性，同时显著提高了安全性及出现安全风险时的收敛恢复速度。

3. Nacos MCP Registry

3.1 Nacos MCP Registry 架构

Nacos 3.0 最主要的能力升级就是作为 MCP Registry，支持了 MCP 服务的管理能力。

Nacos MCP Registry 支持三类 MCP 服务的注册方式：

第一类是将存量 HTTP 或 RPC 的服务，通过声明自动转化为 MCP 服务，配合 Higress 的协议转换能力，实现 0 代码改造成 MCP 服务协议，如何将存量 API 转化为 MCP 服务，详情可参见文档^【1】。

第二类就是新构建的 MCP 服务注册，配合 Spring AI 等 AI Agent 应用框架和 Nacos-MCP 的 sdk，能够做到像微服务一样自动注册到 Nacos 中进行统一的管理和维护，如何通过 Spring AI 或 Nacos-MCP 的 sdk 进行 MCP 服务的自动注册与发现，请参见文档^【2】。

第三类就是已经构建好的或其他供应商提供的 MCP 服务，可以导入到 Nacos 中，进行其描述、工具列表、工具 Schema 等内容的动态修改和维护，让调试 MCP 服务变得更加简单。

3.2 Nacos MCP Router

Nacos 3.0 支持用户通过 3 种方式发布 MCP 服务，并对 MCP 服务的元数据和版本进行管理，但如果最终不能将这些元数据和版本信息进行实际的使用，这些信息就没有意义。

因此 Nacos 3.0 提供 Nacos MCP Router 帮助终端使用者无需实际感知 MCP 服务列表，即可自动发现和使用需要的 MCP 服务。

Nacos MCP Router 提供两种工作模式，动态路由和动态代理。

动态路由模式将会根据 LLM 所提供的关键字信息，对注册在 Nacos 中的 MCP 服务进行相关性过滤和筛选，选择出与关键字相关的 MCP 服务进行实际的使用，从而减少对 LLM 上下文的消耗，实现路由 MCP 服务的能力。

而代理模式能够进行 MCP 协议的转换，将 stdio 和 sse 类型的 MCP 服务，代理成 streamable 类型的 MCP 服务。代理模式下的 Nacos MCP Router 不根据关键字进行筛选，仅是将注册在 Nacos 中的 stdio 和 sse 类型的 MCP 服务，转化成 streamable 类型，同时应用用户在 Nacos 上修改和编辑的 Tool 描述信息，将转化后的 MCP 服务列表，返回给 LLM 供其使用。

4. Nacos 3.0 RoadMap

Nacos 3.0 的目标是成为全面拥抱 AI 时代的服务、配置、AI Registry 平台，因此 Nacos3.0 的 RoadMap 将会逐步实现 AI Registry 的能力，从当前的 MCP 管理，拓展到 Prompt 管理，Agent 的自动注册发现，再到 LLM 模型的参数管理和托管；同时进一步加强注册配置中心的能力和更多相关领域协议的支持（如 DNS，Mesh）。

Nacos 也希望有更多的社区贡献者加入进 Nacos 社区，帮助 Nacos 更快更好的完善和实现 Nacos3.0。

5. 欢迎加入 Nacos 社区

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及 AI 管理。

Nacos 帮助用户更敏捷和容易地构建、交付和管理云原生 AI 应用的平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式、AI 原生范式) 的服务基础设施。

Nacos 3.0 还有很多待完成的功能及大量待探索和开发的领域，欢迎大家扫码加入 Nacos 社区群及 Nacos MCP 社区讨论群，参与 Nacos 社区的贡献和讨论，在 Nacos 社区一起搭把手，让你的代码和能力有机会能在各行各业领域内进行释放能量，期待认识你和你一起共建 Nacos 社区；

“Nacos 相信一切都是服务，每个服务节点被构想为一个星球，每个服务都是一个星系；Nacos 致力于帮助这些服务建立连接赋予智能，助力每个有面向星辰的梦想能够透过云层，飞在云上，更好的链接整片星空。”

Nacos 官网：

https://nacos.io/

Nacos 仓库地址：

https://github.com/alibaba/nacos

“Nacos社区群5”群的钉钉群号：

120960003144

“Nacos MCP 社区讨论群”群的钉钉群号：

97760026913