MCP Gateway：微软给 MCP 服务器打造的智能流量门卫

想象一下：你有一个 AI 助手，它能调用各种工具来完成任务——查天气、写代码、管文件。但这些工具来自不同的服务器，有的在本地，有的在云端，有的响应快，有的慢得像蜗牛。如果没有一个聪明的「路由器」来统一调度、保持会话连续性、处理认证授权，这个 AI 助手就会乱成一锅粥。

MCP Gateway 正是为解决这个痛点而生的。它是微软官方出品的 MCP 服务器反向代理和管理平台，专为 Kubernetes 环境设计，提供会话感知的路由、企业级访问控制，以及完整的 MCP 服务器生命周期管理能力。

背景：MCP 协议与工具调用困境

2024 年底，Anthropic 正式推出 Model Context Protocol（MCP），旨在为 AI 模型与外部工具、数据源之间建立标准化的通信协议。简单来说，MCP 就是 AI 世界的「USB 接口」——无论什么品牌的设备，插上就能用。

然而，MCP 生态迅速扩展后，新的问题浮现：企业需要同时运行数十个甚至上百个 MCP 服务器，这些服务器分布在不同的命名空间、不同的微服务体系中。如何让 AI 代理透明地调用它们？如何保证同一个会话的所有请求都路由到同一个服务器实例（会话亲和性）？如何集中管理这些服务器的部署、更新和权限？

这些正是 MCP Gateway 要回答的问题。微软凭借其在云原生和企业级身份认证领域的深厚积累，选择了一条务实的路线：将 Gateway 定位为企业级 MCP 基础设施，而非简单的流量代理。

核心架构：三层结构的精密协作

MCP Gateway 的架构可以用「控制平面 + 数据平面 + 管理门户」三层来理解。

控制平面提供 RESTful API，开发者通过 /adapters 和 /tools 端点来管理 MCP 服务器和工具的定义与部署。每一个「Adapter」对应一个 MCP 服务器实例，「Tool」则是注册到网关的工具元数据，包含输入模式、执行端点等信息。控制平面还负责与 Azure Entra ID 集成，托管基于角色的访问控制（RBAC）——只有持有 mcp.engineer 角色的用户才能读取资源，而写入操作（如部署新服务器）则需要 mcp.admin 角色。

数据平面是真正的流量网关。所有 MCP 请求（以 Streamable HTTP 协议）都经过网关的路由层，根据 session_id 进行哈希分发，保证同一会话的所有请求命中同一个后端服务器实例。如果启用了「Tool Gateway Router」（工具网关路由器），数据平面还能根据 MCP 工具定义中的元数据，动态将请求路由到对应的工具服务器——相当于给网关装上了一个「智能调度器」。

管理门户是一个 React + TypeScript 构建的单页应用（SPA），集成 Microsoft Fluent UI 组件，通过 MSAL（Microsoft Authentication Library）完成身份认证后，开发者可以在浏览器中直观地查看 adapter 和 tool 的状态、查看 pod 日志，甚至在页面上直接发送 JSON-RPC 请求来测试每个 MCP 服务器。

在底层存储方面，MCP Gateway 使用 Redis 作为分布式会话存储（生产环境需要外部 Redis 实例），以及 Cosmos DB（Azure 的多模型数据库）存储 adapter 和 tool 的元数据。Redis 保证了在水平扩展多个 Gateway 实例时，会话亲和性不会丢失。

技术栈：C# + .NET 8 + Kubernetes 原生

项目采用 C# / .NET 8 作为主要开发语言，利用 ASP.NET Core 的高性能 HTTP 处理能力实现反向代理和路由逻辑。解决方案按功能模块拆分为三个子项目：

• Microsoft.McpGateway.Service：核心网关服务，处理路由、会话管理和 MCP 协议解析
• Microsoft.McpGateway.Management：管理平面的 REST API 实现
• Microsoft.McpGateway.Tools：工具注册和动态路由相关功能

前端门户使用 React 18 + TypeScript，通过 Vite 构建，UI 组件库选择了微软自家的 Fluent UI（就是 Windows 11 风格的那套设计语言），保证了管理界面与 Windows/Azure 生态的一致性。

部署层面，官方只提供 Kubernetes YAML 清单（Deployment + Service + Secret），不支持 Docker 单机运行。deployment/k8s/ 目录下有两套清单：cloud-deployment-template.yml 针对 Azure 环境集成 Workload Identity（工作负载身份），local-deployment.yml 则配置了本地 Redis 连接字符串用于开发调试。

