作者：葉浩田

背景

傳統(tǒng)的 Serverless 平臺(tái)一般都是面向無(wú)狀態(tài)應(yīng)用的，通過(guò)將請(qǐng)求分發(fā)到不同的可以自動(dòng)擴(kuò)展的函數(shù)實(shí)例，從而為應(yīng)用提供極致的彈性、按量付費(fèi)等能力。然而，針對(duì)存在會(huì)話概念的應(yīng)用，傳統(tǒng)的 Serverless 平臺(tái)就不能夠在后端有多個(gè)副本的情況下，將屬于某個(gè)會(huì)話的請(qǐng)求轉(zhuǎn)發(fā)到服務(wù)該會(huì)話的函數(shù)實(shí)例，從而該類應(yīng)用無(wú)法在不引入外部存儲(chǔ)同步會(huì)話狀態(tài)的情況下運(yùn)行在 Serverless 平臺(tái)上。外部存儲(chǔ)的引入是有代價(jià)的，一方面，某個(gè)函數(shù)的能擴(kuò)展的副本數(shù)量/會(huì)話數(shù)量，會(huì)受到存儲(chǔ)能被多少函數(shù)實(shí)例并發(fā)訪問(wèn)的限制，另外一方面，訪問(wèn)持久化存儲(chǔ)/通過(guò)網(wǎng)絡(luò)訪問(wèn)外部存儲(chǔ)都會(huì)引入額外的開(kāi)銷。函數(shù)計(jì)算通過(guò) Session 機(jī)制的引入，以一種更簡(jiǎn)單的方式支持了該類應(yīng)用在 Serverless 平臺(tái)的運(yùn)行。

MCP 協(xié)議通過(guò)標(biāo)準(zhǔn)化的方式，將外部數(shù)據(jù)源和 LLM 進(jìn)行了連接，從而 LLM 可以從外部數(shù)據(jù)源獲取數(shù)據(jù)，也可以對(duì)外部的內(nèi)容產(chǎn)生作用。在之前的文章中，我們介紹了 MCP SSE 親和的實(shí)現(xiàn)，在這篇文章中，我們跟隨社區(qū)的升級(jí)腳步，將 MCP SSE 協(xié)議升級(jí)為 MCP Streamable 協(xié)議，并在函數(shù)計(jì)算平臺(tái)上，通過(guò)對(duì)應(yīng)親和類型的支持，讓最新的 MCP Server 也可以運(yùn)行在 Serverless 平臺(tái)之上。

概念介紹

函數(shù)計(jì)算：函數(shù)計(jì)算是事件驅(qū)動(dòng)的全托管計(jì)算服務(wù)。使用函數(shù)計(jì)算，您無(wú)需采購(gòu)與管理服務(wù)器等基礎(chǔ)設(shè)施，只需編寫(xiě)并上傳代碼或鏡像。函數(shù)計(jì)算為您準(zhǔn)備好計(jì)算資源，彈性地、可靠地運(yùn)行任務(wù)，并提供日志查詢、性能監(jiān)控和報(bào)警等功能。

MCP：作為開(kāi)放標(biāo)準(zhǔn)協(xié)議，為 AI 應(yīng)用構(gòu)建了通用化上下文交互框架?？梢詫?MCP 想象成 AI 應(yīng)用程序的 USB-C 接口。就像 USB-C 為設(shè)備連接各種外設(shè)和配件提供了標(biāo)準(zhǔn)化方式一樣，MCP 為 AI 模型連接不同的數(shù)據(jù)源和工具提供了標(biāo)準(zhǔn)化方式。

MCP 的三種 Transport：

