隨著 AI 技術(shù)驅(qū)動企業(yè)數(shù)字化轉(zhuǎn)型加速，貨拉拉等企業(yè)開始將 “存量 RPC 服務(wù)快速接入 AI 生態(tài)” 納入當(dāng)前的業(yè)務(wù)探索范疇。

MCP（Model Context Protocol，模型上下文協(xié)議）作為連接 AI 客戶端與后端服務(wù)的標(biāo)準(zhǔn)化協(xié)議，已逐步成為行業(yè)通用接口，但企業(yè)普遍面臨 “存量服務(wù)改造成本高、周期長” 的現(xiàn)實難題。

本文聚焦貨拉拉 LApiGateway（內(nèi)部微服務(wù)網(wǎng)關(guān)）的 MCP 轉(zhuǎn)換技術(shù)，旨在提供 “零改造接入 AI 生態(tài)” 的完整解決方案。

文檔將按 “知識背景→現(xiàn)狀分析→解決方案→總結(jié)” 的邏輯展開，適用于企業(yè)內(nèi)部研發(fā)、架構(gòu)師及運維人員，可作為 MCP 轉(zhuǎn)換技術(shù)落地的參考指南。

一、MCP 核心概念

MCP Server 即實現(xiàn) Model Context Protocol（MCP，模型上下文協(xié)議）的服務(wù)端，能夠向 AI 客戶端（如 IDE 插件、對話機(jī)器人等）暴露 "工具（Tools）/ 資源（Resources）/ 提示（Prompts）/ 補全（Completions）" 等核心能力，客戶端通過 JSON-RPC 協(xié)議與 MCP Server 進(jìn)行交互。

根據(jù)協(xié)議版本的不同，MCP 定義了兩類 (stdio 和 HTTP) 共三種傳輸方式，分別為：stdio、HTTP SSE 及 Streamable HTTP。

其中，HTTP SSE（Server-Sent Events）定義于 MCP 協(xié)議 2024-11-05 版本，是一種基于 HTTP 的單向通信協(xié)議，支持服務(wù)器主動向客戶端推送數(shù)據(jù)，但存在需保持長連接的局限性。

2025 年 3 月 26 日，MCP 協(xié)議發(fā)布重要更新，采用 Streamable HTTP 替代原有的 HTTP SSE 作為默認(rèn)傳輸方式。該方案在解決原有架構(gòu)中連接不可恢復(fù)、服務(wù)端長連接壓力過大等問題的同時，仍保留了 SSE 的流式響應(yīng)優(yōu)勢，支持 stateless（無狀態(tài)）和 stateful（有狀態(tài)）兩種模式，且可根據(jù)流式傳輸需求將響應(yīng)升級為 SSE 流。

基于上述特性，MCP Server 可分為以下三種類型：

• Stateless Server：不保持會話狀態(tài)的 MCP Server，客戶端與服務(wù)端之間無長連接
• Stateless Streamable Server：不保持會話狀態(tài)且無長連接，但以 SSE 格式響應(yīng)的服務(wù)器架構(gòu)
• Stateful Server：保持會話狀態(tài)的服務(wù)器架構(gòu)，類似原 HTTP SSE 模式

MCPTool 是 MCP Server 暴露給客戶端可調(diào)用的具體能力（一個“動作”）。每個 Tool 具備：

• name: 工具名（唯一標(biāo)識）
• description: 說明
• inputSchema: 輸入?yún)?shù) JSON Schema

客戶端調(diào)用MCP Tool 后，MCP Server 返回  CallToolResult，包含工具執(zhí)行結(jié)果，通常為文本塊（TextContent）或結(jié)構(gòu)化數(shù)據(jù)（如 JSON 格式的分析結(jié)果）。

MCP協(xié)議：Introduction - Model Context Protocol

二、現(xiàn)狀

2.1 行業(yè)趨勢

當(dāng)前 AI 領(lǐng)域技術(shù)落地中，越來越多AI客戶端開始通過 MCP（通用能力調(diào)用平臺）統(tǒng)一對接外部服務(wù)能力。作為標(biāo)準(zhǔn)化通用接口層，MCP 能有效解決多服務(wù)集成的碎片化問題：一方面大幅降低跨團(tuán)隊、跨系統(tǒng)的集成復(fù)雜度，減少重復(fù)開發(fā)成本；另一方面通過統(tǒng)一的監(jiān)控、日志與配置管理，顯著提升服務(wù)可觀測性與全生命周期治理能力，已成為行業(yè)主流技術(shù)選型方向。

2.2 內(nèi)部當(dāng)前困境

貨拉拉企業(yè)內(nèi)部經(jīng)過長期業(yè)務(wù)沉淀，已構(gòu)建起數(shù)量龐大的HTTPRPC服務(wù)體系，且這些服務(wù)深度支撐核心業(yè)務(wù)流程。若要求各業(yè)務(wù)團(tuán)隊將現(xiàn)有服務(wù)全部重構(gòu)為 “原生 MCP Server” 模式，將面臨兩大核心挑戰(zhàn)：

