MCP Gateway：基于Kubernetes的AI应用统一接入与工具管理平台

1. 项目概述：MCP Gateway，AI应用与LLM的“交通枢纽”

如果你正在构建或管理基于大型语言模型（LLM）的智能应用，比如AI助手、智能客服或者自动化工作流，那你一定遇到过这个痛点：如何高效、安全地管理和调用背后那些五花八门的“能力提供者”——也就是MCP服务器。这些服务器可能负责文件读取、数据库查询、调用外部API，甚至是控制智能家居。手动管理它们的部署、连接、认证和扩缩容，很快就会变成一场运维噩梦。

MCP Gateway就是为了解决这个核心问题而生的。你可以把它理解为一个专为AI应用场景设计的“智能交通枢纽”或“统一接入层”。它基于微软开源的Model Context Protocol，在Kubernetes环境中，为MCP服务器提供了一个可扩展、带会话感知的反向代理和管理平面。简单说，它把零散的、难以管理的MCP服务器，变成了一个可以统一调度、监控和使用的“服务网格”。

我在实际部署和测试这个项目的过程中发现，它的价值远不止于文档里提到的“路由”和“管理”。它真正解决的是AI应用落地时，从开发到生产环境切换中的“最后一公里”问题：如何让AI能力像微服务一样被标准化地消费。接下来，我将结合我的实操经验，为你深入拆解MCP Gateway的架构设计、核心功能，并手把手带你完成从本地开发到云端部署的全过程，分享那些官方文档里不会写的配置细节和避坑指南。

2. 核心架构与设计哲学：为什么是“网关+控制平面”？

在深入命令行之前，我们必须先理解MCP Gateway的设计思路。这决定了你后续如何使用它，以及如何根据自身业务进行调整。它的架构清晰地分为了“控制平面”和“数据平面”，这种分离是现代云原生系统的典型设计。

2.1 控制平面：你的MCP服务器“指挥中心”

控制平面通过一组RESTful API暴露，这是你作为管理员或开发者与之交互的主要界面。它的核心职责是声明式管理。

适配器管理：当你通过POST /adapters创建一个适配器时，你并不是在手动启动一个容器。你是在向系统声明：“我需要一个名为‘weather-service’的MCP服务器，请使用weather:1.2.0这个镜像，并确保它始终有2个副本运行。” 网关的控制平面接收到这个“期望状态”后，会驱动底层的Kubernetes编排器去创建对应的StatefulSet、Service等资源，并持续监控，确保实际状态与期望状态一致。GET /adapters/{name}/status和.../logs接口，就是让你随时查看这个“声明”的执行情况。

工具注册与管理：这是MCP Gateway一个非常强大的特性。传统的MCP服务器通常是一个“大而全”的容器，提供多种工具。但在微服务架构下，我们更希望每个工具能独立开发、部署和扩展。工具注册功能允许你将一个独立的服务（比如一个专门查询天气的微服务）注册为一个MCP工具。你不仅提供容器信息，还通过toolDefinition字段提供了这个工具的“使用说明书”——它的名字、描述、输入参数格式。这样，网关就能理解这个工具能做什么，以及如何调用它。

实操心得：工具定义中的inputSchema非常关键。它必须严格遵循JSON Schema规范。我遇到过因为required字段漏写或属性type定义错误，导致工具虽然部署成功，但路由时无法正确匹配和调用的坑。务必在注册前，先用JSON Schema验证器检查你的定义。

2.2 数据平面：智能、会话化的请求路由

数据平面是流量入口，负责将来自AI应用（如VS Code Copilot Chat）的MCP协议请求，高效、正确地分发给后端的MCP服务器或工具。

