MCP 架构设计案例剖析：Nacos MCP Registry 实现存量应用接口升级 MCP 协议 原创

Model Context Protocol（MCP）模型上下文协议（如下图所示）是 Anthropic 发布的一种标准化协议，使得 Agent 智能体应用可以方便快捷地与下游异构的数据或者工具进行交互，还不熟悉的同学可以看下这两篇文章《​​王炸！MCP 架构设计深度剖析 & 使用 Spring AI + MCP 四步教你实现 Agent 智能体开发​​​​》、《​​​MCP 架构设计演进：从 Local MCP Server 到 Remote MCP Server 开源架构设计实现​​​》。

最近，两大关键事件标志着 MCP 已从事实标准迈向行业标准：一方面，OpenAI 正式宣布跟进 Anthropic 的 MCP 协议，另一方面，Anthropic 发布了新版本 MCP 协议，在 Remote MCP Server 的场景进行了显著改进。

但是，云原生存量业务架构中的 API 改造成 MCP Server，既面临时间成本，还有人力上的挑战。企业对能提升 MCP 构建效率的开源和商业方案愈加渴望。

阿里 Nacos（Naming and Configuration Service）作为云原生注册配置中心，最近发布了 MCP Registry，让存量业务 API “0改动”就可以适配 MCP Server。

Nacos 在作为 MCP Registry ，承担着控制面板的关键角色。它不仅负责管理 Tool 的元信息，还能将现有的 API 转化为符合 MCP 协议的接口。借助 Nacos，云原生存量业务应用可以迅速将其已有的业务 API 接口转换为 MCP 协议接口，并通过与 Higress AI 网关的结合，实现 MCP 协议与现有协议之间的无缝转换。在这个过程中，Nacos 提供了对现有服务的管理以及动态服务信息的定义，使得业务能够在不改动现有接口的前提下，通过 Nacos 的服务管理功能，动态地应用 Higress 网关生成的 MCP Server 协议。

下文对 Nacos MCP Registry 架构设计详细剖析之。

1、Nacos MCP Regisry 架构设计剖析

第一、Nacos 0代码适配 MCP Server 的架构原理剖析

我们先来了解一下普通的服务调用过程。首先，调用方（Consumer）需要知道服务提供方（Provider）的地址（可以是一个域名或 IP 地址）。然后，调用方根据事先约定好的参数，对服务接口进行调用。整个调用流程如下图所示：

在日常开发中，我们通常已经熟悉了当前服务提供方的接口集合以及接口参数的具体作用。因此，我们可以在业务代码中编写调用逻辑，实现服务之间的调用。对于大模型来说，这些调用上下文同样是必不可少的。大模型需要了解服务提供方的接口集合以及接口的详细描述，才能根据上下文进行接口调用。

对于已经使用 Nacos 作为注册配置中心的存量服务，Nacos 中已经保存了服务的调用地址。我们只需要增加服务的接口信息，就可以实现大模型调用上下文的构建。

为此，Nacos 引入了“应用全局描述”这一概念，用于描述当前应用及其接口的详细信息。通过统一的接口描述协议，我们可以对 Nacos 中的服务进行 MCP 化改造。对于之前未在 Nacos 中注册的服务，我们可以通过 Nacos 的持久化服务发现功能手动进行注册。在配置完服务相关信息后，MCP 协议所需的数据已经完备。接下来，我们需要考虑如何通过 MCP 协议将这些数据暴露出去。这里，我们利用 Higress 的插件机制来实现 MCP 协议的暴露能力。调用流程图如下：

第二、Nacos MCP Registry 整体架构设计剖析

1.Nacos MCP Regisry 架构设计

MCP 协议目前支持多种资源（Tool、Prompt、Resource 等），Nacos 优先实现了使用量较高的 Tool，并借助 Higress 提供的统一 SSE 协议支持，加速了 MCP Server 的构建，整体架构设计如下图所示：

