Nacos釋出MCPRegistry，實現存量應用介面“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 管理 Tool 的元資訊的優勢

存量 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 服務發現中心的託管作用。

手把手演示“0 程式碼”

復刻高德 MCP Server

最近高德推出了 MCP Server 獲得了業內廣泛關注，這部分 Server 是高德基於 MCP 社群的開發指引實現的，構建成本較高。接下來，我們基於高德官方的 Open API 介面，透過 Nacos+Higress 的方案，來演示如何 0 程式碼適配 MCP Server。

環境準備

Nacos 部署

透過 docker 部署 nacos：

export NACOS_AUTH_TOKEN=自定義的token，token為原始內容的base64編碼結果export NACOS_AUTH_IDENTITY_VALUE=自定義的IDENTITY_VALUE，任意英文和數字組合docker run -td -e PREFER_HOST_MODE=hostname -e MODE=standalone -e NACOS_AUTH_IDENTITY_KEY=serverIdentity -e NACOS_AUTH_IDENTITY_VALUE=${NACOS_AUTH_IDENTITY_VALUE} -e NACOS_AUTH_TOKEN=${NACOS_AUTH_TOKEN} -p 8848:8848 -p 9848:9848 nacos/nacos-server

Higress 部署

安裝 docker

配置 Kind透過 Kind 在本地安裝 higress，在 Linux x86 的環境下使用如下命令安裝

# For AMD64 / x86_64[ $(uname -m) = x86_64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.27.0/kind-linux-amd64# For ARM64[ $(uname -m) = aarch64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.27.0/kind-linux-arm64chmod +x ./kindsudo mv ./kind /usr/local/bin/kind

透過 Kind 建立一個 local 的 k8s 叢集

kind create cluster

獲取 hgctl，準備安裝 higress

curl -Ls https://raw.githubusercontent.com/alibaba/higress/main/tools/hack/get-hgctl.sh | bash

在本地部署 higress

hgctl install --set profile=local-k8s

安裝 Kubectl 並連線到剛剛建立的叢集

curl-LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"chmod+x ./kubectlmv./kubectl /usr/bin/kubectl

部署 redis

docker run --name higress-redis -d redis

修改 ConfigMap 讓 Higress 連線到 Nacos

kubectl -n higress-system edit cm higress-config

將紅框部分替換為一下內容, 即在原本配置中，data.higress 中增加 mcpServer 段的配置

apiVersion: v1data:higress: |-mcpServer:sse_path_suffix: /sseenable: trueredis:address: {local_ip}:6379match_list:-match_rule_domain: "*"match_rule_path: /registrymatch_rule_type: "prefix"servers:-name: nacos-registrytype: nacos-mcp-registrypath: /registryconfig: serverAddr: {local_ip}namespace: ""serviceMatcher:amap: ".*"ip: ".*"downstream:connectionBufferLimits: 32768http2:initialConnectionWindowSize: 1048576initialStreamWindowSize: 65535maxConcurrentStreams: 100idleTimeout: 180maxRequestHeadersKb: 60routeTimeout: 0upstream:connectionBufferLimits: 10485760idleTimeout: 10

請將 {local_ip} 替換為本機地址，可以在本地執行以下命令獲取

ifconfig eth0 | grep 'inet ' | grep -v '127.0.0.1' | awk '{print $2}'

編輯完成之後儲存配置，至此基本環境以及配置完成。

使用高德官方的 Open API，構建 MCP Server

環境部署完成之後，我們透過一個小的 Demo 對整個流程進行演示，我們以查詢天氣為場景，將高德的 HTTP 介面在無改造的情況下暴露為 MCP 協議，讓 Agent 進行呼叫。

高德開發者 API KEY 申請

呼叫高德 API，我們首先需要申請到高德 API 的 key。進入高德開發者平臺，登陸之後，建立新應用。

建立新應用：

應用建立完成之後，我們建立 key：

在控制檯看到 key，將 key 儲存下來

接下來我們完成 higress 中關聯 Nacos 做 MCP registry 的配置接下來我們在 Nacos 中配置完成高德 HttpApi 的描述檔案的配置以及高德域名資訊配置

在 Nacos 中進行高德 API 服務配置

首先我們透過持久化服務發現的能力將高德的域名註冊到 nacos 中，服務名為 amap，分組為 amap。

建立完服務之後，我們將高德的域名註冊到 Nacos 中。

透過以下命令註冊高德的域名。

curl -X POST 'http://127.0.0.1:8848/nacos/v1/ns/instance?serviceName=amap&groupName=amap&ip=restapi.amap.com&port=80&ephemeral=false'

檢查 amap 服務的例項數變為 1。

在配置中心新建一個配置檔案對高德的 API 進行描述。

進入配置中心，點選新建配置。

建立 DataId 為 amap-mcp-tools.json 分組為 amap 的配置項，配置內容為