• Stdio：Client 和 Server 部署在同一臺(tái)機(jī)器上，通過(guò)標(biāo)準(zhǔn)輸入、輸出傳輸信息。
• MCP SSE：MCP 的 SSE（Server-Sent Events）傳輸方式是一種基于 HTTP 的單向通信協(xié)議，允許服務(wù)器通過(guò)事件流向客戶端推送數(shù)據(jù)，但需要維護(hù) HTTP POST 和 SSE 兩個(gè)端點(diǎn) 。
• MCP Streamable HTTP：MCP 的 Streamable HTTP 傳輸方式則是一種更高效的替代方案，它利用標(biāo)準(zhǔn)的 HTTP POST 和 GET 請(qǐng)求來(lái)處理多個(gè)客戶端連接，旨在解決 SSE 在遠(yuǎn)程傳輸中的限制并提供更低的延遲和更好的并發(fā)性能 。

為什么你的 MCP 服務(wù)應(yīng)該升級(jí)到 MCP Streamable HTTP協(xié)議

HTTP+SSE 的傳輸方式存在缺陷

1. 不支持重新連接/恢復(fù)： 當(dāng) SSE 連接斷開(kāi)時(shí)，所有會(huì)話狀態(tài)都會(huì)丟失，需要客戶端重新建立連接并初始化整個(gè)會(huì)話。例如，正在執(zhí)行的大文檔分析任務(wù)可能會(huì)因?yàn)椴环€(wěn)定的 WiFi 而完全中斷，迫使用戶重新開(kāi)始整個(gè)過(guò)程。
2. 服務(wù)器必須保持長(zhǎng)連接： 服務(wù)器必須為每個(gè)客戶端維護(hù)一個(gè)長(zhǎng)時(shí)間的 SSE 連接，當(dāng)大量用戶并發(fā)時(shí)，這會(huì)導(dǎo)致資源消耗顯著增加。當(dāng)服務(wù)器需要重啟或擴(kuò)展時(shí)，所有連接都會(huì)中斷，這對(duì)用戶體驗(yàn)和系統(tǒng)可靠性產(chǎn)生負(fù)面影響。
3. 服務(wù)器消息只能通過(guò) SSE 傳輸：即使對(duì)于簡(jiǎn)單的請(qǐng)求-響應(yīng)交互，服務(wù)器也必須通過(guò) SSE 通道返回信息，這會(huì)帶來(lái)不必要的復(fù)雜性和開(kāi)銷。由于需要維護(hù)長(zhǎng)時(shí)間的 SSE 連接。
4. 基礎(chǔ)設(shè)施兼容性限制許多現(xiàn)有的網(wǎng)絡(luò)基礎(chǔ)設(shè)施，如 CDN、負(fù)載均衡器和 API 網(wǎng)關(guān)，可能無(wú)法正確處理長(zhǎng)壽命的 SSE 連接。企業(yè)防火墻可能會(huì)強(qiáng)制關(guān)閉超時(shí)連接，導(dǎo)致服務(wù)不穩(wěn)定。

Streamable HTTP 引入關(guān)鍵改進(jìn)

1. 統(tǒng)一端點(diǎn)：移除專用的 /sse 和/message 端點(diǎn)，允許所有通信通過(guò)單一端點(diǎn)進(jìn)行（目前在官方 SDK 中實(shí)現(xiàn)為 /mcp）。
2. 按需流式傳輸：服務(wù)器可以靈活選擇返回標(biāo)準(zhǔn)的 HTTP 響應(yīng)或?qū)⑦B接升級(jí)為 SSE 流。
3. 靈活初始化：客戶端可以通過(guò)一個(gè)空的 GET 請(qǐng)求主動(dòng)初始化 SSE 流。
4. 會(huì)話可恢復(fù)：Streamable HTTP 協(xié)議中，只要客戶端沒(méi)有顯式刪除 Session 或者服務(wù)端定期清理掉了 Session，因?yàn)檫B接斷開(kāi)的 Session 都是可以繼續(xù)使用的。

從一些實(shí)驗(yàn)的對(duì)比中，可以看到：

