Nacos 3.0 正式版本发布啦！升级 MCP Registry，围绕着 MCP 服务管理，MCP 多种类型注册，包含 MCP Server 注册、编排、动态调试和管理，并且提供 Nacos-MCP-Router 可以进行 MCP 动态发现，可以自动安装、代理 MCP Server，全生态面向 AI Registry 进行升级；升级安全架构，默认开启鉴权，基础架构一系列升级，作为云原生时代的基础设施级产品，Nacos 3.0 不仅是技术能力的跃升，更是以更高效、安全的方式帮助用户构建云原生 AI 应用架构！
一、Nacos 3.0 背景
Nacos /nɑ:kəʊs/是 Dynamic Naming and Configuration Service 的首字母简称，定位于一个更易于构建云原生 AI 应用的动态服务发现、配置管理和服务管理平台。从 2018 年 7 月开始宣布开源以来，已经走过了第六个年头，在这六年里，备受广大开源用户欢迎，收获许多社区大奖。Nacos 在社区共同的建设下不断成长，逐步的开始帮助用户解决实际问题，助力企业数字化转型，目前已经广泛的使用在国内的公司中，根据微服务领域调查问卷，Nacos 在注册配置中心领域已经成为国内首选，占有 50%+ 国内市场份额，被各行各业的头部企业广泛使用！
Nacos 3.0 提升安全性，整体架构安全拆分，默认开启鉴权，并且支持动态数据源密钥等零信任方案；多语言生态，覆盖主流开发语言，Python、GoLang、Rust 作为重要部分，发布多个核心组件，可以打通 K8S 生态的 Service / ConfigMap / Secret 数据，面向全场景可以作为统一管理平台；
Nacos 发布 MCP Registry，实现存量应用接口“0改动”升级到 MCP 协议
MCP 的发展速度之快，似乎超出了大部分人的想象。今年2月，Cursur、Winsurf、Cline 均开始引入 MCP，近日 OpenAI 宣布支持 MCP，国内百度地图、高德地图陆续发布 MCP Server，还有一众非常活跃的提供 MCP 托管和中间件服务的供应商，MCP 生态正呈现越加丰富和成熟的发展态势。
虽然 AI 在短期内依旧面临 ROI 的考验，但几乎所有人都不会怀疑他的未来，都不希望错过这一场“军备竞赛”。问题随之而来，存量业务架构中的 API 改造成 MCP Server，既面临时间成本，还有人力上的挑战。企业对能提升 MCP 构建效率的开源和商业方案愈加渴望。
一、“0改动”适配 MCP Server
Nacos 作为 MCP Registry，扮演控制面的角色，不仅管理 Tool 的元信息，还可以把存量 API 转化成 MCP 协议。
Nacos 可以帮助应用快速把业务已有的 API 接口，转换成 MCP 协议接口，结合 Higress AI 网关，实现 MCP 协议和存量协议的转换。其中，Nacos 提供存量的服务管理和动态的服务信息定义，帮助业务在存量接口不改动的情况下，通过 Nacos 的服务管理动态生效 Higress 网关所生成的 MCP Server 协议。
借助 MCP 的发展契机，Nacos （Naming and Configuration Service）正从构建云原生应用向云原生 AI 应用的动态服务发现、配置管理和服务管理平台开源项目进行演进 ，近期 Nacos 即将发布3.0 正式版本，会体系化面向 AI 架构进行升级。
为什么能实现“0代码”适配 MCP Server
我们先看一下普通的调用是如何发生。
首先，调用者需要知道服务提供者的地址(一个域名或者是一个 IP)，之后调用者根据提前约定好的参数，对接口进行调用。调用流程图如下：
在日常开发中，我们已经知悉当前的提供者的接口集合、接口和接口参数的具体作用，所以可以基于这些上下文，在业务代码中写入调用逻辑，实现服务间的调用。对模型而言，这些调用上下文也是必须的，模型也需要知道服务提供者的接口集合以及接口的详细描述，才能根据上下文进行接口调用。
因此，对于已经使用 Nacos 作为注册配置中心的存量服务而言，Nacos 中已经存储了服务的调用地址，只需要增加服务的接口信息就能实现模型来调用上下文。
为此，我们引入了“应用全局描述”来描述当前应用以及接口的详细信息，通过统一的接口描述协议对Nacos 中的服务进行 MCP 化改造。对于之前未注册在 Nacos 中的服务，只需要通过 Nacos 持久化服务发现手动注册即可。在配置完服务相关信息之后，MCP 协议需要的相关数据都已经齐全了，接下来就需要考虑如何将这些数据通过 MCP 协议暴露出去，这里我们通过 Higress 的插件机制完成 MCP 协议的暴露能力。调用流程图如下：
Nacos 转化 MCP 的具体实现原理
MCP 协议目前支持多种资源（Tool、Prompt、Resource 等），我们对使用量较高的 Tool 进行了优先实现，再借助 Higress 提供的统一的 SSE 协议支持，便加速了 MCP Server 的构建。
实现原理上，我们通过在 Higress 中的 MCP Server 插件实现了 Nacos 中管理的 Tools 的暴露，对外通过 MCP 协议暴露普通 HTTP 服务，需要先完成两件事，实现原理图如下：
- 暴露 tool/list 接口，由 Higress 代理返回所有的 Tool 列表
tool/list 方法主要负责将当前 MCP Server 支持的 Tool 的详细信息列表返回给客户端，返回信息包含 Tool 的作用描述和 Tool 的参数描述（包含类型，作用等），然后通过将 Nacos 存储的描述信息转化为标准的 MCP 协议里的 tool/list 结果，返回给客户端。
Nacos 中会注册多个服务，每个服务会有多个接口，每一个接口映射为一个 Tool，Tool 的描述信息就是接口的描述信息，之后根据接口名，将所有服务中的所有 Tool 的服务名等生成全局唯一的 Tool 名称，然后将这些 Tool 聚合为当前的 Tool 列表，返回给 MCP Client。
- 协议转化，对 MCP 协议的 Json RPC 转化为普通 HTTP 请求，并转发到后端服务
当 MCP Client 要调用 Tool 的时候，Higress 将 tool/call 的 Json RPC 请求解析出来，通过用户配置的参数映射信、Path、后端地址等信息，Higress 生成后端的 HTTP 调用请求，并进行调用。调用完成后，再将后端的调用结果包装供标准的 tool/call 接口调用的返回结果。
在整体实现中，Nacos 作为 MCP Registry，扮演控制面的角色来管理 Tool 的元信息，Higress 在数据面做协议转换和 RPC 调用。存量服务只需要添加接口描述即可，无需做任何改动。
使用 Nacos 管理 MCP 的优势
存量 API 可以快速构建 MCP Server：Nacos 集成 Higress 的方案可以让用户快速，0代码的构建成MCP Server，快速跟进 MCP 协议；
MCP 信息动态下发实时生效：MCP 描述信息、Tools 以及 Prompt 都需要进行调试，才能达到更好效果，Nacos 可以帮助管理和下发信息，更高效的调试描述；
MCP信息历史版本管理：Nacos 会管理和存储 MCP 信息历史版本，方便进行 Diff 对比差异，方便进行快速回滚；
MCP信息灰度管理：Nacos 在 MCP 信息生效的时候，可以进行灰度分批生效，方便对比 MCP 信息效果；
密码配置加密：MCP 信息里以及调用 API 过程中，需要密码等敏感信息，Nacos 提供了敏感信息加密的能力，帮助更安全的使用 MCP；
MCP 返回格式 JSON 转换 XML：和大模型交互都有体感，对模型来说，JSON 没有 XML 格式好用，所以在 MCP 返回信息格式上，Nacos 可以帮助 MCP 把返回格式从 JSON 变成 XML，方便大模型理解；
MCP 服务管理及健康检查：MCP 服务会越来越多，Nacos 有大规模服务管理能力，并且持续在迭代过程中，为 MCP 做健康检查、实时更新、负载均衡，起到 MCP 服务发现中心的托管作用。