L1ngg's Home

1. 快速感知与连接状态管理（Connection Level）#

不可用故障往往分为两类：静默死锁/网络黑洞 与 进程崩溃/显式断开。Client 需要双轨检测：

• 传输层直接感知：
  • Stdio 模式：监听底层子进程的 exit / close 事件以及 stderr 的异常管道信号，在毫秒级捕捉进程退出。
  • SSE / HTTP 模式：监听 EventSource 的 onerror 事件或 TCP 断连；对长轮询或流式连接设置严格的 ReadTimeout（如 5s）。
• 应用层探活（Heartbeat Ping）：
  • MCP 协议基于 JSON-RPC 2.0，天然支持双向 ping 请求。
  • Client 维护周期性心跳定时器（例如 10s 发送一次 {"jsonrpc": "2.0", "id": 1, "method": "ping"}）。若连续 2 次无响应或超过超时阈值（如 3s），即刻判定 Server 失联。
• 熔断机制（Circuit Breaker）：
  • 维护 Server 实例的滑动时间窗口错误率。一旦失败率超过设定阈值（例如 50%）或探测失败，立即将该 Server 标记为 Open 熔断状态，阻断后续新请求直接快速失败，避免线程和连接池耗尽。
• 平滑重连与抖动退避（Exponential Backoff with Jitter）：
  • 后台重连线程接管恢复逻辑，禁止固定间隔的高并发雪崩式重连。
  • 采用指数退避加随机抖动策略：

• 重新握手必须严格走全套 MCP 生命周期（initialize → notifications/initialized），确认能力对齐后再将熔断器恢复为 Closed。

2. 状态隔离与能力动态注销（State Cleanup）#

若仅在网络层捕获异常，而未在 Agent 上下文中同步状态，模型就会在后续推理思考中持续产生 工具幻觉调用。

• 动态下线注册项：
  • Client 维护当前 Session 的可用能力路由表（Tool Registry、Resource Registry、Prompt Registry）。
  • 当某个 Server 进入不可用状态后，必须立即触发上下文热更新事件，从发送给 LLM 的 tools 列表中剔除该 Server 贡献的所有工具声明。
• 对齐协议通知机制：
  • MCP 协议规范定义了 notifications/tools/list_changed 等事件。Client 端在内部状态机中模拟该事件流，通知上下文构建模块刷新下一轮推理的 Tool Schema 视图。

3. Agent 业务层降级与模型自愈（Graceful Degradation & Self-Correction）#

如果崩溃发生时，恰好有一个 Tool Call 正在执行，Client 必须阻断异常外溢并协助模型决策：

1
{
2
  "jsonrpc": "2.0",
3
  "id": "call_1024",
4
  "result": {
5
    "isError": true,
6
    "content": [
7
      {
8
        "type": "text",
9
        "text": "TOOL_UNAVAILABLE: The weather_query service is temporarily unreachable. Please consider alternative methods, explain the situation to the user, or continue without this information."
10
      }
11
    ]
12
  }
13
}

• 将系统故障转化为语义化输入：
  • 不要向大模型直接抛出 ECONNRESET 或底层堆栈，应将错误包装为符合 MCP CallToolResult 规范的标准错误格式（isError: true）。
  • 错误信息需包含清晰的指引（Hint），触发大模型的自我纠错（Self-Correction）循环，引导模型选择替代路径或向终端用户诚实解释。
• 透明冗余路由（Backup Fallback）：
  • 在 Client 的工具调度中心引入虚拟工具（Virtual Tool Alias）。若主 Server 宕机，透明重定向至同功能的 Secondary Server（例如将 weather_server_a 降级切换至 weather_server_b）。
• 资源缓存降级（Cache Fallback）：
  • 针对只读属性的 resources/read 请求，若底层数据源不可用，Client 自动回退并加载本地快照或最后一次成功的缓存副本，并在响应元数据中打上 stale: true 标记。

4. 结构化日志与 APM 可观测性（Observability）#

• 记录结构化审计日志：记录 Session ID、Run ID、Server 名称、异常阶段（握手 / 心跳 / 工具执行）、崩溃持续时间与熔断状态变更。
• 上报指标至 Prometheus / OpenTelemetry（如 mcp_server_up{server="db_query"} 0、mcp_tool_failure_count），超过阈值即时触发 PagerDuty 或告警推送给系统运维。

1. 通信架构定界：Stdio 与 网络传输 的本质区别#

• Stdio 模式（1:1 进程绑定）：通过父子进程标准输入输出流（stdin / stdout）进行通信。该模式天然是点对点独占的，无法原生支持多 Client 并发共享同一个 Server 进程。
• 网络传输模式（SSE / Stream HTTP / WebSocket）：多 Client 并发调用的前提必然是 基于网络协议暴露的独立服务，或者架构前方存在集中式代理层。