• 在連接數(shù)上， Streamable HTTP 方案的 TCP 連接數(shù)明顯低于 HTTP + SSE 方案
• 在不同并發(fā)用戶數(shù)下的請(qǐng)求成功率測(cè)試中，Streamable HTTP 的成功率顯著高于 HTTP + SSE 方案
• 在性能上，Streamable HTTP 在響應(yīng)時(shí)間方面具有明顯優(yōu)勢(shì)，Streamable HTTP 的平均響應(yīng)時(shí)間更短，響應(yīng)時(shí)間波動(dòng)較小，隨并發(fā)用戶數(shù)增加，響應(yīng)時(shí)間增長(zhǎng)更平，而 HTTP + SSE 的平均響應(yīng)時(shí)間更長(zhǎng)，在高并發(fā)場(chǎng)景下響應(yīng)時(shí)間波動(dòng)較大。因此，鑒于 MCP Streamable HTTP 服務(wù)的各項(xiàng)改進(jìn)，更推薦將 MCP 服務(wù)升級(jí)到 Streamable HTTP 傳輸。

兩者更詳細(xì)的對(duì)比如下：

特征	MCP SSE	MCP Streamable HTTP
請(qǐng)求路徑	sse：/sse 或者其他自定義路徑消息：/message	/mcp，可自定義，支持 GET 和 POST 方法
響應(yīng)傳輸方式	SSE 協(xié)議+HTTP	同步 HTTP 請(qǐng)求或者 SSE 協(xié)議
會(huì)話保持時(shí)間	只要 sse 連接存在，會(huì)話一直存在	直到客戶端發(fā)送 HTTP DELETE 請(qǐng)求刪除 Session 或者服務(wù)端超時(shí)機(jī)制清理 Session
SessionID 傳遞方式	通過(guò) url	通過(guò) HTTP Header 傳遞
是否支持會(huì)話重連	不支持	支持
Session 是否可選	必須	可選，客戶端也可以不攜帶 SessionID 訪問(wèn) Server

MCP Streamable HTTP 協(xié)議傳輸解析

客戶端主動(dòng)發(fā)送消息到服務(wù)端

MCP SSE

在 SSE 方式下，Client 向 Server 發(fā)送請(qǐng)求通過(guò)/message 端點(diǎn)實(shí)現(xiàn)，每個(gè)請(qǐng)求是一個(gè)異步的 HTTP 請(qǐng)求，如果 MCP Server 接收該請(qǐng)求，則在響應(yīng)中返回 202 狀態(tài)碼，后續(xù)的請(qǐng)求處理結(jié)果則會(huì)通過(guò) Client 和 Server 維持的 SSE 長(zhǎng)鏈接返回。

在該方式下，請(qǐng)求中會(huì)攜帶 id 信息，在后續(xù) SSE 的響應(yīng)中，針對(duì)同一個(gè)請(qǐng)求的 Response，id 設(shè)置為相同的值，client 就可以知道響應(yīng)是針對(duì)哪個(gè)請(qǐng)求返回的（json-rpc 的約定）。

# client發(fā)送給server的請(qǐng)求
POST /messages/?session_id=706c5bb094fe43c89a6cb33fb96f470d HTTP/1.1
host: 127.0.0.1:8000
connection: keep-alive
Accept: text/event-stream
content-type: application/json
accept-language: *
sec-fetch-mode: cors
user-agent: node
accept-encoding: gzip, deflate
content-length: 8

{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{"_meta":{"progressToken":1}}}

# server的異步返回
HTTP/1.1 202 Accepted
date: Thu, 31 Jul 2025 07:50:51 GMT
server: uvicorn
content-length: 8