会话亲和性路由：这是MCP Gateway的一个精髓设计。MCP协议通常是基于SSE或WebSocket的长连接、流式传输协议。一个复杂的用户对话可能会涉及对同一个MCP服务器的多次连续调用。如果这些请求被随机分发到不同的服务器实例，会话状态（比如之前读取的文件句柄、数据库事务上下文）就会丢失。网关通过session_id来保证带有相同会话ID的所有请求，都会被路由到同一个MCP服务器Pod实例上。这在生产环境中对于保证复杂交互的连贯性至关重要。

工具网关路由器：这是实现工具动态路由的核心组件。它本身也是一个MCP服务器，但它的“工具”是“知道所有已注册工具的路由表”。当客户端向/mcp端点发起请求时，请求首先到达网关，网关再以会话亲和的方式将其转发给某个工具网关路由器实例。路由器解析请求中的工具调用（例如{"name": "get_weather", "arguments": {"location": "Beijing"}}），然后查询内部注册表，找到名为get_weather的工具对应的实际服务地址（例如http://weather-tool-0:8000），再将请求代理过去，最后将结果原路返回。

这种设计的好处是解耦。工具提供者只需关心实现自己的业务逻辑并注册，无需知道客户端在哪里；客户端只需知道一个统一的入口（/mcp），无需维护所有工具服务器的地址列表。路由器的水平扩展也使得整个系统的吞吐量可以随着工具数量的增长而线性提升。

2.3 认证与授权：企业级安全基石

任何面向企业的网关，安全都是头等大事。MCP Gateway深度集成了Azure Entra ID（原Azure Active Directory）。

认证流程：所有对控制平面（管理API）和数据平面（MCP流端点）的请求，都必须携带一个有效的Bearer Token。这个Token由Azure Entra ID颁发。在本地测试时，你可以用Azure CLI的az account get-access-token命令快速获取。在生产环境中，你的客户端应用（如自定义的AI前端）需要使用OAuth 2.0客户端凭证流等方式来获取Token。

基于角色的访问控制：这是授权层。你可以在创建适配器或注册工具时，通过requiredRoles字段指定一个或多个应用角色（例如["mcp.engineer"]）。只有持有Token且Token中包含相应角色声明的用户或服务主体，才能访问该资源。mcp.admin角色被设计为超级管理员，拥有所有资源的读写权限。

避坑指南：在Azure门户中配置应用角色时，角色的“值”字段（如mcp.engineer）必须与你在API请求requiredRoles数组中填写的值完全一致，包括大小写。我最初曾因为角色值配置为Mcp.Engineer而请求中用了mcp.engineer，导致授权失败，排查了很久。建议全部使用小写加下划线的命名方式。

3. 本地环境部署与深度实操

理解了架构，我们动手把它跑起来。本地部署是学习和调试的最佳方式，能让你看清所有组件是如何协作的。

3.1 环境准备：超越“安装完成”

文档列出了需要安装.NET 8 SDK、Docker Desktop和Kubernetes。但这里有几个细节决定成败：

1. Kubernetes版本兼容性：MCP Gateway的Kubernetes清单文件使用了StatefulSet、Service等标准资源，对版本要求不苛刻。但确保你的Docker Desktop内置Kubernetes版本在1.24以上。可以在终端输入kubectl version --short确认。
2. 本地镜像仓库：docker run -d -p 5000:5000 --name registry registry:2.7这行命令启动的是一个不安全的HTTP仓库。对于本地开发没问题，但如果你后续的构建推送失败，记得检查Docker Desktop的配置：在Settings -> Docker Engine中，确保insecure-registries包含了"localhost:5000"。
3. 资源配额：在本地跑一整套Kubernetes服务，对内存有一定要求。建议为Docker Desktop分配至少6GB内存（Settings -> Resources），否则在部署多个Pod时可能因内存不足而失败。

3.2 构建与推送：理解多阶段构建

项目提供了示例MCP服务器（mcp-example）和工具服务器（weather-tool）。我们以mcp-example为例，看看它的Dockerfile：

