MCP 如何与微服务架构结合？

MCP（Model Context Protocol）与微服务架构的结合，是构建可扩展 AI 应用系统的关键路径。MCP 本身采用客户端-服务器架构，天然契合微服务的拆分与独立部署理念。本文从实际架构设计出发，讲清楚 MCP 在微服务中怎么拆、怎么连、怎么管。

为什么 MCP 适合微服务架构

MCP 解决的核心问题是 AI 系统与外部工具集成的 N×M 复杂度——每个 AI 应用对接每个工具需要单独适配。MCP 将其简化为 N+M：每个 AI 应用实现一次客户端协议，每个工具实现一次服务器协议，即可互操作。

这与微服务架构解决的问题是同构的：微服务将单体应用拆分为独立服务，通过标准化协议通信；MCP 将 AI 能力拆分为独立工具服务器，通过标准化协议对接。两者叠加，可以构建出高度解耦、独立演进的 AI 微服务系统。

MCP 微服务架构的三层设计

shell
┌─────────────────────────────────────────────┐
│              API Gateway / BFF              │
│         (认证、限流、路由、协议转换)          │
├─────────────────────────────────────────────┤
│           MCP Client Layer                  │
│   ┌──────────┐ ┌──────────┐ ┌──────────┐   │
│   │ Client A │ │ Client B │ │ Client C │   │
│   └────┬─────┘ └────┬─────┘ └────┬─────┘   │
├────────┼────────────┼────────────┼──────────┤
│        └────────────┼────────────┘          │
│              MCP Server Layer               │
│   ┌──────────┐ ┌──────────┐ ┌──────────┐   │
│   │ DB MCP   │ │ API MCP  │ │ File MCP │   │
│   │ Server   │ │ Server   │ │ Server   │   │
│   └──────────┘ └──────────┘ └──────────┘   │
├─────────────────────────────────────────────┤
│          Infrastructure Layer               │
│   Consul / etcd / Kafka / Redis / Prometheus│
└─────────────────────────────────────────────┘

第一层：MCP Server——按业务域拆分

拆分粒度是第一个决策点。原则是按业务能力拆分，而非按技术层拆分：

拆分方式	示例	判断
按业务域	用户服务 MCP、订单服务 MCP、支付服务 MCP	正确：边界清晰，独立演进
按技术层	数据库 MCP、缓存 MCP、消息队列 MCP	错误：职责混杂，变更耦合

每个 MCP Server 独立部署，暴露三类能力：

• Tools：可调用的操作（如 create_order、query_user）
• Resources：可读取的数据（如 user://123/profile）
• Prompts：预定义的交互模板（如 analyze_order_trend）

python
# MCP Server 注册示例 - 按业务域拆分
from mcp.server import Server

order_server = Server("order-service")

@order_server.tool()
async def create_order(user_id: str, items: list) -> dict:
    # 创建订单，调用订单微服务的内部 API
    return await order_service.create(user_id, items)

@order_server.resource("order://{order_id}")
async def get_order(order_id: str) -> str:
    # 获取订单详情
    order = await order_service.get(order_id)
    return order.to_json()

第二层：MCP Client——编排与上下文管理

MCP Client 是 AI 应用与 MCP Server 之间的桥梁。在微服务架构中，Client 需要处理三件事：服务发现、连接管理和上下文聚合。

python
from mcp.client import Client

class MCPClientManager:
    # 管理多个 MCP Server 连接

    def __init__(self, service_discovery):
        self.discovery = service_discovery
        self.clients: dict[str, Client] = {}

    async def connect(self, server_name: str) -> Client:
        # 通过服务发现连接 MCP Server
        endpoint = await self.discovery.resolve(server_name)
        client = Client(f"{endpoint}/mcp")
        await client.connect()
        self.clients[server_name] = client
        return client

    async def aggregate_context(self, query: str) -> str:
        # 聚集多个 Server 的上下文
        contexts = []
        for name, client in self.clients.items():
            resources = await client.list_resources()
            for r in resources:
                if self._is_relevant(r, query):
                    content = await client.read_resource(r.uri)
                    contexts.append(f"[{name}] {content}")
        return "\n\n".join(contexts)

第三层：基础设施——服务发现与配置

MCP Server 作为微服务，需要注册到服务发现组件。关键区别在于：MCP Server 的健康检查不仅要检查 HTTP 端口，还要验证 MCP 协议握手是否正常。

python
# MCP Server 注册到 Consul（含协议级健康检查）
import consul

def register_mcp_server(consul_client, server_name, address, port):
    consul_client.agent.service.register(
        name=server_name,
        address=address,
        port=port,
        tags=["mcp", "v2"],  # 标记为 MCP 服务
        check=consul.Check.http(
            url=f"http://{address}:{port}/health",
            interval="10s",
            header={"MCP-Protocol-Version": ["2025-03-26"]}
        )
    )

三个关键集成模式

模式一：API Gateway 统一入口

在微服务架构中，API Gateway 是统一入口。MCP 的加入需要 Gateway 支持协议转换——外部请求通过 REST/GraphQL 进入，Gateway 将其翻译为 MCP 协议调用后端服务。

shell
客户端 → API Gateway → MCP Client → MCP Server
              │
              ├─ REST → MCP Tool Call
              ├─ GraphQL → MCP Resource Query
              └─ SSE → MCP Streamable HTTP