{"protocol": "http","tools": [ {"name": "get_weather","description": "get weather","inputSchema": {"type": "object","properties": {"city": {"type": "string","description": "city adcode" } } } }, {"name": "get_adcode","description": "get adcode via address","inputSchema": {"type": "object","properties": {"address": {"type": "string","description": "address" } } } }, {"name": "get_address_via_ip","description": "get address via ip","inputSchema": {"type": "object","properties": {"ip": {"type": "string","description": "ip address" } } } } ],"toolsMeta": {"get_weather": {"credentialRef": "amap-key.json","InvokeContext": {"path": "/v3/weather/weatherInfo","method": "GET" } },"get_adcode": {"credentialRef": "amap-key.json","InvokeContext": {"path": "/v3/geocode/geo","method": "GET" } },"get_address_via_ip": {"credentialRef": "amap-key.json","InvokeContext": {"path": "/v3/ip","method": "GET" } } }}

這個配置描述了高德的 HTTP API 的相關引數資訊，以及 Higress 進行協議轉換時需要的上下文資訊。再建立 DataId 為 amap-key.json，分組為 amap 的配置項配置內容為：

{"type": "fixed-query-token","credentialsMap": {"key": "key","value": "高德的api key" }}

在 Nacos 中進行獲取出口 IP 服務配置

註冊一個獲取當前出口 IP 的服務獲取當前的 IP。以 ipinfo.io 為例，在服務管理中建立服務 ip, 分組為 ip：

服務創建完成之後，向 Nacos 中註冊 ipinfo.io 的域名資訊，執行一下命令。

curl -X POST 'http://127.0.0.1:8848/nacos/v1/ns/instance?serviceName=ip&groupName=ip&ip=ipinfo.io&port=80&ephemeral=false'

註冊完成之後，就能在 Nacos 控制檯看到 IP 服務的下有一個例項了。

服務建立完成之後，我們在配置中心配置獲取 IP 服務的介面描述。建立 DataId ip-mcp-tools.json 為，分組為 ip 的配置，配置內容為：

{"protocol": "http","tools": [ {"name": "get_current_ip_address","description": "get current caller's ip address","inputSchema": {"type": "object","properties": {"empty_args": {"type": "string","description": "should be empty" } } } } ],"toolsMeta": {"get_current_ip_address": {"InvokeContext": {"path": "/","method": "GET" } } }}

配置建立完之後，就可以在 Cursor 中配置 Higress 作為 MCP Server 呼叫 Tool 了。

Cursor MCP 配置

Cursor 的具體配置方法如下：首先安裝最新版本的 Cursor，安裝完成之後在 Cursor 的設定中，配置 MCP Server 的具體資訊。

{"mcpServers": {"nacos-registry": {"url": "http://localhost/registry/sse" } }}

配置完成後可以看到透過 Higress + Nacos 暴露的 MCP Server 提供的 Tool。

查詢天氣

接下來，我們透過 Agent 模式向智慧體，詢問今天天氣怎麼樣。

可以看到，智慧體先獲取了當前主機的出口 IP，再透過 IP 獲取到具體的省市資訊，再透過省市資訊獲取到 adcode，最終透過 adcode 獲取到當前的天氣資訊。整個過程中，使用者只需要將服務註冊在 Nacos 中，並且在 Nacos 中配置服務介面相關的描述資訊即可，服務本身的程式碼無需任何改造；

總結

透過 Nacos+Higress 的方案實現 0 程式碼改造將 Agent 連線到存量應用，能夠顯著降低存量應用的改造成本。當前需要使用者手動配置介面描述資訊，後續可以透過工具化的能力將介面進一步簡化，使用者只需要微調即可。現實中，我們有大量的存量服務和介面，按照介面到 Tool 的對映，我們將會有非常多的 Tool，當 Agent 拉取 Tool 列表並傳遞給模型的時候，將會有非常多的 token 消耗，並且模型的效能也可能會下降。那麼如何在上下文中圈定有效的 Tool 列表，並返回給 Agent，將會是我們後續重要的演進方向之一。除了 Tool，MCP 協議還有 Prompt、Resource 等，MCP 社群也在持續更新協議，我們將在後續逐個支援，助力 MCP 生態的發展。

Nacos 3.0 AI 應用服務管理平臺

Nacos 3.0 架構已將釋出正式版本，定位 AI 應用服務管理平臺，包含了 MCP 動態管理，也覆蓋通用 AI 生態場景，包含模型引數、Prompt 動態模版等場景幫助業務動態管理即時生效，Nacos 社群有完備的多語言客戶端生態，成熟的 Python、GO、Rust、Java、NodeJS 等主流語言的適配，幫你用最低的成本快速構建 AI 應用；隨著 Nacos 演進，會推出越來越多 AI 相關的能力。