# 使用官方 .NET 运行时镜像作为基础 FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base WORKDIR /app EXPOSE 8080 # 使用 .NET SDK 镜像来构建应用 FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build WORKDIR /src COPY ["mcp-example.csproj", "./"] RUN dotnet restore "mcp-example.csproj" COPY . . RUN dotnet build "mcp-example.csproj" -c Release -o /app/build # 发布应用 FROM build AS publish RUN dotnet publish "mcp-example.csproj" -c Release -o /app/publish # 最终阶段，只包含运行时和发布产物，镜像更小 FROM base AS final WORKDIR /app COPY --from=publish /app/publish . ENTRYPOINT ["dotnet", "mcp-example.dll"]

这是一个典型的多阶段构建，目的是减小最终镜像体积。构建并推送的命令：

docker build -f sample-servers/mcp-example/Dockerfile sample-servers/mcp-example -t localhost:5000/mcp-example:1.0.0 docker push localhost:5000/mcp-example:1.0.0

关键点：-t参数中的标签localhost:5000/前缀，指明了镜像要推送到我们刚启动的本地仓库。如果推送失败，请先用docker ps确认registry容器正在运行，并用curl http://localhost:5000/v2/_catalog测试仓库是否可访问。

3.3 网关与路由器构建：Pubxml配置的奥秘

构建网关和路由器镜像的命令使用了/p:PublishProfile=localhost_5000.pubxml参数。这个文件（位于项目目录下）定义了发布配置，核心内容是指定容器镜像的仓库地址和标签：

<?xml version="1.0" encoding="utf-8"?> <Project> <PropertyGroup> <ContainerRepository>localhost:5000/mcp-gateway</ContainerRepository> <ContainerImageTag>latest</ContainerImageTag> <RuntimeIdentifier>linux-x64</RuntimeIdentifier> <PublishSingleFile>true</PublishSingleFile> </PropertyGroup> </Project>

这个配置让dotnet publish命令在打包应用的同时，直接构建出Docker镜像并打上标签。执行完发布命令后，用docker images | grep localhost:5000应该能看到mcp-gateway和mcp-tool-gateway的镜像。

3.4 Kubernetes部署清单解析

应用deployment/k8s/local-deployment.yml是整个系统的蓝图。我们拆解几个关键部分：

命名空间与配置：

apiVersion: v1 kind: Namespace metadata: name: adapter --- apiVersion: v1 kind: ConfigMap metadata: name: gateway-config namespace: adapter data: AppSettings.json: | { "SessionStore": "Distributed", "DistributedSessionStore": "Redis" }

所有资源都部署在adapter命名空间下，便于隔离和管理。ConfigMapgateway-config以文件形式挂载到网关Pod中，相当于应用配置文件。这里指定了使用分布式会话存储（Redis），这是生产模式，确保多个网关实例间能共享会话状态。

网关服务（Service）：

apiVersion: v1 kind: Service metadata: name: mcpgateway-service namespace: adapter spec: selector: app: mcpgateway ports: - port: 8000 targetPort: 8080 type: ClusterIP

这是一个ClusterIP类型的服务，在集群内部暴露网关应用（端口8080）为8000端口。我们后续的kubectl port-forward就是将本地的8000端口转发到这个服务的8000端口。

网关部署（Deployment）：

apiVersion: apps/v1 kind: Deployment metadata: name: mcpgateway namespace: adapter spec: replicas: 2 selector: matchLabels: app: mcpgateway template: metadata: labels: app: mcpgateway spec: containers: - name: mcpgateway image: localhost:5000/mcp-gateway:latest ports: - containerPort: 8080 env: - name: ASPNETCORE_ENVIRONMENT value: "Development" volumeMounts: - name: config mountPath: /app/config volumes: - name: config configMap: name: gateway-config

这里定义了网关本身：运行2个副本（replicas: 2）以实现高可用，使用我们刚构建的镜像，挂载配置文件，并设置环境变量。注意：在本地开发时使用Development环境是合理的，但在生产环境必须改为Production，这会启用更严格的安全设置和优化。