# sse的返回結(jié)果
event: message
data: {"jsonrpc":"2.0","id":1,"result":{"tools":[{"name":"calculate_bmi","description":"Calculate BMI given weight in kg and height in meters","inputSchema":{"properties":{"weight_kg":{"title":"Weight Kg","type":"number"},"height_m":{"title":"Height M","type":"number"}},"required":["weight_kg","height_m"],"title":"calculate_bmiArguments","type":"object"},"outputSchema":{"properties":{"result":{"title":"Result","type":"number"}},"required":["result"],"title":"calculate_bmiOutput","type":"object"}},{"name":"fetch_weather","description":"Fetch current weather for a city","inputSchema":{"properties":{"city":{"title":"City","type":"string"}},"required":["city"],"title":"fetch_weatherArguments","type":"object"},"outputSchema":{"properties":{"result":{"title":"Result","type":"string"}},"required":["result"],"title":"fetch_weatherOutput","type":"object"}}]}

MCP Streamable HTTP

根據(jù)協(xié)議的約定，可以有如下兩種工作的流程

1、同步返回結(jié)果：

2、通過(guò) SSE 返回調(diào)用結(jié)果：

區(qū)別

MCP SSE 中 Client 和 Server 始終要保持一個(gè)長(zhǎng)鏈接，請(qǐng)求通過(guò)新的短連接發(fā)起，通過(guò) SSE 長(zhǎng)鏈接返回調(diào)用結(jié)果。而在 MCP Streamable HTTP 中，針對(duì)處理速度比較快或者不能分批返回的調(diào)用，Server 可以同步在響應(yīng)中返回調(diào)用結(jié)果，針對(duì)處理速度比較慢可以分批返回的結(jié)果，Server 可以將鏈接升級(jí)為 SSE 連接，將調(diào)用結(jié)果分批返回（比如其他大語(yǔ)言模型的輸出）。在對(duì)應(yīng)的請(qǐng)求處理結(jié)束后，與 MCP SSE 仍然保持著 SSE 連接用于后續(xù)請(qǐng)求的結(jié)果返回不同，Streamable HTTP 會(huì)在對(duì)應(yīng)的請(qǐng)求處理結(jié)果都通過(guò)對(duì)應(yīng)的 SSE 連接返回后，關(guān)閉其使用的 SSE 連接，新的請(qǐng)求需要發(fā)起新的 SSE 連接而不能復(fù)用之前的 SSE 連接。

服務(wù)端消息推送機(jī)制

MCP SSE

在 SSE 方式下，由于 Client 和 Server 維持著 SSE 的長(zhǎng)鏈接，因此，Server 到 Client 的 Notifications 都可以通過(guò)這條 SSE 鏈接發(fā)送。

MCP Streamable HTTP

在 MCP Streamable HTTP 下，Server 如果要發(fā)送消息到 Client，是沒(méi)有辦法實(shí)現(xiàn)的，因此，協(xié)議在/mcp（也可以是自定義的其他路徑上）支持了 GET 請(qǐng)求，用于建立 Client 到 Server 的一條 SSE 的長(zhǎng)鏈接。

同時(shí)，如果在 GET 請(qǐng)求中攜帶了 Last-Event-ID 頭，則表明該 SSE 連接是針對(duì)前述客戶端請(qǐng)求的錯(cuò)誤回復(fù)，MCP Server 可以在該 SSE 流上繼續(xù)傳輸之前沒(méi)有傳輸完成的消息，實(shí)現(xiàn)錯(cuò)誤回復(fù)。

會(huì)話管理

MCP SSE

在 MCP SSE 的官方協(xié)議說(shuō)明中，并沒(méi)有看到關(guān)于 Session 說(shuō)明，在其他的三方文檔和 SDK 的實(shí)現(xiàn)中，可以看到有關(guān)的約定。

會(huì)話管理：

每個(gè) SSE 連接都有唯一的會(huì)話標(biāo)識(shí)，在 Message 請(qǐng)求中會(huì)包含該會(huì)話標(biāo)識(shí)：

1. 客戶端發(fā)起 SSE 連接；
2. 服務(wù)端通過(guò) Endpoint URL 消息，發(fā)送 SessionID 信息；
3. 客戶短通過(guò) Endpoint URL 發(fā)送后續(xù)的消息。

抓包的結(jié)果也和有關(guān) SDK 的說(shuō)明吻合：

plain
# 客戶端發(fā)起SSE連接
GET /sse HTTP/1.1
host: 127.0.0.1:8000
connection: keep-alive
Accept: text/event-stream
accept-language: *
sec-fetch-mode: cors
user-agent: node
pragma: no-cache
cache-control: no-cache
accept-encoding: gzip, deflate

# Server返回結(jié)果，異步返回endpoint信息
HTTP/1.1 200 OK
date: Thu, 31 Jul 2025 08:51:27 GMT
server: uvicorn
cache-control: no-store
connection: keep-alive
x-accel-buffering: no
content-type: text/event-stream; charset=utf-8
Transfer-Encoding: chunked


# SSE返回Endpoint
event: endpoint
data: /messages/?session_id=c6cf551d4d5a4594961b18a8d74998b7

# 客戶端發(fā)送initialized通知
POST /messages/?session_id=c6cf551d4d5a4594961b18a8d74998b7 HTTP/1.1
host: 127.0.0.1:8000
connection: keep-alive
Accept: text/event-stream
content-type: application/json
accept-language: *
sec-fetch-mode: cors
user-agent: node
accept-encoding: gzip, deflate
content-length: 222

{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{"sampling":{},"elicitation":{},"roots":{"listChanged":true}},"clientInfo":{"name":"mcp-inspector","version":"0.16.2"}}}