注意：MCP 2026 规范已将 HTTP Transport 升级为 Streamable HTTP，支持长连接和流式响应，Gateway 需要支持 SSE 透传。

模式二：MCP Server 作为 Sidecar

对于已有微服务，不需要重写代码。采用 Sidecar 模式，在现有服务旁边部署一个 MCP 适配器，将微服务的 API 翻译为 MCP 协议：

shell
┌──────────────────────┐
│      Pod             │
│  ┌───────┐ ┌───────┐│
│  │ User  │ │ MCP   ││
│  │ Svc   │←│Proxy  ││
│  │:8080  │ │:3000  ││
│  └───────┘ └───────┘│
└──────────────────────┘

这种模式的优势：零侵入改造现有服务，MCP Proxy 独立升级，不影响业务逻辑。

python
# Sidecar 模式的 MCP Proxy
from mcp.server import Server
import httpx

proxy = Server("user-service-mcp-proxy")
backend = httpx.AsyncClient(base_url="http://localhost:8080")

@proxy.tool()
async def get_user(user_id: str) -> dict:
    # 代理到用户微服务的 GET /users/{id}
    resp = await backend.get(f"/users/{user_id}")
    return resp.json()

@proxy.tool()
async def update_user(user_id: str, data: dict) -> dict:
    # 代理到用户微服务的 PUT /users/{id}
    resp = await backend.put(f"/users/{user_id}", json=data)
    return resp.json()

模式三：事件驱动的 MCP 编排

微服务间的异步通信通过消息队列。MCP 可以订阅 Kafka Topic，当事件到达时主动推送上下文给 AI 应用：

python
# MCP Server 订阅 Kafka 事件
from aiokafka import AIOKafkaConsumer
import json

@order_server.resource("order://events/recent")
async def recent_order_events() -> str:
    # 返回最近的订单事件流
    consumer = AIOKafkaConsumer(
        "order-events",
        bootstrap_servers="kafka:9092",
        auto_offset_reset="latest"
    )
    await consumer.start()
    events = []
    async for msg in consumer:
        events.append(json.loads(msg.value))
        if len(events) >= 10:
            break
    await consumer.stop()
    return json.dumps(events, ensure_ascii=False)

安全：MCP 微服务必须解决的三个问题

1. 服务间认证

MCP 2026 规范的 Auth 机制已从草案进入正式版。每个 MCP Server 必须验证 Client 的 OAuth 2.0 Token，而非简单信任网络边界：

python
from mcp.server import Server
from authlib.integrations.starlette import OAuth2Proxy

server = Server("secure-service", auth_provider=OAuth2Proxy(
    issuer="https://auth.example.com",
    audience="mcp-api"
))

# 未认证的请求将被拒绝
@server.tool()
async def sensitive_operation(data: dict) -> dict:
    # 只有携带有效 Token 的 Client 才能调用
    return await process(data)

2. 上下文隔离

MCP 的安全边界设计要求：Server 不能读取完整对话历史，只能收到必要的上下文。在微服务环境中，这意味着每个 MCP Server 只能访问自己业务域的数据，跨域调用必须通过 Client 编排。

3. 限流与熔断

AI 调用工具的频率可能远超人类操作。MCP Server 必须实现限流，防止 AI Agent 的重试风暴击穿后端服务：

python
from circuitbreaker import circuit

@circuit(failure_threshold=5, recovery_timeout=30)
@server.tool()
async def query_database(sql: str) -> list:
    # 带熔断的数据库查询
    return await db.execute(sql)

可观测性：追踪 AI 调用链

在微服务中追踪一次用户请求已经复杂，加入 MCP 后链路更长。需要端到端的 Trace ID 贯穿：用户请求 → API Gateway → MCP Client → MCP Server → 后端微服务。

python
from opentelemetry import trace, context

tracer = trace.get_tracer("mcp-service")

@server.tool()
async def create_order(user_id: str, items: list) -> dict:
    with tracer.start_as_current_span("mcp.tool.create_order") as span:
        span.set_attribute("mcp.server", "order-service")
        span.set_attribute("mcp.tool", "create_order")
        span.set_attribute("user.id", user_id)
        result = await order_service.create(user_id, items)
        span.set_attribute("order.id", result["id"])
        return result

决策清单：什么时候用 MCP 微服务

场景	建议
单个 AI 应用 + 少于 5 个工具	不需要微服务，单体 MCP Server 足够
多个 AI 应用共享工具集	拆分为独立 MCP Server，统一注册
工具调用需要独立扩缩容	按业务域拆分 MCP Server，独立部署
已有微服务需要 AI 化	Sidecar 模式，零侵入接入
AI Agent 需要跨域编排	MCP Client 聚合上下文，统一编排

总结

MCP 与微服务的结合不是简单叠加，而是架构层面的对齐：MCP 的客户端-服务器模型对应微服务的服务拆分与通信，MCP 的工具/资源/提示对应微服务的 API/数据/事件。核心原则是按业务域拆分 MCP Server、用 Sidecar 零侵入改造现有服务、通过 MCP Client 编排跨域调用。安全上必须启用 OAuth 2.0 认证和上下文隔离，可观测性上要保证 AI 调用链的端到端追踪。