工具网关路由器（StatefulSet）：

apiVersion: apps/v1 kind: StatefulSet metadata: name: toolgateway namespace: adapter spec: serviceName: "toolgateway" replicas: 2 selector: matchLabels: app: toolgateway template: metadata: labels: app: toolgateway spec: containers: - name: toolgateway image: localhost:5000/mcp-tool-gateway:latest ports: - containerPort: 8080

工具网关路由器使用了StatefulSet而不是Deployment。这是因为每个路由器实例可能需要有稳定的网络标识（如toolgateway-0,toolgateway-1），这对于实现精确的会话亲和性路由可能有帮助。serviceName字段会创建一个与之匹配的Headless Service，为每个Pod提供唯一的DNS记录。

执行kubectl apply -f deployment/k8s/local-deployment.yml后，使用kubectl get all -n adapter查看所有资源状态，确保所有Pod都进入Running状态。

3.5 端口转发与API测试：使用真实的HTTP客户端

kubectl port-forward -n adapter svc/mcpgateway-service 8000:8000这个命令会在后台运行一个进程，将你本地机器的8000端口映射到Kubernetes集群内mcpgateway-service的8000端口。现在，http://localhost:8000就指向了集群内的网关。

我强烈建议使用Bruno或Postman这类API客户端进行测试，而不是简单的curl。因为它们能更好地处理长时间运行的SSE连接，并且可以方便地管理环境变量和授权头。

1. 创建适配器：在Bruno中新建一个请求，方法POST，地址http://localhost:8000/adapters。在Body标签中选择JSON，粘贴示例JSON。注意，本地部署通常没有启用认证（取决于网关的配置），所以可能不需要Authorization头。点击发送，你应该收到一个201 Created或202 Accepted的响应，其中包含你创建的适配器信息。
2. 检查状态：立刻发送一个GET http://localhost:8000/adapters/mcp-example/status请求。在初始阶段，你可能会看到状态是Provisioning或Creating。这是因为网关正在调用Kubernetes API创建Pod。持续轮询这个端点，直到状态变为Running。这个过程通常需要几十秒，取决于镜像拉取速度。
3. 查看日志：如果状态长时间不变成Running，或者变成Failed，立刻使用GET http://localhost:8000/adapters/mcp-example/logs接口查看日志。这是最直接的排错手段。常见的失败原因包括：镜像名称错误（localhost:5000/前缀缺失）、本地仓库无法从集群内访问、镜像拉取策略（imagePullPolicy）设置为Always而本地镜像没有标签等。

3.6 连接VS Code Copilot：配置文件的细节

要让VS Code的Copilot Chat连接到你的MCP服务器，需要在项目或全局配置中创建.vscode/mcp.json文件。这里有一个极易忽略的细节：

{ "servers": { "mcp-example": { "url": "http://localhost:8000/adapters/mcp-example/mcp", "forwardServerLogs": true } } }

forwardServerLogs这个选项非常有用。当设置为true时，MCP服务器端的日志也会输出到VS Code的“MCP Servers”输出面板。这在调试工具调用失败时，能帮你快速定位问题是出在网关路由层，还是出在具体的MCP服务器实现层。

配置完成后，在VS Code中打开命令面板（Ctrl+Shift+P），输入 “MCP: Refresh Servers” 并执行，以重新加载配置。然后，你就可以在Copilot Chat中尝试使用这个MCP服务器提供的工具了。

3.7 工具注册与动态路由实战

这是MCP Gateway最精彩的部分。我们注册一个独立的天气工具。