2. 服务端非阻塞架构与长耗时任务解耦#

MCP Server 处理的工具逻辑多为外部系统集成（数据库操作、外部 HTTP API 抓取、代码沙箱执行），属于典型的 I/O 密集型场景。

• 全链路异步事件驱动模型：
  • Server 底座必须基于非阻塞 I/O 运行时（Node.js Event Loop、Python AsyncIO、Go Goroutines、Rust Tokio）。
  • 杜绝在请求主线程中执行阻塞式系统调用（如同步 time.sleep、同步读写大文件），防止工作线程耗尽导致所有并发 Client 的请求队列积压。
• 长任务异步化与进度机制（Progress Decoupling）：
  • 当 Tool 执行耗时预估超过阈值（如 > 5s）时，避免维持长阻塞连接。
  • 方案 A（MCP 原生进度通知）：利用 MCP 的 Progress Token 机制（$/progress notification），在长任务执行期间持续向 Client 推送中间百分比或阶段状态，维持长连接保活并避免 Client 端误判超时。
  • 方案 B（Job 模式解耦）：对于超长任务（批处理分析、沙箱编译），Tool Call 立即返回一个带有状态的 job_id，Client 后续通过轮询或专用通知通道消费完成事件。

3. 流量控制、背压防护与优先级调度（Rate Limiting & Backpressure）#

多租户并发访问下，单一恶意或高频 Client 极易造成“吵闹邻居（Noisy Neighbor）”效应，耗尽 Server 资源。

4. 幂等计算与只读资源的多级缓存（Caching）#

大模型多轮会话交互中，经常存在重复拉取相同上下文或多次执行参数完全一致的只读探测工具：

• resources/read 强缓存：
  • 对于静态文档、配置信息、Git 仓库元数据等 MCP Resource，Server 端计算 ETag 或版本 Hash，在内存（LRU Cache）或分布式缓存（Redis）中加速读取，直接跳过底层文件或数据库 I/O。
• 只读 Tool 的入参 Hash 缓存：
  • 针对声明为具备幂等、只读属性的 Tool Call（如 search_documentation、get_user_profile），利用其入参 JSON 字符串的 SHA-256 作为 Cache Key。
  • 设置合理的 TTL（例如 60s），命中后直接返回预序列化报文，将 P99 响应延迟从数百毫秒压缩到 5 毫秒以内。

5. 下游资源池化与线程隔离#

MCP Server 本身即使具备异步处理能力，其依赖的下游后端（如 PostgreSQL、Redis、三方开放平台）也会成为瓶颈：

• 连接池管理（Connection Pooling）：
  • 严格限制数据库连接池的最大空闲数（MaxIdle）与最大活跃数（MaxActive），配置连接超时（Checkout Timeout）。
  • 防止 1000 个 Client 请求打入 Server 时，Server 瞬间向底层数据库建立 1000 个 TCP 连接而导致数据库端口耗尽或崩溃。
• 隔离舱模式（Bulkhead）：
  • 为不同关键度的 Tool 分配独立的内部工作线程池或并发限额。避免高耗时的“文件 OCR 识别工具”耗尽全部计算资源，导致轻量级的“时间查询工具”无法执行。

6. 无状态设计与集群横向扩展（Horizontal Scaling）#

要在多 Client 场景下实现真正的性能飞跃，单机垂直调优具有物理上限，必须满足 无状态横向扩展 要求：

架构核心准则

在多 Client 共享场景中，MCP Server 必须保持彻底无状态；所有会话历史、上下文窗口与推理状态均由 Client 自身维护，Server 仅作为无状态的工具执行算力单元。

• 保持 Server 进程绝对无状态（Stateless Server）：
  • 保证任何一个 Client 的请求路由到后端任意一个 Server 副本上，均能产出确定性一致的执行结果。
• 反向代理与长连接负载均衡：
  • 在 Server 前置引入 Nginx、Traefik 或 Envoy 进行流量分发。
  • 针对 SSE 这种长期保持的 HTTP 连接，传统轮询（Round Robin）容易导致长连接分布倾斜，必须采用 最小连接数（Least Connections） 算法。
  • 若部分高级场景 Server 内部维持了临时缓存热点，可配置一致性哈希（Consistent Hashing）或会话保持（Sticky Session）。

面试核心权衡与落地总结#

将上述方案收敛为两句话的架构决策准则：

1. 不可用靠“快速失败与语义自愈”：通信层依赖秒级心跳与熔断隔绝故障扩散，业务层将错误协议化包装并反哺模型促成自愈，上下文层动态剔除失效能力遏制幻觉。
2. 高并发靠“异步底座与网关解耦”：服务端以非阻塞事件驱动支撑并发，借助多级缓存与连接池保护下游，并将认证、流控、负载均衡与探活统一下沉至 MCP Gateway 控制面，保持底层 Server 彻底无状态，实现按需横向扩展。