在架构设计上，Nacos 通过在 Higress 中的 MCP Server 插件实现了 Nacos 中管理的 Tools 的暴露。对外通过 MCP 协议暴露普通 HTTP 服务，需要先完成以下两件事：

• 暴露 tool/list 接口

    功能：由 Higress AI 网关返回所有的 Tool 列表。

    实现：tool/list 方法主要负责将当前 MCP Server 支持的 Tool 的详细信息列表返回给 MCP Client。返回信息包含 Tool 的作用描述和 Tool 的参数描述（包含类型、作用等）。通过将 Nacos 存储的描述信息转化为标准的 MCP 协议里的 tool/list 结果，返回给 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 调用。存量服务只需添加接口描述，无需进行任何改动。

2.使用 Nacos MCP Registr 架构设计的优势

• 存量 API 快速构建 MCP Server

    Nacos 集成 Higress 的方案：通过 Nacos 和 Higress 的集成，用户可以实现零代码快速构建 MCP Server，迅速跟进 MCP 协议，无缝对接存量 API。

• MCP 信息动态下发实时生效

动态调试与优化：MCP 描述信息、Tools 以及 Prompt 都需要经过调试才能达到最佳效果。Nacos 能够帮助管理和下发这些信息，实现动态调整和实时生效，提高调试效率。

• MCP 信息历史版本管理

版本管理与回滚：Nacos 会管理和存储 MCP 信息的历史版本，方便进行 Diff 对比差异，在出现问题时能够快速回滚到之前的版本，确保系统的稳定性和可靠性。

• MCP 信息灰度管理

灰度分批生效：在 MCP 信息生效时，Nacos 支持灰度分批生效，允许逐步推广新配置，方便对比不同版本的效果，降低风险。

• 密码配置加密

敏感信息保护：在 MCP 信息和 API 调用过程中，涉及密码等敏感信息时，Nacos 提供了 敏感信息加密 的能力，确保数据的安全性。

• MCP 返回格式 JSON 转换 XML

格式优化：在与大模型交互时，JSON 格式可能不如 XML 格式直观。Nacos 可以帮助将 MCP 的返回格式从 JSON 转换为 XML，使大模型更容易理解和处理。

• MCP 服务管理及健康检查

服务管理与监控：随着 MCP 服务数量的增加，Nacos 提供了大规模服务管理能力，包括健康检查、实时更新和负载均衡，确保 MCP 服务的高效运行，同时作为 MCP 服务发现中心的托管平台。

通过这些功能，Nacos 和 Higress 的结合为 MCP Server 的构建和管理提供了全面的支持，帮助用户快速、安全地实现 MCP 协议的落地。

2、Nacos MCP Regisry 架构设计总结

借助 Nacos 与 Higress 的组合方案，能够实现无需代码改造，将 AI Agent 智能体无缝连接至现有应用，从而大幅削减现有应用的改造成本。目前，用户需手动配置接口描述信息，但未来 Nacos 计划通过工具化手段进一步简化这一流程，使用户仅需进行微调即可完成配置。在实际场景中，我们面临着海量的存量服务与接口。按照接口到 Tool 的映射规则，我们将产生大量的 Tool。当 Agent 获取 Tool 列表并将其传递给大模型时，这将导致大量的 token 消耗，进而可能影响大模型的性能。因此，如何在上下文中精准筛选出有效的 Tool 列表，并将其高效返回给 Agent 智能体，将成为后续发展的关键方向之一。除了 Tool，MCP 协议还涵盖 Prompt、Resource 等多种资源，MCP 社区也在持续对协议进行更新。相信 Nacos 将逐步支持这些新特性，为 MCP 生态的繁荣贡献力量。

本文转载自公众号玄姐聊AGI  作者：玄姐

原文链接：​​https://mp.weixin.qq.com/s/nQF-bUcmODpqo_SGPSxfbg​​