1. 构建工具镜像：确保weather-tool示例镜像已构建并推送到本地仓库。
2. 注册工具：向POST http://localhost:8000/tools发送请求，Body中包含完整的工具定义。特别注意toolDefinition.port字段，它必须与工具服务器容器内实际监听的端口一致（示例中是8000）。如果端口不匹配，路由器将无法连接到你的工具服务器。
3. 验证部署：同样，通过GET /tools/weather/status和GET /tools/weather/logs来监控部署过程。
4. 测试动态路由：修改你的mcp.json，将服务器URL改为http://localhost:8000/mcp。这个端点连接的是工具网关路由器。现在，当你在Copilot Chat中调用weather工具时，请求的流向是：VS Code -> 网关 (localhost:8000) -> 工具网关路由器 Pod -> 天气工具服务器 Pod -> 返回结果。 你可以通过查看网关、路由器、工具服务器三方的日志，来完整追踪一次调用的生命周期。

4. 云端部署到Azure：生产就绪之路

本地环境跑通后，就可以考虑部署到云端的生产环境了。Azure部署提供了高可用、可扩展、带安全认证的完整生产套件。

4.1 基础设施即代码：Bicep模板解析

项目通过一个“一键部署”按钮，使用ARM模板（背后是Bicep）在Azure中创建整套资源。我们手动执行的话，核心是理解这些资源的作用：

• Azure Container Registry：私有Docker镜像仓库，用于存储你的MCP服务器、工具服务器、网关和路由器的镜像。
• Azure Kubernetes Service：托管的Kubernetes集群，是MCP Gateway和所有工作负载的运行平台。
• Azure Cosmos DB：用作分布式会话存储（Redis模式）的后端，确保多个网关实例间的会话一致性。也可以用于存储适配器和工具的元数据。
• Azure Application Gateway：作为面向公网的7层负载均衡器，提供TLS终止、WAF防护、基于路径/主机的路由规则。它是外部流量进入集群的入口。
• Application Insights：用于收集应用日志、性能和遥测数据，是监控和诊断的核心。
• Managed Identity：为AKS集群中的Pod提供访问其他Azure资源（如ACR、Cosmos DB）的权限，无需管理密码或密钥，是最佳安全实践。

部署命令az deployment group create会一次性创建所有这些资源，并配置好它们之间的网络、身份和依赖关系。

4.2 认证配置的深水区：Entra ID应用角色

云端部署与本地最大的不同就是强制的认证。文档提到了配置应用角色，但这里有几个必须明确的点：

1. “谁”来扮演客户端？当你用Azure CLI获取Token测试API时，客户端是“Azure CLI”这个已注册的应用（Client ID:04b07795-8ddb-461a-bbee-02f9e1bf7b46）。当你用VS Code连接时，客户端是“Visual Studio Code”应用（Client ID:aebc6443-996d-45c2-90f0-388ff96faa56）。在生产中，你自己的后端服务或前端应用需要单独注册为一个Entra ID应用，并获取其Client ID和Secret（或证书）。
2. 角色分配的对象：在Azure门户中，你创建了角色（如mcp.admin），但这个角色需要被“分配”给用户、组或服务主体。对于自动化场景（服务间调用），你需要创建一个“服务主体”（Enterprise Application），然后给这个服务主体分配角色。注意：给“应用注册”本身分配角色是无效的，必须给其对应的“服务主体”分配。
3. Token中的声明：一个成功的Token的roles声明会是一个数组，如["mcp.admin"]。你可以在 jwt.ms 这个网站上粘贴你的Token，解码后查看其中的声明，确认角色是否正确包含。

4.3 生产环境配置调优

部署完成后，默认配置是针对通用场景的。要用于真实生产负载，你需要调整：