# Server返回initialized響應(yīng)
HTTP/1.1 202 Accepted
date: Thu, 31 Jul 2025 08:51:27 GMT
server: uvicorn
content-length: 8

# Client發(fā)起后續(xù)請(qǐng)求
POST /messages/?session_id=c6cf551d4d5a4594961b18a8d74998b7 HTTP/1.1
host: 127.0.0.1:8000
connection: keep-alive
Accept: text/event-stream
content-type: application/json
accept-language: *
sec-fetch-mode: cors
user-agent: node
accept-encoding: gzip, deflate
content-length: 222

{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{"sampling":{},"elicitation":{},"roots":{"listChanged":true}},"clientInfo":{"name":"mcp-inspector","version":"0.16.2"}}}

#其他的忽略

MCP Streamable HTTP

一個(gè) MCP “會(huì)話”（session）是指客戶端與服務(wù)器之間映射關(guān)系，通過(guò) initialize 階段發(fā)起。一個(gè)支持 Session 管理的 MCP 服務(wù)需要滿足：

1. 使用 Streamable HTTP 傳輸?shù)姆?wù)器在初始化時(shí)分配一個(gè)會(huì)話 ID，將其包含 InitializeResult 的 HTTP 響應(yīng)的頭部字段 Mcp-Session-Id 中。

- 會(huì)話 ID 應(yīng)該是全局唯一且密碼學(xué)安全的（例如：安全生成的 UUID、JWT 或加密哈希值）。
- 會(huì)話 ID 必須僅包含可見(jiàn) ASCII 字符（范圍從 0x21 到 0x7E）。

2. 如果服務(wù)器在初始化過(guò)程中返回了 Mcp-Session-Id，則使用 Streamable HTTP 傳輸?shù)目蛻舳吮仨氃谒泻罄m(xù)的 HTTP 請(qǐng)求中包含該 Mcp-Session-Id 頭字段。

- 支持會(huì)話的 MCP 服務(wù)器應(yīng)該對(duì)缺少 Mcp-Session-Id 頭字段（除初始化請(qǐng)求外）的請(qǐng)求返回 HTTP 400 Bad Request。

3. 服務(wù)器可以在任意時(shí)間終止會(huì)話，之后它必須對(duì)包含該會(huì)話 ID 的請(qǐng)求返回 HTTP 404 Not Found。
4. 當(dāng)客戶端收到一個(gè)包含 Mcp-Session-Id 的請(qǐng)求返回 HTTP 404 時(shí)，它必須通過(guò)發(fā)送一個(gè)新的不帶會(huì)話 ID 的 InitializeRequest 來(lái)啟動(dòng)一個(gè)新會(huì)話。
5. 當(dāng)客戶端不再需要某個(gè)特定會(huì)話時(shí)（例如用戶正在退出客戶端應(yīng)用），它應(yīng)該向 MCP 端點(diǎn)發(fā)送一個(gè)帶有 Mcp-Session-Id 頭字段的 HTTP DELETE 請(qǐng)求，以顯式終止該會(huì)話。

