Azure Functions 中的並行

本文說明 Azure Functions 中事件驅動觸發程序的並行行為。 其中還說明用於最佳化並行行為的新動態模型。

Functions 的裝載模型可讓多個函式引動過程在單一計算執行個體上同時執行。 例如，假設您在函式應用程式中有三個不同的函式，這會擴增並在多個執行個體上執行。 在此案例中，每個函式都會在函式應用程式執行所在的每個 VM 執行個體上處理引動過程。 單一執行個體上的函式引動過程會共用相同的 VM 計算資源，例如記憶體、CPU 和連線。 當應用程式裝載於動態方案 (取用或進階) 時，平台會根據傳入事件數目來擴大或縮減函式應用程式執行個體數目。 若要深入了解，請參閱事件驅動調整。 當您在專用 (App Service) 方案中裝載函式時，您可手動設定執行個體或設定自動調整配置。

由於多個函式引動過程可在每個執行個體上同時執行，因此每個函式都必須有辦法調節在任何指定時間處理的並行引動過程數目。

靜態並行

許多觸發程序都支援主機層級靜態設定模型，其用於指定該觸發程序類型的每個執行個體並行。 例如，服務匯流排觸發程序會在 host.json 檔案中提供 MaxConcurrentCalls 和 MaxConcurrentSessions 設定。 這些設定可一起控制每個函式在每個執行個體上同時處理的訊息數目上限。 其他觸發程序類型具有內建機制可跨執行個體平衡引動過程的負載。 例如，事件中樞和 Azure Cosmos DB 都會使用分割區型配置。

若為支援並行設定的觸發程序類型，您可選擇預設行為，以在函式應用程式的 host.json 檔案中覆寫。 這些設定適用於所有執行中的執行個體，可讓您控制每個執行個體上函式的並行上限。 例如，當函式耗用大量 CPU 或資源時，您可選擇限制並行，讓執行個體保持良好狀態。 同樣地，當函式對進行節流的下游服務提出要求時，您也應該考慮限制並行。

雖然這類並行設定可讓您控制某些觸發程序行為，例如調節函式，但可能難以判斷這些設定的最佳值。 一般而言，您必須透過負載測試的試用和錯誤程序來達到可接受的值。 即使您判斷一組用於特定負載設定檔的值，從連線服務送達的事件數目可能會每天變更。 這種變化表示您的應用程式通常以次佳的值執行。 例如，函式應用程式可能會在一周的最後一天處理要求特別高的訊息承載，這需要您調降並行。 不過，在一周的其餘時間內，訊息承載比較簡單，這表示您可在一周的其餘時間使用較高的並行層級。

在理想情況下，我們希望系統允許執行個體處理盡可能多的工作，同時讓每個執行個體保持良好狀態且較低延遲，也就是動態並行的設計訴求。

動態並行

函式現在提供動態並行模型，以簡化針對在相同方案中執行的所有函式應用程式設定並行。

注意

目前只有 Azure Blob、Azure 佇列和服務匯流排觸發程序支援動態並行，而且您必須使用以下延伸模組支援一節中列出的版本。

福利

使用動態並行可提供下列優勢：

• 簡化的設定：您不再需要手動判斷每個觸發程序的並行設定。 系統會隨著時間了解您工作負載的最佳值。
• 動態調整：並行會即時進行動態向上或向下調整，讓系統能夠隨著時間適應不斷變更的負載模式。
• 執行個體健康情況保護：執行階段會將並行限制為函式應用程式執行個體可輕鬆處理的層級。 這可防止應用程式因承擔比應有更多的工作而使本身多載。
• 改善的輸送量：整體輸送量已改善，因為個別執行個體不會提取比其可快速處理更多的工作。 這可讓工作在執行個體間更有效率地達到負載平衡。 對於可處理較高負載的函式，並行可增加至超出預設組態值的值，這可產生較高的輸送量。

動態並行設定

您可在 host.json 檔案中的主機層級啟用動態並行。 啟用支援動態並行之函數應用程式所使用的任何繫結延伸模組時，會視需要動態調整並行。 動態並行設定會覆寫支援動態並行之觸發程序的任何手動設定並行設定。

預設會停用動態並行。 啟用動態並行後，並行會針對每個函式從 1 開始，並調整為最佳值 (由主機決定)。

