通过开启MCP Streamable HTTP亲和功能，函数计算可以将属于同一个MCP会话的请求路由到生成该会话的后端函数实例上。函数计算会在MCP Streamable HTTP会话初始化时，解析使用MCP Streamable HTTP传输的函数的HTTP响应头Mcp-Session-Id字段，将其与平台侧的会话进行关联，后续携带相同Mcp-Session-Id的请求被认为属于同一个MCP Streamable HTTP会话，将路由至初始化会话的函数实例。当收到DELETE请求终止会话时，系统清除平台侧与MCP Streamable HTTP关联的会话，并释放该会话占用的并发资源。
注意事项
客户端通过DELETE请求主动结束MCP Streamable HTTP亲和的会话时，函数计算在系统层面回收该Session的资源，包括该Session占用的实例Session并发配额等。此时，请确保函数配置的HTTP触发器支持DELETE请求，否则函数计算系统会拒绝DELTE请求，从而导致MCP Streamable HTTP的Session无法正常结束。
实现原理
函数计算抽象架构
函数计算作为Serverless服务，实现弹性调度、计算托管与免运维能力。可将函数计算核心组件抽象为三部分：
Gateway：网关层，用户流量入口，负责接收用户请求、鉴权、流控等功能。
Scheduler：调度引擎层，负责将用户的请求调度到合适的实例。
Instance：具体的函数实例。
由于Gateway在Session处理的部分比较细节且琐碎，不便于理解函数计算MCP Streamable HTTP的Session亲和实现原理，因此为了便于理解，本文所有流程图中将省略Gateway，将Client请求直接指向Scheduler。实际客户端和函数计算的组件交互时，一定会经过函数计算的Gateway。
Session 并发管理
在MCP Streamable HTTP会话资源需求模型中，单Session生命周期内存在两类并发需求：
M(M>=1)个SSE长连接，占用M个并发Quota。N(N>=1)个POST请求，占用 N 个并发 Quota。
TotalQuota(s)=M+N(M>=1,N>=1)
您需结合实际业务场景需求配置合理的限制项：
非亲和模式场景可根据业务需求调整单实例并发度。亲和模式场景仅限制实例最大并发Session数，单实例下所有Session并发请求数最大为200。
并发参数类型 | 含义 | 是否可调 | 限制 | 消耗规则 | 并发回收机制 |
单实例最大并发度 | 单实例最多同时处理的最大并发请求数，超出并发上限的请求将路由到其他实例或拒绝限流。 | 不可调整 | 200 | 每个请求/长连接占用1个并发 | 请求处理完成后异步释放 |
单实例并发Session数 | 单实例在同一个时间内能同时处理的最大 Session 数，多Session下的请求共享 200 并发度 | 可调整 | [1,200] | 每个MCP Streamable HTTP的Session占用1个Session数 | DELETE会话的响应或者是TTL、IdleTimeout触发异步释放 |
会话亲和预期行为（实例调度规则）
场景1：Session和实例绑定规则及Session触发实例扩容机制
函数计算引入单实例并发Session数策略，限制每个实例最多绑定n个Session。如下流程所示：
假设函数配置了可绑定2个Session，Client1发起MCP Streamable HTTP的初始化Session请求时，分配到Instance1实例，并占用1个Session并发。
Client2发起MCP Streamable HTTP的初始化Session请求时，Scheduler计算Instance1仍有1个可用Session，成功和Instance1再次完成绑定。
Client3发起MCP Streamable HTTP的初始化Session请求时，Scheduler计算Instance1实例的2个并发Session数已被2个MCP Streamable HTTP的Session占用，无法再次绑定，则调度到新实例Instance2，完成实例绑定。
场景2：单实例下多Session共享资源限流机制
场景2.1: 客户端请求MCP Streamable HTTP传输的函数时，只使用同步的POST请求。
假设函数配置了Session配额为2，Client1发起Session1请求时，分配了Instance1实例。
Client2发起Session2请求时，Scheduler计算Instance1 仍有1个可用并发Session，成功和Instance1再次完成绑定，此时实例消耗2个并发Session。
Session1和Session2并发200个POST请求，此时实例消耗2个并发Session+200个请求并发度。
当发起第201个POST请求时，单实例200请求并发度已耗尽，请求限流返回 429。
场景2.2: 客户端请求MCP Streamable HTTP传输的函数时，同时使用SSE长连接和同步的POST请求。
假设函数配置了Session配额为2，Client1发起Session1请求时，分配了Instance1实例，随后Client1发起了1个GET请求，和Instance1建立了一条SSE的长连接。
Client2发起Session2请求时，Scheduler计算Instance1 仍有1个可用并发Session，成功和Instance1再次完成绑定，此时实例消耗2个并发Session，随后Client2发起了1个GET请求，和Instance1建立了一条SSE的长连接。
Session1和Session2并发198个POST请求，此时实例消耗2个并发Session+200个请求并发度。
当发起第199个POST请求时，单实例200请求并发度已耗尽，请求限流返回 429。
函数平滑更新
在 MCP 场景下，数据请求从请求级无状态变为会话级绑定，在UpdateFunction后，如果存量Session关联的请求路由到新实例，则新增无法识别到 SessionID 信息，返回错误。为解决这类问题，函数计算优雅更新能力从无状态请求级别升级至有状态Session级别，在用户更新函数后，存量Session关联的请求仍路由到旧实例，新建Session请求路由至新实例，优雅实现MCP亲和场景下的升级需求。
计费说明
会话亲和费用 = 处理请求的弹性实例（活跃）费用 + 实例保活期间的弹性实例（闲置）费用
关于弹性实例（活跃）和弹性实例（闲置）费用计算说明，请参见计费概述。