1.改造成本極高：需投入大量人力對歷史代碼進(jìn)行重構(gòu)、測試與適配，擠占新業(yè)務(wù)開發(fā)資源；

2.周期風(fēng)險可控性低：全量改造涉及多業(yè)務(wù)線協(xié)同，周期可能長達(dá)數(shù)月，期間易出現(xiàn)新舊服務(wù)兼容問題，影響業(yè)務(wù)穩(wěn)定性。

2.3 核心痛點

在現(xiàn)有技術(shù)架構(gòu)下，MCP 改造還面臨三大關(guān)鍵適配問題：

1.Java 版本兼容性問題：貨拉拉當(dāng)前生產(chǎn)環(huán)境主流 Java 版本為 8，而 MCP Server 對運行環(huán)境的最低要求為 Java 17 及以上。若要完成改造，需推動所有涉及服務(wù)的 Java 版本升級，不僅涉及代碼兼容性改造（如舊 API 替換、依賴包升級），還需經(jīng)過全鏈路測試驗證，成本與風(fēng)險較高；

2.流量體系適配沖突：現(xiàn)有服務(wù)基于內(nèi)部自研框架構(gòu)建，已實現(xiàn)全鏈路灰度發(fā)布、多泳道隔離（如環(huán)境隔離、業(yè)務(wù)隔離）等核心流量管控能力，可滿足復(fù)雜業(yè)務(wù)場景下的穩(wěn)定性需求。而原生 MCP Server 暫不支持該套流量體系，若強(qiáng)行改造，需在 MCP 架構(gòu)下重新開發(fā)適配能力，或維護(hù) “原有服務(wù) + MCP 服務(wù)” 兩套流量體系，既增加運維復(fù)雜度，也可能引入流量管控漏洞；

3.協(xié)議版本迭代風(fēng)險：MCP 協(xié)議處于持續(xù)迭代優(yōu)化中，未來若出現(xiàn)重大版本更新（如接口定義變更、傳輸協(xié)議升級），已改造完成的所有 MCP Server 需同步進(jìn)行版本適配與升級，將面臨重復(fù)改造的成本，且可能因協(xié)議兼容性問題影響服務(wù)可用性。

三、解決方案

我們通過在LApiGateway 上提供MCP 轉(zhuǎn)換技術(shù)，統(tǒng)一解決了“零改造接入 AI 生態(tài)” 問題。由LApiGateway 統(tǒng)一解決Java 版本兼容性問題、流量體系適配沖突和協(xié)議版本迭代風(fēng)險。

3.1 LApiGateway 架構(gòu)設(shè)計

LApiGateway是貨拉拉內(nèi)部的微服務(wù)網(wǎng)關(guān)，負(fù)責(zé)流量轉(zhuǎn)發(fā)，并為研發(fā)提供諸如鑒權(quán)，限流，參數(shù)修改，參數(shù)校驗等一系列功能，以此幫助研發(fā)提升開發(fā)效率。

圖片

LApi控制面主要包括：

• 服務(wù)配置，由LApi管理平臺和Apollo配置中心組成，用戶能夠通過LApi管理平臺修改服務(wù)的配置
• 服務(wù)發(fā)現(xiàn)，LApi通過Consul獲取后端服務(wù)的節(jié)點注冊信息，比如節(jié)點的IP地址，分組標(biāo)識，灰度版本等
• 監(jiān)控，主要由Trace服務(wù)和HLL Monitor兩大組件構(gòu)成，能夠進(jìn)行請求監(jiān)控和錯誤告警

LApi數(shù)據(jù)面，請求經(jīng)過入口處的負(fù)載均衡（KONG、SLB）到達(dá)LApi節(jié)點，在LApi內(nèi)部經(jīng)過一系列的插件處理后，被轉(zhuǎn)發(fā)到下游服務(wù)節(jié)點。

LApi在“MCP Server 代理層”，將 MCP Tool 映射為現(xiàn)有的 HTTP REST 調(diào)用：

• 以配置方式定義MCP Tool，支持動態(tài)更新，快速開啟 AI 能力對接。
• 復(fù)用網(wǎng)關(guān)既有能力：鑒權(quán)、限流、重試、熔斷、路由、灰度、可觀測性等，統(tǒng)一治理、統(tǒng)一監(jiān)控。
• 無狀態(tài)實現(xiàn)，天然支持水平擴(kuò)容。

LApi同時提供一些依賴第三方服務(wù)的插件，比如賬號鑒權(quán)插件依賴賬號服務(wù)，SSO鑒權(quán)插件依賴SSO服務(wù)。

目前在數(shù)據(jù)處理過程中，LApi可能會依賴以下組件的處理結(jié)果：

• 賬號服務(wù)，負(fù)責(zé)用戶賬號鑒權(quán)
• Kafka，負(fù)責(zé)保存請求產(chǎn)生的消息數(shù)據(jù)
• Lone，負(fù)責(zé)發(fā)布窗口和服務(wù)權(quán)限管理等
• SSO服務(wù)，負(fù)責(zé)員工賬號鑒權(quán)