1. AKS节点池：默认部署可能使用少量标准DSv3系列虚拟机。根据你的负载预估，可能需要增加节点数量、选择更高性能的SKU（如内存优化型），或启用节点自动扩缩容。
2. 网关与路由器副本数：在Kubernetes部署清单中，增加mcpgatewayDeployment和toolgatewayStatefulSet的replicas数量（例如从2增加到3或更多），并结合Horizontal Pod Autoscaler根据CPU/内存使用率自动扩缩容。
3. 资源请求与限制：为所有Pod（网关、路由器、你的MCP服务器）定义合理的resources.requests和resources.limits，防止单个Pod耗尽节点资源，也帮助调度器做出最佳决策。
4. 应用网关配置：
   • TLS证书：在Application Gateway的监听器上绑定从权威CA（如Let‘s Encrypt）或企业CA获取的SSL证书，启用HTTPS。
   • WAF策略：启用Web应用防火墙并配置适当的防护模式（预防或检测），防范常见Web攻击。
   • 健康探测：配置针对网关/health或/ready端点的健康探测，确保不健康的Pod不会被接收流量。

4.4 监控与运维

一旦系统上线，监控就是你的眼睛。

1. Application Insights仪表板：配置关键指标仪表板，包括：网关请求率、延迟、错误率（4xx，5xx）；Kubernetes集群节点和Pod的CPU/内存使用率；Cosmos DB的请求单位和存储用量。
2. 告警：设置告警规则，例如：当5xx错误率超过1%持续5分钟时，或当平均响应时间超过1秒时，通过邮件、短信或Teams频道通知运维人员。
3. 集中式日志：虽然Application Insights能收集日志，但对于复杂的Kubernetes应用，通常还会集成如Azure Monitor for Containers或第三方方案如Grafana Loki，来集中收集和分析所有Pod的标准输出日志。
4. 密钥管理：所有敏感配置（如数据库连接字符串、外部API密钥）都应使用Azure Key Vault存储，并通过CSI驱动或Pod身份映射到容器中，切勿硬编码在环境变量或配置文件中。

5. 常见问题与故障排查实录

在实际操作中，你一定会遇到各种问题。以下是我踩过的一些坑和解决方法，希望能帮你节省时间。

5.1 本地部署问题

问题1：kubectl apply后Pod一直处于ContainerCreating或ImagePullBackOff状态。

• 排查：运行kubectl describe pod <pod-name> -n adapter。查看Events部分。
• 可能原因及解决：
  • 镜像拉取错误：本地仓库localhost:5000对Docker Desktop内的Kubernetes是可达的，但有时需要明确设置镜像拉取策略。在Pod模板中尝试添加imagePullPolicy: IfNotPresent或imagePullPolicy: Never（仅限本地开发）。
  • 资源不足：Events中显示Insufficient memory或Insufficient cpu。为Docker Desktop分配更多资源。
  • 端口冲突：检查是否有其他进程占用了8000端口。使用netstat -ano | findstr :8000(Windows) 或lsof -i :8000(Mac/Linux) 查看并终止冲突进程。

问题2：API请求创建适配器成功，但状态始终不是Running。

• 排查：首先检查适配器Pod的日志：kubectl logs -n adapter deployment/mcp-example（假设部署名是mcp-example）。如果没有Pod，检查StatefulSet：kubectl get statefulset -n adapter。
• 可能原因：
  • MCP服务器启动失败：日志中可能显示应用本身启动错误，如缺少配置、数据库连接失败等。这需要你检查自己的MCP服务器代码。
  • 就绪探针失败：Kubernetes通过就绪探针判断Pod是否可接收流量。MCP Gateway部署的StatefulSet可能配置了HTTP就绪探针（/health）。确保你的MCP服务器镜像包含了健康检查端点，并且该端点能正确响应。

问题3：VS Code能连接网关，但调用工具时超时或无响应。

• 排查：这是一个链条问题，需要分段排查。
  1. 检查网关日志：kubectl logs -n adapter deployment/mcpgateway。看请求是否到达网关，是否有错误日志。
  2. 检查路由器日志：kubectl logs -n adapter statefulset/toolgateway -c toolgateway。看请求是否被正确路由。
  3. 检查工具服务器日志：kubectl logs -n adapter deployment/weather。看请求是否到达，业务逻辑是否执行。