- 服務(wù)器可以對(duì)該請(qǐng)求返回 HTTP 405 Method Not Allowed，表示服務(wù)器不允許客戶端主動(dòng)終止會(huì)話。

兼容性

服務(wù)端

服務(wù)端如果要保持向后兼容，則必須同時(shí)支持兩種通信方式：
POST+SSE: 需要有兩個(gè)端點(diǎn)，/sse 和/messge,分別支持 SSE 和 POST 請(qǐng)求
Streamable Http: 一個(gè)新的端點(diǎn)/mcp，支持新版通信方式。
也就是說(shuō)，服務(wù)端要有三個(gè)端點(diǎn)，兩種通信方式互相獨(dú)立同時(shí)存在。官方不建議將兩者融合在一起。

客戶端

客戶端可以直接嘗試將 InitializeRequest POST 到服務(wù)器 URL。
如果成功，客戶端可以假定這是支持新 Streamable HTTP 傳輸?shù)姆?wù)器。
如果失敗且服務(wù)端返回 HTTP 4xx 狀態(tài)代碼，則向服務(wù)器 URL 發(fā)出 GET 請(qǐng)求，期望這將打開(kāi) SSE 流并返回 endpont 事件（舊版通信方式中的一個(gè)事件）作為第一個(gè)事件。當(dāng) endpoint 事件到達(dá)時(shí)，客戶端可以假定這是運(yùn)行舊 HTTP+SSE 傳輸?shù)姆?wù)器，并應(yīng)將該傳輸用于所有后續(xù)通信。

整體的流程圖

FC MCP Streamable HTTP 親和機(jī)制

FC 為 MCP Streamable HTTP 單獨(dú)增加了一種親和類型，通過(guò)配置該親和類型，如果函數(shù)運(yùn)行的是 MCP Streamable HTTP 傳輸?shù)?Server，同一個(gè) Session 的請(qǐng)求都會(huì)被轉(zhuǎn)發(fā)到會(huì)話所屬的函數(shù)實(shí)例上。

會(huì)話管理

函數(shù)計(jì)算作為集調(diào)度、計(jì)算托管、免運(yùn)維等特性于一身的 Serverless 服務(wù)，可將函數(shù)計(jì)算核心組件抽象為三部分：

1. Gateway：網(wǎng)關(guān)層，用戶流量入口，負(fù)責(zé)接收用戶請(qǐng)求、鑒權(quán)、流控等功能。
2. Scheduler：調(diào)度引擎層，負(fù)責(zé)將用戶的請(qǐng)求調(diào)度到合適的節(jié)點(diǎn)和實(shí)例。
3. VMS：資源層，函數(shù)執(zhí)行環(huán)境。

根據(jù) Session 階段的不同，將 Session 的生命周期分為三部分：會(huì)話初始化、會(huì)話中以及會(huì)話結(jié)束三部分分別介紹函數(shù)計(jì)算在三個(gè)階段如何實(shí)現(xiàn)的會(huì)話管理。

會(huì)話初始化

1. Client 根據(jù)協(xié)議的約定,通過(guò) Initialize 請(qǐng)求，發(fā)起 MCP 會(huì)話的初始化，網(wǎng)關(guān)節(jié)點(diǎn)權(quán)限校驗(yàn)通過(guò)后轉(zhuǎn)發(fā)至調(diào)度模塊 Scheduler。
2. 調(diào)度模塊根據(jù)特定標(biāo)識(shí)識(shí)別出請(qǐng)求類型為 MCP Streamable HTTP 時(shí)，將調(diào)度到一臺(tái)可用實(shí)例。
3. 當(dāng)請(qǐng)求和實(shí)例綁定時(shí)，實(shí)例將啟動(dòng)用戶代碼。
4. 用戶代碼啟動(dòng)完成后，將會(huì)將會(huì)話信息通過(guò)響應(yīng)的 Mcp-Session-Id 頭部返回。
5. 在 response 返回經(jīng)過(guò) Gateway 網(wǎng)關(guān)層時(shí)，網(wǎng)關(guān)層將攔截 Mcp Initialize 請(qǐng)求的首個(gè)回包，解析 SessionID 信息，并將 SessionID 和實(shí)例的映射關(guān)系持久化到 DB。