在 host.json 檔案中新增下列設定，即可在函式應用程式中啟用動態並行：

    { 
        "version": "2.0", 
        "concurrency": { 
            "dynamicConcurrencyEnabled": true, 
            "snapshotPersistenceEnabled": true 
        } 
    } 

當 SnapshotPersistenceEnabled 為 true (這是預設值) 時，學習到的並行值會定期保存到儲存體，所以新的執行個體會從這些值開始，而不是從 1 開始且必須重新進行學習。

並行管理員

在幕後，啟用動態並行時，會有並行管理員程序在背景中執行。 此管理員會持續監視執行個體健康情況計量 (例如 CPU 和執行緒使用率)，並視需要變更節流。 啟用一或多個節流時，函式並行會向下調整，直到主機再度狀況良好為止。 停用節流後，允許並行增加。 各種啟發學習法用於根據這些節流，以智慧方式視需要向上或向下調整並行。 隨著時間的推移，每個函式的並行都會穩定至特定層級。

系統會針對每個個別函式管理並行層級。 因此，系統會平衡需要低層級並行的資源密集型函式與可處理較高並行的輕量型函式。 每個函式的並行平衡有助於維護函式應用程式執行個體的整體健全狀況。

啟用動態並行後，您會在記錄中看到動態並行決策。 例如，您會在啟用各種節流時，以及每次針對每個函式向上或向下調整並行時看到記錄。 這些記錄會寫入追蹤資料表中的 Host.Concurrency 記錄類別之下。

延伸模組支援

動態並行會針對主機層級的函式應用程式啟用，以及針對支援在該模式中執行動態並行的任何延伸模組啟用。 動態並行需要主機與個別觸發程序延伸模組之間的共同作業。 只有下列延伸模組列出的版本支援動態並行。

Azure 佇列

Azure 佇列儲存體觸發程序有自己的訊息輪詢迴圈。 使用靜態設定時，並行是由 BatchSize/NewBatchThreshold 設定選項所控管。 使用動態並行時，這些組態值會被忽略。 動態並行已整合到訊息迴圈中，因此會動態調整每次反覆項目擷取的訊息數目。 啟用節流 (主機多載) 時，訊息處理將會暫停，直到節流停用為止。 停用節流後，並行將會增加。

若要對佇列使用動態並行，您必須使用 5.x 版的儲存體延伸模組。

Azure Blob

在內部，Azure Blob 儲存體觸發程序會使用 Azure 佇列觸發程序所使用的相同基礎結構。 需要處理全新/已更新的 Blob 時，訊息會寫入平台受控控制佇列，並使用用於 QueueTrigger 的相同邏輯來處理該佇列。 啟用動態並行後，將會動態管理該控制佇列的並行處理。

若要對 Blob 使用動態並行，您必須使用 5.x 版的儲存體延伸模組。

服務匯流排

服務匯流排觸發程序目前支援三個執行模型。 動態並行會影響這些執行模型，如下所示：

• 單一分派主題/佇列處理：函式的每個引動過程都會處理單一訊息。 使用靜態組態時，並行會由 MaxConcurrentCalls 組態選項控管。 使用動態並行時，該組態值會被忽略並動態調整並行。
• 工作階段型單一分派主題/佇列處理：函式的每個引動過程都會處理單一訊息。 視主題/佇列的作用中工作階段數目而定，每個執行個體都會租用一或多個工作階段。 每個工作階段中的訊息都會循序處理，以保證在工作階段中排序。 若未使用動態並行，並行是由 MaxConcurrentSessions 設定控管。 啟用動態並行後，MaxConcurrentSessions 會遭到忽略，而且會動態調整每個執行個體正在處理的工作階段數目。
• 批次處理：函式的每個引動過程都會處理由 MaxMessageCount 設定控管的一批訊息。 因為批次引動過程是連續的，所以批次觸發函式的並行一律為一個，且不適用動態並行。

若要讓服務匯流排觸發程序使用動態並行，您必須使用服務匯流排延伸模組的 5.x 版。

下一步

如需詳細資訊，請參閱以下資源：

• Azure Functions 的最佳做法
• Azure Functions 開發人員參考
• Azure Functions 觸發程序和繫結