• 常见原因：
  • 网络策略：默认情况下，Kubernetes集群内Pod间网络是通的。但如果安装了Calico等网络插件并设置了默认拒绝策略，需要创建允许adapter命名空间内Pod互访的NetworkPolicy。
  • 会话亲和性导致的路由错误：如果工具网关路由器有多个副本，且会话亲和性基于源IP，而你的测试请求来自同一个IP，那么所有请求可能都被路由到同一个路由器副本。如果这个副本恰好不健康，就会失败。检查路由器的就绪状态和日志。

5.2 云端部署问题

问题1：Azure部署失败，提示资源名称冲突或参数无效。

• 原因：resourceLabel参数必须是全局唯一的（在所用区域），且只能包含小写字母和数字。它被用作许多资源名称（如存储账户、ACR）的一部分。
• 解决：使用一个更独特、更随机的resourceLabel，例如结合项目名和日期myproj20241027。

问题2：获取的Bearer Token在调用API时返回401 Unauthorized。

• 排查：
  1. 确认Token未过期。Token默认有效期为1小时。
  2. 在 jwt.ms 解码Token，确认aud(受众) 声明是否是你的应用注册的Client ID，以及roles声明是否包含访问资源所需的角色（例如mcp.admin）。
  3. 确认你在创建适配器或工具时，requiredRoles数组设置是否正确。如果留空[]，则表示任何通过认证的用户（拥有有效Token）都可访问。如果你设置了["mcp.engineer"]，则Token中必须包含此角色。
• 根本解决：仔细按照文档docs/entra-app-roles.md的步骤，确保角色已创建、并正确分配给了测试用户或服务主体。

问题3：从公网无法访问部署的服务。

• 排查：
  1. 检查Application Gateway的公共IP地址是否已分配且状态正常：az network public-ip show -g <资源组> -n mg-pip-<label> --query ipAddress。
  2. 检查Application Gateway的后端池健康状态。在Azure门户中，进入你的应用网关 -> “后端健康”。确保网关实例的健康探测是成功的。
  3. 检查网络安全组和Azure防火墙规则，确保允许从互联网到Application Gateway前端IP的HTTPS（443）流量。

5.3 性能与扩展性问题

问题：在高并发下，网关响应变慢或出现错误。

• 监控指标：查看Application Insights中的“服务器响应时间”、“请求率”和“失败请求”图表。查看AKS的节点CPU/内存使用率。
• 可能瓶颈及优化：
  1. 网关Pod CPU/内存不足：增加Deployment的replicas，并配置HPA基于CPU利用率（如70%）自动扩缩容。
  2. 工具网关路由器成为瓶颈：工具调用需要经过两次代理（网关->路由器->工具服务器）。如果工具调用非常频繁，考虑增加路由器副本数。更激进的优化是，对于性能关键的工具，可以考虑让其直接作为适配器部署，通过/adapters/{name}/mcp直接访问，绕过路由器层。
  3. 会话存储（Cosmos DB）延迟高：检查Cosmos DB的请求单位使用率是否达到上限。考虑增加RU/s，或优化会话数据的结构和查询。
  4. MCP服务器本身性能差：这是最常见的原因。使用APM工具对你自己开发的MCP服务器进行性能剖析，优化慢查询或计算密集型操作。

MCP Gateway将一个复杂的AI后端架构问题，封装成了一组清晰的API和可部署的组件。从本地实验到云端生产，它提供了一条清晰的路径。我的体会是，最大的价值不在于它本身的功能多强大，而在于它定义了一种标准化的、云原生的方式来管理和消费AI能力。这为团队协作、能力复用和系统运维带来了巨大的便利。如果你正在为如何管理越来越多的AI工具和模型而头疼，花时间深入了解一下MCP Gateway，很可能会为你打开一扇新的大门。