3.2 技術(shù)細(xì)節(jié)

LApi 在實現(xiàn) MCP Server 代理層時，初期采用 HTTP SSE 傳輸方式；隨著 MCP 協(xié)議升級至 Streamable HTTP，其架構(gòu)同步演進(jìn)為 Stateless Server 模式，通過去中心化設(shè)計有效解決了負(fù)載均衡與高可用問題。

圖片

1.MCP Tool 調(diào)用請求的處理流程：

• 客戶端向網(wǎng)關(guān)的 MCP 入口（/{serviceAppid}/{mcpServerName}/mcp）發(fā)送 MCP Tool 調(diào)用請求。
• 網(wǎng)關(guān)內(nèi)部的 MCP 無狀態(tài)服務(wù)根據(jù) Tool 定義，將該次 Tool 調(diào)用“轉(zhuǎn)寫”為一個標(biāo)準(zhǔn)的下游 HTTP 請求
• 通過網(wǎng)關(guān)路由將該 HTTP 請求下發(fā)到后端 RPC 服務(wù)（會先經(jīng)過用戶在 LApigateway 上配置的路由與插件處理，如重寫、鑒權(quán)、限流、負(fù)載均衡等），并攔截下游響應(yīng)：

• 若下游返回 2xx：聚合響應(yīng)體文本，作為 MCP CallToolResult 的 TextContent
• 若下游返回 4xx/5xx：拋出 MCP 錯誤

• 網(wǎng)關(guān)將原始響應(yīng)結(jié)果封裝成 JSON-RPC 響應(yīng)（成功或錯誤）返回給 MCP 客戶端。

2.關(guān)鍵點：

• 網(wǎng)關(guān)端使用無狀態(tài)傳輸（Stateless transport），不保持會話，易水平擴(kuò)容。
• Tool 的 HTTP 生成使用了LApi的表達(dá)式引擎，支持從請求頭/查詢/工具入?yún)⒅腥≈挡⒕幣拧?/span>
• 響應(yīng)只寫回 JSON-RPC（攔截下游響應(yīng)并“吞掉”），最終客戶端只看到 JSON-RPC 的 result 或 error。
• 通過AI 工具將MCP JAVA SDK 依賴的JAVA版本降級并適配JAVA 8

3.3 平臺化落地

LApi 管理平臺 提供了MCP Server 配置模塊 和 MCP 服務(wù)市場。

3.3.1 MCP Server 配置模塊

在MCP Server 配置平臺上添加MCP Tool和對應(yīng)的后端接口，能靈活動態(tài)地對外暴露MCP能力，并且可以一鍵發(fā)布到MCP服務(wù)市場中。

圖片

圖片

3.3.2 MCP 服務(wù)市場

MCP 服務(wù)市場平臺具備 MCP 服務(wù)發(fā)布能力，同時匯聚了代碼質(zhì)量、文檔、監(jiān)控等多個領(lǐng)域的精選服務(wù)，致力于打造屬于貨拉拉的 MCP 生態(tài)平臺。

圖片

四、總結(jié)

LApiGateway 在網(wǎng)關(guān)層開展的 MCP 轉(zhuǎn)換技術(shù)實踐，為企業(yè)內(nèi)部RPC 服務(wù)對接智能化工具生態(tài)提供了一種可行的優(yōu)化方向，也為數(shù)字化轉(zhuǎn)型探索了具體路徑。

依托 Stateless MCP Server 架構(gòu)與 LApi 表達(dá)式引擎，這一改造著重實現(xiàn)了多方面實際價值：既能快速對接各類 AI 客戶端以縮短集成周期，又無需改動后端服務(wù)、不影響現(xiàn)有調(diào)用方的正常業(yè)務(wù)；同時借助網(wǎng)關(guān)的統(tǒng)一治理能力，既強(qiáng)化了服務(wù)可觀測性以支撐高效問題排查，也通過策略管控與操作審計，保障了 MCP 調(diào)用的安全合規(guī)。

此外，該方案以零改造成本推動現(xiàn)有服務(wù)完成 AI 化升級，還通過生態(tài)化運營促進(jìn)工具能力的共享復(fù)用，為企業(yè)搭建智能化工具平臺提供了切實助力。從初期的技術(shù)嘗試到后續(xù)的落地應(yīng)用，LApiGateway 的這一實踐，希望能為同類場景的技術(shù)優(yōu)化提供些許參考。

展望未來，隨著 AI 技術(shù)的深度融合與 MCP 生態(tài)的日趨成熟，智能化工具將逐步成為企業(yè)構(gòu)建

核心競爭力的重要組成部分。LApiGateway 也將基于現(xiàn)有網(wǎng)關(guān)層能力持續(xù)演進(jìn)，努力承擔(dān)起連接傳統(tǒng)服務(wù)與智能未來的橋梁作用，為企業(yè)在 AI 時代的創(chuàng)新發(fā)展提供支持。