网关 MCP 转换技术：从实现到平台落地

MCP Server  即实现 Model Context Protocol（MCP，模型上下文协议）的服务端，能够向 AI 客户端（如 IDE 插件、对话机器人等）暴露 "工具（Tools）/ 资源（Resources）/ 提示（Prompts）/ 补全（Completions）" 等核心能力，客户端通过 JSON-RPC 协议与 MCP Server 进行交互。

根据协议版本的不同，MCP 定义了两类 (stdio 和 HTTP) 共三种传输方式，分别为：stdio、HTTP SSE 及 Streamable HTTP。

其中，HTTP SSE（Server-Sent Events）定义于 MCP 协议 2024-11-05 版本，是一种基于 HTTP 的单向通信协议，支持服务器主动向客户端推送数据，但存在需保持长连接的局限性。

2025 年 3 月 26 日，MCP 协议发布重要更新，采用 Streamable HTTP 替代原有的 HTTP SSE 作为默认传输方式。该方案在解决原有架构中连接不可恢复、服务端长连接压力过大等问题的同时，仍保留了 SSE 的流式响应优势，支持 stateless（无状态）和 stateful（有状态）两种模式，且可根据流式传输需求将响应升级为 SSE 流。

基于上述特性，MCP Server 可分为以下三种类型：

• Stateless Server：不保持会话状态的 MCP Server，客户端与服务端之间无长连接

• Stateless Streamable Server：不保持会话状态且无长连接，但以 SSE 格式响应的服务器架构

• Stateful Server：保持会话状态的服务器架构，类似原 HTTP SSE 模式

MCP Tool 是 MCP Server 暴露给客户端可调用的具体能力（一个“动作”）。每个 Tool 具备：

• name: 工具名（唯一标识）

• description: 说明

• inputSchema: 输入参数 JSON Schema

客户端调用MCP Tool 后，MCP Server 返回  CallToolResult，包含工具执行结果，通常为文本块（TextContent）或结构化数据（如 JSON 格式的分析结果）。

MCP协议：Introduction - Model Context Protocol

现状

2.1 行业趋势

当前 AI 领域技术落地中，越来越多 AI 客户端开始通过 MCP（通用能力调用平台）统一对接外部服务能力。作为标准化通用接口层，MCP 能有效解决多服务集成的碎片化问题：一方面大幅降低跨团队、跨系统的集成复杂度，减少重复开发成本；另一方面通过统一的监控、日志与配置管理，显著提升服务可观测性与全生命周期治理能力，已成为行业主流技术选型方向。

2.2 内部当前困境

货拉拉企业内部经过长期业务沉淀，已构建起数量庞大的HTTP RPC 服务体系，且这些服务深度支撑核心业务流程。若要求各业务团队将现有服务全部重构为 “原生 MCP Server” 模式，将面临两大核心挑战：

1. 改造成本极高：需投入大量人力对历史代码进行重构、测试与适配，挤占新业务开发资源；

2. 周期风险可控性低：全量改造涉及多业务线协同，周期可能长达数月，期间易出现新旧服务兼容问题，影响业务稳定性。

2.3 核心痛点

在现有技术架构下，MCP 改造还面临三大关键适配问题：

1. Java 版本兼容性问题：货拉拉当前生产环境主流 Java 版本为 8，而 MCP Server 对运行环境的最低要求为 Java 17 及以上。若要完成改造，需推动所有涉及服务的 Java 版本升级，不仅涉及代码兼容性改造（如旧 API 替换、依赖包升级），还需经过全链路测试验证，成本与风险较高；

2. 流量体系适配冲突：现有服务基于内部自研框架构建，已实现全链路灰度发布、多泳道隔离（如环境隔离、业务隔离）等核心流量管控能力，可满足复杂业务场景下的稳定性需求。而原生 MCP Server 暂不支持该套流量体系，若强行改造，需在 MCP 架构下重新开发适配能力，或维护 “原有服务 + MCP 服务” 两套流量体系，既增加运维复杂度，也可能引入流量管控漏洞；

