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

前言

随着 AI 技术驱动企业数字化转型加速，货拉拉等企业开始将 "存量 RPC 服务快速接入 AI 生态" 纳入当前的业务探索范畴。MCP（Model Context Protocol，模型上下文协议）作为连接 AI 客户端与后端服务的标准化协议，已逐步成为行业通用接口，但企业普遍面临 "存量服务改造成本高、周期长" 的现实难题。

本文聚焦货拉拉 LApiGateway（内部微服务网关）的 MCP 转换技术，旨在提供 "零改造接入 AI 生态" 的完整解决方案。文档将按 "知识背景→现状分析→解决方案→总结" 的逻辑展开，适用于企业内部研发、架构师及运维人员，可作为 MCP 转换技术落地的参考指南

一、知识背景

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" 模式，将面临两大核心挑战：

改造成本极高：需投入大量人力对历史代码进行重构、测试与适配，挤占新业务开发资源；
周期风险 可控性低：全量改造涉及多业务线协同，周期可能长达数月，期间易出现新旧服务兼容问题，影响业务稳定性。

2.3 核心痛点

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

Java 版本兼容性问题：货拉拉当前生产环境主流 Java 版本为 8，而 MCP Server 对运行环境的最低要求为 Java 17 及以上。若要完成改造，需推动所有涉及服务的 Java 版本升级，不仅涉及代码兼容性改造（如旧 API 替换、依赖包升级），还需经过全链路测试验证，成本与风险较高；
流量体系适配冲突：现有服务基于内部自研框架构建，已实现全链路灰度发布、多泳道隔离（如环境隔离、业务隔离）等核心流量管控能力，可满足复杂业务场景下的稳定性需求。而原生 MCP Server 暂不支持该套流量体系，若强行改造，需在 MCP 架构下重新开发适配能力，或维护 "原有服务 + MCP 服务" 两套流量体系，既增加运维复杂度，也可能引入流量管控漏洞；
协议版本迭代风险：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 模式，通过去中心化设计有效解决了负载均衡与高可用问题。

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 客户端。

关键点：

网关端使用无状态传输（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 生态平台。

四、结语

LApiGateway 在网关层开展的 MCP 转换技术实践，为企业内部RPC 服务对接智能化工具生态提供了一种可行的优化方向，也为数字化转型探索了具体路径。依托 Stateless MCP Server 架构与 LApi 表达式引擎，这一改造着重实现了多方面实际价值：既能快速对接各类 AI 客户端以缩短集成周期，又无需改动后端服务、不影响现有调用方的正常业务；同时借助网关的统一治理能力，既强化了服务可观测性以支撑高效问题排查，也通过策略管控与操作审计，保障了 MCP 调用的安全合规。

此外，该方案以零改造成本推动现有服务完成 AI 化升级，还通过生态化运营促进工具能力的共享复用，为企业搭建智能化工具平台提供了切实助力。从初期的技术尝试到后续的落地应用，LApiGateway 的这一实践，希望能为同类场景的技术优化提供些许参考。

展望未来，随着 AI 技术的深度融合与 MCP 生态的日趋成熟，智能化工具将逐步成为企业构建核心竞争力的重要组成部分。LApiGateway 也将基于现有网关层能力持续演进，努力承担起连接传统服务与智能未来的桥梁作用，为企业在 AI 时代的创新发展提供支持。