MCP 规范转向无状态核心后怎么落地：横向扩展与会话迁移的工程影响

把 MCP 服务从单实例搬到多实例后，最先暴露的往往不是吞吐，而是“同一个客户端下一次请求落到了另一台机器”。如果会话状态、SSE 连接和重连游标都藏在进程内，负载均衡一切换，调用就可能变成 400、404，或者看起来连接还在、结果却回不来。MCP 近期围绕 Streamable HTTP 和更适合云环境的无状态核心给出了新的工程方向，但它不是把服务器复制几份就结束了。

多实例故障通常从一次重连开始

假设客户端第一次初始化落在实例 A，服务端返回了 MCP-Session-Id；后续请求经过网关时，实例 B 没有这段会话，最容易出现两种结果：B 直接拒绝缺少或未知的会话，或者重新初始化后丢掉原来的交互上下文。若响应是 HTTP 404，客户端还必须知道这是会话结束，按协议重新发起初始化，而不是无脑重放原业务请求。

这也是新闻里“无状态更适合横向扩展”落到工程现场后的真实含义：请求处理节点可以替换，但会话恢复所需的最小信息必须可验证、可迁移，或者干脆由客户端重新建立。这里别急着先改负载均衡策略，先把一次调用的生命周期画成日志字段。

先把协议事实和部署推断分开

官方传输规范目前定义了 stdio 和 Streamable HTTP。后者使用一个同时支持 POST 与 GET 的 MCP 端点，客户端通过 POST 发送 JSON-RPC 消息，服务端可以返回 JSON 或 SSE。规范还明确了 MCP-Session-Id、MCP-Protocol-Version、Last-Event-ID 等字段的语义。

“无状态核心能让服务横向扩展”是架构层面的推断，不等于每个实现都已经自动无状态。你的服务仍可能把工具执行上下文、长任务结果、重复投递去重键或权限租约放在本地内存里。迁移前应列出这些数据的所有者和生命周期，再决定哪些放到共享存储，哪些在断线后允许重建。

迁移分三阶段：先兼容，再切路由

第一阶段：把单实例状态暴露出来

给初始化、每次 POST、GET 重连和工具完成事件都记录请求 ID、会话 ID 的哈希、协议版本、实例标识和结果状态。不要把完整会话 ID 或用户凭据写进普通日志。先在一台实例上确认：同一会话连续请求的状态从哪里读取，断线后最后一个事件 ID 如何保存。

这一阶段的成功状态不是“接口返回 200”，而是能拿一条请求链回答：哪个实例创建了会话、哪个实例处理了后续请求、重连从哪个游标开始、是否发生了重复结果。

第二阶段：让状态可以被另一台实例接住

对会话做两类拆分。协议层只保留必要的会话标识、版本与权限边界；业务层把长任务、工具副作用和结果查询放进可恢复的共享记录。若某个工具调用已经提交到外部系统，断线重连时不能把原 JSON-RPC 请求当成新任务再执行，应使用幂等键或先查任务状态。

type RequestContext struct {
    SessionID       string
    ProtocolVersion string
    RequestID       string
    LastEventID     string
}

// 处理原则：上下文可在实例间验证；
// 长任务通过 task_id 查询；
// 具有副作用的工具必须先做状态确认。

第三阶段：灰度切换与旧客户端兜底

先让网关同时认识新 MCP 端点和旧 HTTP+SSE 入口。对新端点，检查 POST 初始化是否得到协议可识别的响应；若遇到兼容性错误，再按旧传输规则尝试 GET 并等待 endpoint 事件。灰度期间把客户端类型、协议版本、错误码和重连成功率分开统计，不能拿所有 404 混在一起。

网关路由不能只靠粘滞会话

粘滞会话可以暂时减少问题，却没有解决实例重启、扩容缩容和长连接断开后的恢复。新架构更值得验证的是：不带本地状态的请求是否能被任意健康实例接收；需要会话的请求是否有明确的存储读取；SSE 断线后，客户端是否使用最后的事件游标而不是重放未知请求。

Streamable HTTP 的安全边界也要一并搬过去。服务端应校验 Origin，本地服务只绑定回环地址，所有连接都有合适的认证。负载均衡器不要为了“优化”而删除协议版本头、会话头或 Last-Event-ID；如果必须改写，先做端到端契约测试。

发布门禁：用故障注入证明真的可扩展

• 初始化后立刻摘除原实例，后续请求由另一实例接管，确认会话处理结果符合预期。
• 在 SSE 已发出部分事件时断开连接，使用 Last-Event-ID 重连，核对不会跨流重复投递。
• 人为发送错误或不支持的 MCP-Protocol-Version，确认服务返回明确的 400，而不是静默按旧协议猜测。
• 让旧客户端访问新网关，验证新端点失败时能够进入旧 HTTP+SSE 兼容路径。
• 对有副作用的工具连续提交相同请求 ID，确认外部系统只有一次实际变更。

这些测试比压一个漂亮的并发数字更能说明迁移质量。MCP 的消息仍是 JSON-RPC，连接管理变了，不代表重复执行、权限和数据一致性问题自动消失。

回滚要回到端点和数据边界

如果灰度后发现旧客户端大量重连失败，先把流量切回旧入口，保留新端点的只读观测；不要删除共享会话数据，也不要让新旧实现同时写同一份任务记录而没有版本字段。对已提交的外部工具调用，回滚只能影响后续路由，不能把已经发生的副作用“回滚成没发生”。

复盘时至少保留四类证据：协议版本分布、会话跨实例成功率、SSE 恢复与重复投递计数、旧客户端兼容比例。若其中一项没有数据，下一轮发布仍然是在盲切。

常见问题

MCP 无状态后还需要 MCP-Session-Id 吗？

是否返回由服务端实现决定，但只要实现建立了会话，客户端就必须按协议在后续请求中携带它。无状态部署关注的是会话能否被可靠验证和恢复，不是简单删掉这个字段。

收到 HTTP 404 就应该重放原请求吗？

不应该。若 404 是带会话请求得到的会话终止信号，客户端应重新初始化；对有副作用的原请求还要先查任务状态，避免重复执行。

Last-Event-ID 能解决所有断线问题吗？

不能。它只提供流恢复的游标线索，服务端还要按流保存事件、保证 ID 范围正确，并处理事件已过期、任务已完成或结果不可重放等情况。

迁移时可以一直保留粘滞会话吗？

可以作为过渡手段，但它不能替代跨实例恢复测试。扩缩容、实例故障和多地域部署都会削弱粘滞策略的可靠性。

MCP 走向更适合云环境的无状态核心，真正改变的是工程团队对“请求落到哪台机器”的依赖。先把协议头、会话数据、长任务和副作用拆开，再用断线、换实例、旧客户端和版本错误做灰度门禁，迁移才有可复查的边界。