3. 协议版本迭代风险：MCP 协议处于持续迭代优化中，未来若出现重大版本更新（如接口定义变更、传输协议升级），已改造完成的所有 MCP Server 需同步进行版本适配与升级，将面临重复改造的成本，且可能因协议兼容性问题影响服务可用性。

我们通过在LApiGateway 上提供MCP 转换技术，统一解决了“零改造接入 AI 生态” 问题。由LApiGateway 统一解决Java 版本兼容性问题、流量体系适配冲突和协议版本迭代风险。

3.1 LApiGateway 架构设计

LApiGateway是货拉拉内部的微服务网关，负责流量转发，并为研发提供诸如鉴权，限流，参数修改，参数校验等一系列功能，以此帮助研发提升开发效率。

LApi控制面主要包括：

• 服务配置，由LApi管理平台和Apollo配置中心组成，用户能够通过LApi管理平台修改服务的配置

• 服务发现，LApi通过Consul获取后端服务的节点注册信息，比如节点的IP地址，分组标识，灰度版本等

• 监控，主要由Trace服务和HLL Monitor两大组件构成，能够进行请求监控和错误告警

LApi数据面，请求经过入口处的负载均衡（KONG、SLB）到达LApi节点，在LApi内部经过一系列的插件处理后，被转发到下游服务节点。

LApi在“MCP Server 代理层”，将 MCP Tool 映射为现有的 HTTP REST 调用：

• 以配置方式定义MCP Tool，支持动态更新，快速开启 AI 能力对接。

• 复用网关既有能力：鉴权、限流、重试、熔断、路由、灰度、可观测性等，统一治理、统一监控。

• 无状态实现，天然支持水平扩容。

LApi同时提供一些依赖第三方服务的插件，比如账号鉴权插件依赖账号服务，SSO鉴权插件依赖SSO服务。

目前在数据处理过程中，LApi可能会依赖以下组件的处理结果：

• 账号服务，负责用户账号鉴权

• Kafka，负责保存请求产生的消息数据

• Lone，负责发布窗口和服务权限管理等

• SSO服务，负责员工账号鉴权

3.2 技术细节

LApi 在实现 MCP Server 代理层时，初期采用 HTTP SSE 传输方式；随着 MCP 协议升级至 Streamable HTTP，其架构同步演进为 Stateless Server 模式，通过去中心化设计有效解决了负载均衡与高可用问题。

1. MCP Tool 调用请求的处理流程：

• 客户端向网关的 MCP 入口（/{serviceAppid}/{mcpServerName}/mcp）发送 MCP Tool 调用请求。

• 网关内部的 MCP 无状态服务根据 Tool 定义，将该次 Tool 调用“转写”为一个标准的下游 HTTP 请求

• 通过网关路由将该 HTTP 请求下发到后端 RPC 服务（会先经过用户在 LApigateway 上配置的路由与插件处理，如重写、鉴权、限流、负载均衡等），并拦截下游响应：

• 若下游返回 2xx：聚合响应体文本，作为 MCP CallToolResult 的 TextContent

• 若下游返回 4xx/5xx：抛出 MCP 错误

• 网关将原始响应结果封装成 JSON-RPC 响应（成功或错误）返回给 MCP 客户端。

1. 关键点：

• 网关端使用无状态传输（Stateless transport），不保持会话，易水平扩容。

• Tool 的 HTTP 生成使用了LApi的表达式引擎，支持从请求头/查询/工具入参中取值并编排。

• 响应只写回 JSON-RPC（拦截下游响应并“吞掉”），最终客户端只看到 JSON-RPC 的 result 或 error。

• 通过AI 工具将MCP JAVA SDK 依赖的JAVA版本降级并适配JAVA 8

3.3 平台化落地

LApi 管理平台提供了MCP Server 配置模块和 MCP 服务市场。

3.3.1 MCP Server 配置模块

在MCP Server 配置平台上添加MCP Tool和对应的后端接口，能灵活动态地对外暴露MCP能力，并且可以一键发布到MCP服务市场中。

3.3.2 MCP 服务市场

MCP 服务市场平台具备 MCP 服务发布能力，同时汇聚了代码质量、文档、监控等多个领域的精选服务，致力于打造属于货拉拉的 MCP 生态平台。