整體流程和 MCP SSE 親和的會(huì)話初始化階段相同，區(qū)別是提取會(huì)話標(biāo)識(shí)的方式不同。

數(shù)據(jù)鏈路（會(huì)話中）

1. Client 完成 MCP Initialize 請(qǐng)求后，將發(fā)起 MCP 的后續(xù)請(qǐng)求，由于函數(shù)計(jì)算網(wǎng)關(guān)節(jié)點(diǎn)無(wú)狀態(tài)， Message 請(qǐng)求將打散到多個(gè)網(wǎng)關(guān)節(jié)點(diǎn)。
2. 當(dāng) Gateway 收到 MCP 請(qǐng)求，將檢查網(wǎng)關(guān)節(jié)點(diǎn) cache 中是否存在 MCP 請(qǐng)求攜帶的 SessionID 親和信息，如果 cache 中無(wú)記錄，將回源到 DB 獲取相關(guān)數(shù)據(jù)。
3. Gateway 通過(guò) cache 或 DB 拿到 SessionID 和實(shí)例的綁定關(guān)系時(shí)，將攜帶相關(guān)信息轉(zhuǎn)發(fā)至調(diào)度模塊。
4. 調(diào)度模塊根據(jù) SessionID 信息，根據(jù)歷史的會(huì)話狀態(tài)，將請(qǐng)求定向調(diào)度到特定實(shí)例。
5. 后續(xù)請(qǐng)求被正確轉(zhuǎn)發(fā)到對(duì)應(yīng)的實(shí)例，MCP Server 返回 SSE 數(shù)據(jù)或者是同步的 HTTP 響應(yīng)。

整體流程和 SSE 是類似的，區(qū)別是 MCP Streamable HTTP 中，不區(qū)分 Message 消息和管控消息。

會(huì)話結(jié)束

由于 MCP 本身協(xié)議的約定，在 MCP SSE 傳輸方式下，SSE 連接斷開(kāi)就標(biāo)識(shí)著會(huì)話的結(jié)束。但是在 MCP Streamable HTTP 場(chǎng)景下，會(huì)話在被客戶端顯示 DELETE 之后，才會(huì)結(jié)束，因此有如下的會(huì)話結(jié)束的鏈路。

鏈路和會(huì)話初始化是類似的，區(qū)別是服務(wù)端返回之后，函數(shù)計(jì)算網(wǎng)關(guān)會(huì)更新 DB 中的會(huì)話狀態(tài)，標(biāo)識(shí)會(huì)話已結(jié)束。

同時(shí)，MCP Streamable HTTP 還在協(xié)議層的生命周期的約定的基礎(chǔ)上，增加了其他的親和生命周期約束，包括 SessionTTL 和 SessionIdleTimeout 機(jī)制。

SessionTTL：限制 Session 的最大生命周期，TTL 之前，如果客戶端沒(méi)有發(fā)起 DELETE 請(qǐng)求結(jié)束會(huì)話，函數(shù)計(jì)算調(diào)度層會(huì)清理過(guò)期的會(huì)話數(shù)據(jù)，釋放 Session 占用的相關(guān)資源。

SessionIdleTimeout：限制 Session 的空閑時(shí)間，超過(guò) IdleTimeout 之后，如果客戶端沒(méi)有發(fā)起 DELETE 請(qǐng)求結(jié)束會(huì)話，函數(shù)計(jì)算調(diào)度層會(huì)清理過(guò)期的會(huì)話數(shù)據(jù)，釋放 Session 占用的相關(guān)資源。