部署流程通过 PowerShell 脚本驱动，脚本内部调用 Azure CLI 和 Bicep（Azure 的声明式基础设施即代码语言），自动化创建 AKS 集群（Azure Kubernetes Service）、ACR（容器注册表）、Cosmos DB 和 Redis 等依赖资源，再将网关镜像推送到 ACR 并部署到 AKS。整个过程需要手动提供 Entra ID Client ID 和角色标签，配置门槛不低。

关键能力：那些让人眼前一亮的细节

会话亲和性路由是 MCP Gateway 区别于普通反向代理的核心差异。当 AI 代理与用户进行多轮对话时，每个请求携带相同的 session_id，网关根据这个 ID 的一致性哈希值，将请求固定路由到同一个 MCP 服务器实例。这解决了有状态 MCP 服务器（如需要维护上下文的 LLM 调用链）在负载均衡环境下无法工作的根本问题。

工具动态路由则是另一个亮点。Tool Gateway Router 本身也是一个 MCP 服务器实例，它会根据每个已注册工具的元数据（包括工具名称、输入 schema）自动选择合适的后端工具服务器来执行请求。开发者只需在控制平面注册工具定义，路由器就能自动搞定路由逻辑——这比手动配置 Nginx 路由规则优雅得多。

Azure 深度集成体现在多个层面：使用 Entra ID 做身份认证和 RBAC、使用 Workload Identity（无需管理密钥的 Pod 级别身份机制）连接 Azure 服务、使用 ACR 存储和拉取容器镜像。这套组合拳对于已经在使用 Azure 的企业来说，吸引力巨大。

Preview 阶段的 Agents & Sessions 功能更激进——除了管理 MCP 服务器，网关还尝试在控制平面之上构建 LLM Agent 运行时。用户可以定义 Agent 元数据（系统提示词、使用的模型、允许调用的工具列表），然后在 Sessions 中与 Agent 进行多轮对话，网关以 SSE（Server-Sent Events）流式返回 LLM 响应。不过这个功能目前处于 Preview 状态，需要配置 Foundry 端点才能启用。

部署体验：Azure 企业用户的菜

坦率地说，MCP Gateway 的部署难度不小。没有 Dockerfile、没有 docker-compose，所有生产部署都绑死在 Azure Kubernetes Service 上。官方文档虽然详细，但整个链路涉及 PowerShell 脚本、Azure CLI、Bicep 模板、Entra ID 应用注册、Kubernetes 资源编排，至少需要 30 分钟到 1 小时才能完成初次部署。

本地开发体验相对友好——deployment/k8s/local-deployment.yml 提供了最小化的 Redis + Gateway 组合，在已有 kubectl 和 Docker 环境的前提下可以快速跑起来。但本地开发也绕不开 .NET 8 SDK 的安装和编译。

硬件需求方面，网关本身是轻量级服务，不需要 GPU，4GB RAM 足够支撑中等规模的请求。磁盘占用主要来自容器镜像，约 10GB。

局限与挑战

MCP Gateway 当前最大的局限是厂商锁定（Vendor Lock-in）。整个部署和运维体系完全围绕 Azure + Kubernetes 构建，对于使用 AWS、GCP 或私有化部署的团队来说，门槛极高。微软似乎将这个项目定位为 Azure AI 平台的一个组件，而非通用的 MCP 网关解决方案。

其次，MCP 协议本身仍在快速演进中（截至 2025 年，Streamable HTTP、OAuth 2.0 采样等特性仍处于草案阶段），Gateway 对协议新特性的跟进速度将直接影响其生态生命力。

最后，开源社区的活跃度也值得关注。虽然项目背靠微软，但 GitHub stars 增长速度相对温和——这可能反映了企业级 MCP 网关本身的用户群体就偏小众。

行业意义：企业级 MCP 基础设施的探路者

MCP Gateway 的出现填补了一个重要空白：在 MCP 生态从「极客玩具」向「企业级工具」演进的过程中，需要有人来解决规模化部署、统一认证、流量管理这些工程化难题。微软选择用成熟的云原生技术栈（C#、.NET、Kubernetes、Entra ID）来构建这个网关，既是优势也是限制——它让 Azure 用户可以几乎无缝地接入 MCP 生态，但也把非 Azure 用户挡在了门外。

从更宏观的视角看，随着 AI Agent 逐渐成为企业应用的主流形态，类似 MCP Gateway 这样的「AI 网关」将成为基础设施的标配。它不仅仅是一个反向代理，更代表了 AI 工具治理、访问控制、生命周期管理的系统性思考。这个赛道才刚刚开始，MCP Gateway 至少已经迈出了值得尊敬的第一步。

项目基本信息