Function Compute：會話親和通用限制及原理說明

1. Cookie親和專屬限制

• 僅支援服務端植入 Cookie 模式：
  用戶端首次訪問時，Function Compute自動在響應中通過 Set-Cookie Header 植入 Cookie。用戶端需解析並儲存該 Cookie，並在後續請求中攜帶。
  

• 支援 SessionAPI 管理：
  可通過 SessionAPI 對會話進行生命週期管理（如建立、更新、查詢、終止等）。
  

2. HeaderField親和專屬限制

• 會話 ID 來源：

  • 若用戶端在預定義 Header 中傳入會話 ID，則以該值作為會話標識。

  • 若未傳入，服務端將產生全域唯一會話 ID，通過CreateFunction預定義的Header欄位，通過響應 Header 返回。

• Header 欄位定義：
  在建立函數時，於 SessionAffinityConfig 中指定用於傳輸會話 ID 的 Header 欄位名。
  

• 支援 SessionAPI 管理：
  可通過 SessionAPI 實現對會話的監控與控制。
  

3. MCP Streamable HTTP親和專屬限制

• 協議版本要求：
  支援 MCP 協議版本 2025-03-26 和 2025-06-18。用戶端與函數必須遵循對應版本的 Transport 層規範。
  

• 相容性說明：若函數啟用了 MCP Streamable HTTP 親和，則 禁止使用 MCP HTTP with SSE 調用，因會話管理機制不相容，導致調用失敗。

• 訪問方式限制：
  僅支援通過 HTTP 觸發器 或 自訂網域名 訪問。
  

• HTTP 觸發器配置要求：
  必須至少支援 GET、POST 和 DELETE 方法。
  

  DELETE 方法必要性：
  用戶端可通過 DELETE 請求主動結束會話。Function Compute將回收該 Session 的資源（包括執行個體並發配額）。若未啟用 DELETE 方法，系統將拒絕請求，導致 Session 無法正常釋放。
  

• 不支援 SessionAPI 管理。

4. MCP SSE親和專屬限制

• 運行時限制：

  • 使用內建運行時 → 不支援 MCP SSE 親和。

  • 使用 MCP 運行時 → 僅支援 MCP 親和（含 SSE）。

  • 其他運行時無此限制。

• 用戶端要求：
  必須使用 MCP 官方標準 Client 或 SDK 發起請求，否則無法建立有效親和串連。
  

• 會話生命週期：
  最大生命週期等於函數的最大逾時時間。超出後，服務端中斷連線；重新串連將產生新會話 ID，不再保證路由至原執行個體。
  

• 訪問方式限制：
  僅支援通過 HTTP 觸發器 或 自訂網域名 訪問。
  

• 要求節流：

  • 首次 SSE 請求暫不支援攜帶 query 參數。

  • 單一實例最大並發數為 200。

• 不支援 SessionAPI 管理。

1. 核心流程

用戶端發起請求 → 識別/產生 Session ID → 綁定到可用執行個體 → 後續請求路由至該執行個體

2. 資源模型（統一架構）

• 每個 Session 佔用 1 個 “Session 並發配額”

• 每個 請求（包括 POST、GET、Message）佔用 1 個 “請求並發配額”

• 單一實例總並發額度：200（不可調）

• 多個 Session 共用這 200 個並發額度

公式表達：

TotalQuota = Σ(每個 Session 的並發消耗) ≤ 200

3. 生命週期管理

並發參數說明

單會話佔用並發資源模型

單一實例並發Session數配置建議：

1. 安全隔離情境：建議配置1，單個Session獨享計算資源，安全可靠。

2. 多租共用情境：可配區間（1，200]，多Session共用單一實例資源，提升資源使用率

情境1：Session 和執行個體綁定規則及擴容機制

假設函數配置單一實例並發 Session 數 = 2

1. Client1 請求 → 分配 Instance1，佔用 1 個 Session 配額

2. Client2 請求 → Scheduler 判斷 Instance1 仍有 1 個空閑 Session → 成功綁定

3. Client3 請求 → Instance1 已滿 → 建立新執行個體 Instance2 → 綁定成功

關鍵點說明：

• 系統在調度層會儘力優先複用已有執行個體，但不完全保證

• 僅當所有執行個體均滿時才會擴容

• 實現了動態負載平衡與Auto Scaling

情境2：單一實例下多 Session 共用資源限流機制

假設函數配置單一實例並發 Session 數 = 2

1. Client1 請求 → 佔用 1 個 Session + 1 個請求並發度

2. Client2 請求 → 佔用 1 個 Session + 1 個請求並發度

3. 前兩個請求未結束時，兩者同時並發再次發送 198 個請求 → 總共消耗 200 個請求並發度

4. 第 199 個請求 → 超出 200 上限 → 返回 `429 Too Many Requests`

關鍵點說明：

• 單一實例最大並發度固定為 200，不可調

• 多個 Session 共用此額度

• 當並發度耗盡時，系統拒絕新請求