MCP 服务端部署：无状态之后，负载均衡到底怎么配
数据截至 2026-07，价格与限额以各官网为准。
如果你的 MCP 远程服务端过去是靠粘性会话撑起来的，那么 2026-07-28 这版规范之后，最该做的事不是加东西，而是删东西——把网关上的会话保持、共享 session 存储、为了识别请求类型而做的深度包检测统统拆掉，退回最普通的轮询负载均衡，再按 Mcp-Method 头做路由。协议层已经不要求会话追踪了，你的基础设施没有理由继续为它买单。
先承认一个很常见的误解：不少人一听”MCP 无状态化”，第一反应是”那 MCP 以后不能有状态了？我的服务端要维护数据库连接、要缓存用户上下文，是不是都不合规了？“不是这个意思。变的是协议层——协议不再要求你追踪会话；应用层想不想维护状态、怎么维护，那是另一回事，规范管不着，也没打算管。把这两层分开看，后面所有部署决策才不会拧巴。
这次改的是什么：先建立正确的心智模型
官方博客把 2026-07-28 这次发布称为自协议发布以来最大的一次修订，兑现的是 2026 年路线图。改动分六块：无状态协议内核、Extensions 框架、Tasks、MCP Apps、授权加固，外加一套正式的弃用策略。
其中跟运维关系最直接的就是第一块。无状态化不是一句口号，而是由 6 个 SEP（Specification Enhancement Proposal，规范增强提案）共同落地的，完成了此前《The Future of MCP Transports》里规划的方向。落到你的部署图上，结论只有一句：协议层不再要求会话追踪。
维护者 David Soria Parra 对这次改动的评价相当直白——这是自加入授权以来最实质的变更，他的原话是：“A lot of things that made MCP are gone.”（很多曾经定义 MCP 的东西没了。）这句话值得放在心上：不要指望这是一次可以无脑升级的小版本迭代。
负载均衡：从粘性会话退回普通轮询
这是最有获得感的一处变化。
旧的部署形态里，远程 MCP 服务端通常要满足三件事：网关做粘性会话（sticky session），保证同一个客户端后续请求落回同一个实例；多实例之间要有共享 session 存储（Redis 之类）兜底，防止实例重启或扩缩容时会话丢失；网关还得做深度包检测，因为它得看懂请求体才知道这条请求该怎么处理。三件事叠在一起，结果就是一个本该很轻的服务，被逼出了一套重基础设施。
新规范之后，这三件事都可以拆。官方明确给出的实际影响是：以前需要粘性会话、共享 session 存储、网关做深度包检测的远程服务器，现在可以直接跑在普通轮询负载均衡后面，按 Mcp-Method 头路由。
具体到配置层面，可操作的动作大致是这几步：
- 先删粘性策略。Nginx 里的
ip_hash、基于 cookie 的 sticky 模块，云厂商 ALB/SLB 上的”会话保持”开关，能关就关。关掉之后默认回到轮询或最少连接（least_conn），后者在长短请求混杂时更均匀一些。 - 再评估共享 session 存储还留不留。这一步别急着删。协议不要求会话追踪，不等于你的业务不依赖它——如果你在 session 里塞了业务态（比如用户的工作区上下文、鉴权后的身份缓存），那它属于应用层状态，删了会出事。判断标准很简单：这份状态是协议逼你存的，还是你自己业务要存的。前者可以清，后者留着，但建议把它从”会话”重命名成它真正的业务含义，免得下次重构又被概念误导。
- 最后拆掉网关上的深度包检测。这类规则往往是历史包袱里最脏的一块——为了在七层网关上解析请求体做分流，通常会写一堆 Lua 或自定义插件。既然现在有了显式的
Mcp-Method头，就没必要再拆包了。 - 健康检查同步简化。无状态实例的健康检查可以退回最朴素的形式，探活通过即可进池，不用再关心”这个实例上还挂着谁的会话”。
- 扩缩容策略可以放开。这是无状态化带来的连锁收益：实例可以随时被回收，滚动更新不用再等会话排空（drain），HPA 之类的自动扩缩容也不再有”缩容会踢掉用户”的顾虑。
Mcp-Method 头能拿来做什么
Mcp-Method 这个头的意义，是把”这条请求要干什么”从请求体里提到了传输层，网关不用理解 MCP 的载荷就能做分流决策。
典型用法是按方法类型分池：把重的、慢的方法路由到一组资源更足的实例，把轻的、高频的方法路由到另一组；或者对特定方法单独设限流、单独设超时、单独打日志采样。在 Nginx 里这可以是一段 map $http_mcp_method $backend_pool 的映射，在云网关上通常是一条”按请求头匹配”的转发规则，都不需要额外插件。
有两点提醒：一是不要把这个头当鉴权依据——它是客户端发来的，可以被伪造，权限判断必须落在授权链路上；二是分池会带来运维复杂度，如果你的流量还没大到需要区分冷热方法，先老老实实一个池轮询，别提前优化。
授权链路要跟着一起改
这次修订里，授权同样由 6 个 SEP 加固，方向是让授权规范更贴近真实世界的 OAuth 2.0 / OpenID Connect 部署形态——也就是说，以前那种”半标准”的做法会越来越难混过去。
具体到必须做的事，规范里点名的一条是：要求客户端按 RFC 9207 校验 iss 参数（SEP-2468）。这条对部署的含义是，如果你的授权服务器签发的响应里没有正确带上 iss，或者你的客户端实现从来没校验过这个参数，升级后就会在授权环节直接卡住。排查这类问题时，建议顺序是：先确认授权服务器的响应带没带 iss、值对不对，再确认客户端 SDK 版本有没有实现这项校验，最后才去怀疑网络和网关。
顺带一提，Mcp-Method 分池之后，授权中间件的位置别放错——它应该在分流之后、业务处理之前对每条请求独立生效，而不是依附于某个”会话已鉴权”的假设。会话没了，那种”登录一次、整条会话免检”的写法就是个隐患。
Tasks 移出核心：长任务的部署形态变了
原本用于长时间运行操作的 Tasks 特性，这次从核心协议移到了 extension。同时新规范引入了 Extensions 框架，用户可以自建 extension，与官方认可的 extension 并存。
对部署的影响是两层。第一层是依赖检查：如果你的服务端功能建立在长任务之上，升级前要先确认对应的 extension 在你这条技术栈上可用，不能默认它还在核心里。第二层更微妙——长任务天然是有状态的，把它从核心挪走，恰恰是把”协议内核保持无状态”和”某些场景确实需要长期态”这两件事解耦开了。这也反过来印证了前面那句：无状态说的是协议层，不是禁止你做有状态的事。
新旧不兼容：12 个月窗口怎么用
这是升级计划里最需要写进日程表的一条：2026-07-28 版本的 server 可能无法与旧 client 协同，反之亦然。不是”可能有点小问题”，是双向都可能直接跑不通。
好在这次同时给出了正式的弃用策略：弃用机制给旧版本 12 个月窗口。这个窗口的正确用法不是拖到最后一个月才动，而是拿来做灰度：
- 先盘客户端。你的服务端被哪些客户端调用、各自什么版本，先列出来。自家应用好办，第三方客户端要预留沟通时间。
- 新旧并行跑一段。有条件的话，新旧版本服务端各起一组，网关按版本分流，让旧客户端继续走旧组，新客户端走新组，观察一段时间再收敛。
- 把基础设施改造放在协议升级之后。先升协议、验证连通，再拆粘性会话和共享存储。两件事同时做，出问题很难定位是协议不兼容还是负载均衡配错了。
- 不要跳过预发环境。这次改动幅度摆在这里，直接在生产上滚是自找麻烦。
发布与发现：注册表和 Server Cards
部署完还要让人找得到。官方 MCP Registry 的地址是 registry.modelcontextprotocol.io，提供 server 发现、文档与 API 参考，由 modelcontextprotocol GitHub 组织维护，是社区驱动的。
路线图上还有一项跟部署直接相关的工作叫 MCP Server Cards——通过 .well-known URL 暴露 server 元数据的标准，让注册表和爬虫不用真的连上你的 server 就能发现它的能力。如果你在做面向外部的 server，这条值得提前留意：它意味着未来”被发现”这件事可能落到你的 HTTP 服务器配置上，而不只是靠去注册表里登记。
生态背景也交代一句：2025 年 12 月，Anthropic 把 MCP 捐给了 Linux 基金会下的 Agentic AI Foundation，从此是厂商中立、社区治理的标准，OpenAI、Google、Microsoft、AWS 都已把它接进自家 agent 栈。按官方与行业公开资料的口径，目前有超过 10,000 个公开 MCP server 跑在生产环境，SDK 月下载量超过 9,700 万——这两个数字是公开资料汇总口径，不是精确统计，看个量级就好。
诚实说局限
有几件事必须讲清楚，免得你按这篇去拍板：
- 这篇写在规范发布当天。时效性极强，中文资料几乎为零，所以任何细节都请以官方博客与规范文档的当前版本为准，不要拿这篇当规范原文用。
- 网上不少中文资料已经过期。有站点到现在还把 2025-11-25 那版列为当前稳定版、把下一版说成”暂定 2026 年 6 月”，这类内容已经不成立，不要照抄。判断信源新不新，看它有没有提到无状态内核和 Extensions 框架就够了。
- 具体的配置写法这篇没给完整样例。
Mcp-Method的取值集合、传输层细节、SDK 各语言的实现进度，都以官方文档为准；这篇给的是决策顺序和排查思路，不是可以直接粘贴上生产的配置文件。 - 不同网关的能力差异很大。自建 Nginx、Envoy、云厂商托管网关，在按请求头路由和关闭会话保持这两件事上的做法都不一样，需要你结合自己的栈落地。
小结
一，MCP 这次改的是协议层的无状态，不是禁止你的应用有状态，这两层千万别混。二，最直接的运维红利是负载均衡可以从粘性会话退回普通轮询，共享 session 存储和网关深度包检测大多可以拆掉，扩缩容和滚动更新跟着变轻。三，Mcp-Method 头让网关不拆包也能分流，但它不能当鉴权依据。四，授权链路要跟着改，iss 校验这条不做就会卡住，Tasks 已经移到 extension，依赖它的先做兼容确认。五，新旧版本双向可能不兼容，12 个月的弃用窗口要用来做灰度而不是用来拖延，一切细节以官方文档当前版本为准。