通過(guò)會(huì)話層的 DELETE 結(jié)束約定以及平臺(tái)側(cè)的生命周期管理機(jī)制，函數(shù)計(jì)算在 MCP Streamable HTTP 場(chǎng)景下，提供了完善的 MCP Session 的生命周期管理。

Session 配額

引入 Session Concurrency 策略，即結(jié)合函數(shù)實(shí)例的并發(fā)度配置，限制每個(gè)實(shí)例最多綁定 n 個(gè) Session?？蛻粜杞Y(jié)合實(shí)際業(yè)務(wù)場(chǎng)景需求配置合理的限制項(xiàng)：

• 親和模式場(chǎng)景僅限制實(shí)例最大并發(fā) Session 數(shù)，單實(shí)例下所有 session 并發(fā)請(qǐng)求數(shù)最大 200。

配額類型	含義	是否可調(diào)	限制	消耗規(guī)則	配額回收機(jī)制
單實(shí)例最大并發(fā)度	單實(shí)例最多同時(shí)處理的最大并發(fā)請(qǐng)求數(shù)，超出并發(fā)上限的請(qǐng)求將路由到其他實(shí)例或拒絕限流。	不可調(diào)整	200	每個(gè) TCP 連接占用 1	請(qǐng)求處理完成后異步釋放
單實(shí)例最大并發(fā) Session 數(shù)	單實(shí)例最多同時(shí)處理的 Session 數(shù)，多 Session 下的請(qǐng)求共享 200 并發(fā)配額。	可調(diào)整	[1,200]	每個(gè)邏輯會(huì)話占用 1 個(gè)配額	Session TTL/Session Idle/ 顯式標(biāo)識(shí)會(huì)話結(jié)束

優(yōu)雅升級(jí)/輪轉(zhuǎn)

在 MCP 場(chǎng)景下，數(shù)據(jù)請(qǐng)求從請(qǐng)求級(jí)無(wú)狀態(tài)變?yōu)闀?huì)話級(jí)綁定，在 UpdateFunction 后，如果存量 Session 關(guān)聯(lián)的請(qǐng)求路由到新實(shí)例，則新增無(wú)法識(shí)別到 SessionID 信息，返回錯(cuò)誤。為解決這類問(wèn)題，函數(shù)計(jì)算優(yōu)雅更新能力從無(wú)狀態(tài)請(qǐng)求級(jí)別升級(jí)至有狀態(tài) Session 級(jí)別，在用戶更新函數(shù)后，存量 Session 關(guān)聯(lián)的請(qǐng)求仍路由到舊實(shí)例，新建 Session 請(qǐng)求路由至新實(shí)例，優(yōu)雅實(shí)現(xiàn) MCP 親和場(chǎng)景下的升級(jí)需求。

演示

1、創(chuàng)建一個(gè) Web 函數(shù)，親和類型選擇 MCP Streamable HTTP 親和

2、函數(shù)創(chuàng)建完成之后，選擇觸發(fā)器，配置 HTTP 的訪問(wèn)方式為 Bearer，為該函數(shù)的訪問(wèn)入口配置安全措施；

3、本地啟動(dòng) Mcp Inspector，將 Bearer Token 信息和觸發(fā)器的地址信息拼接 MCP 的服務(wù)端點(diǎn)，填入 Mcp Inspector 的對(duì)應(yīng)配置選項(xiàng)中。（詳情可參考官網(wǎng)：https://modelcontextprotocol.io/docs/tools/inspector）

點(diǎn)擊 Connect 之后，發(fā)起會(huì)話，后續(xù)就可以使用 MCP Streamable HTTP 提供的服務(wù)了。

總結(jié)

函數(shù)計(jì)算跟隨 MCP 社區(qū)的動(dòng)態(tài)，在 MCP SSE 親和之后，推出了 MCP Streamable HTTP 親和，讓廣大開(kāi)發(fā)者可以將自己的服務(wù)升級(jí)到 MCP Streamable HTTP 傳輸，并結(jié)合 Bearer 認(rèn)證，即獲得性能上的提升，也更安全的暴露自己的服務(wù)。