Web函式請求多併發上線，Web服務部署更快更省！

Web函式（Web Function）是雲函式的一種函式型別，區別於事件函式（Event Function），Web函式通過支援原生的HTTP/WebSocket協議，相容任意一種原生Web框架編寫的Web服務，無需改造即可將傳統專案部署到函式，保證和本地開發服務體驗一致。

自21年6月推出以來，廣受歡迎，數萬傳統Web專案輕鬆遷移到函式上，讓老程式碼也能在Serverless基礎設施上繼續發光。然而，隨著Web函式在更多場景得到應用，一些問題也逐漸暴露出來。

一、Web函式請求單併發

預設情況下，在呼叫函式時，雲函式會分配一個併發例項處理請求或事件。函式程式碼執行完畢返回後，該例項會處理其他請求。如果在請求到來時，所有例項都在執行中，雲函式則會分配一個新的併發例項。一個併發例項同一時刻僅處理一個事件的執行邏輯，保障每個事件的處理效率和穩定性。

在大多數情況下，請求單併發都是值得推薦使用的模式，無需在寫程式碼時考慮多個請求同時處理帶來的典型併發難題，例如執行緒安全、阻塞呼叫、異常處理等。

而在Web應用中，典型的業務場景是IO密集型——函式內訪問資料庫或其他系統的介面等下游服務，會有較多時間在等待這些下游服務響應。這種等待一般都是在做iowait，不怎麼消耗CPU，此時，單例項單併發模式則會產生兩個問題:

計算資源浪費，在websocket長連線中尤為突出；
計費略高，每一個同時進來的請求因為分配在不同的例項中進行處理，單獨計費，整體費用較傳統容器或主機方案沒有優勢。

二、Web函式請求多併發

Web函式目前已經支援請求多併發模式，您可以根據業務需要進行啟用和配置。請求多併發支援自定義靜態併發、智慧動態併發兩種模式。

（一）自定義靜態併發

啟用後，當同時有多個請求，將不超過指定併發值的請求排程到同一函式例項內執行。併發增多，將增加函式例項的CPU、記憶體等消耗，建議配合壓力測試進行合理設定，避免函式執行異常。目前支援的併發範圍為2～100併發。

（二）智慧動態併發

啟用後，在函式例項負載允許的情況下，智慧動態排程更多請求到同一函式例項內執行。將於後續推出，敬請期待。

三、壓測

多併發vs單併發壓測結果：最大請求延遲降低82.7%，成本節約98.8%

測試說明：

在北京地域準備一個Web函式，模擬請求響應時間500ms，函式配置為512MB。

在北京市準備公網壓測環境，分別壓測未開啟多併發和開啟100多併發時的表現，壓測條件為：100併發，持續請求50000次。

未開啟請求多併發：需要60個例項，最大響應時間4177ms，計費記憶體時間12500GBs

客戶端壓測結果：最大響應時間4177ms，平均響應時間為569ms。壓測開始時，函式接收到100併發請求，立即開始冷啟動拉起函式例項，在冷啟動過程中，頭幾批請求開始等待，最長響應時間為4177ms，而隨著例項拉起來正常處理請求，則新的併發請求會被立即均勻分配到多個例項中進行處理，因此後續的大多數請求等待時間小，整體平均響應時間被拉平，迴歸到正常水平。

函式監控截圖：一開始冷啟動瞬間拉起了100個例項，後續例項輪轉複用，平穩在60例項。計費時間為0.5GB0.5s50000=12500GBs。

開啟請求多併發：僅需1個例項，最大響應時間723ms，計費時長150GBs

客戶端壓測結果：最大響應時間723ms，平均響應時間為565ms。壓測開始時，函式接收到100併發請求，立即開始冷啟動拉起函式例項，在冷啟動過程中，頭一批請求開始等待，最長響應時間為723ms，而隨著第一個例項被拉起來，新的併發請求會被立即分配到該例項中進行處理。處於等待冷啟動中的請求數要顯著少於未開啟多併發時。

函式監控截圖：併發請求進入，所有請求被分配到一個函式例項進行立即處理。