Azure Functions 中的並行

在 Azure Functions 中，單一函式應用程式執行個體允許同時處理多個事件。 由於這些會在相同的運算執行處理上執行，因此會共用記憶體、CPU 和連線資源。 在某些託管計劃中，對特定實例的高需求會導致 Functions 主機自動建立新實例來處理增加的負載。 在這些 動態擴展 計劃中，並行和擴展行為之間需要取捨。 為了進一步控制應用程式的執行方式，Functions 提供了一種方法來管理並行執行次數。

函式提供兩種管理並行的主要方式：

• 固定個別執行個體並行：您可以設定主機層級的並行限制，這是專屬於個別觸發程序的限制。 此模型是函數的預設並行行為。
• 動態並行：針對特定觸發程式類型，函式主機可以自動判斷函式應用程式中該觸發程式的最佳並行層級。 您必須選擇加入此並行模型。

本文說明 Functions 中事件驅動觸發程式的並行行為，以及這些行為如何影響動態計劃中的調整。 它也會比較固定個別執行個體和動態並行模型。

擴展與並行

對於使用基於事件的觸發器或回應 HTTP 請求的函數，您可以在高需求期間快速達到並發執行的限制。 在此期間，您必須能夠藉由新增執行個體來調整函式應用程式，以避免在處理傳入要求時出現待處理項目。 我們調整應用程式的方式取決於您的託管方案：

調整類型	託管計劃	描述
動態 （事件驅動） 擴展	消費 彈性消費 高級	在動態縮放計劃中，伺服器會根據傳入事件的數量，動態增加或減少函式應用程式執行個體的數量。 如需詳細資訊，請參閱 Azure Functions 中的事件驅動調整。
手動調整	專用 （App Service） 方案	當您在專用方案中託管函式應用程式時，您必須在較高負載期間手動設定執行個體，或 設定自動擴展方案。

在可能發生任何調整之前，您的函式應用程式會嘗試在單一實例中處理相同類型的多個叫用，以處理負載增加。 因此，在指定執行個體上執行這些並行執行會直接影響規模決策。 例如，當動態擴展計劃中的應用程式達到並行限制時，可能需要調整以跟上傳入的需求。

您嘗試在應用程式中達到的規模與並行的平衡取決於可能發生瓶頸的位置：處理中 （CPU 密集型進程限制） 或下游服務中 （I/O 型限制）。

固定個別執行個體並行

根據預設，大多數觸發器都會透過 目標型擴展來支援固定的每個執行個體並行組態模型。 在此模型中，每個觸發程序類型都有個別執行個體的並行限制。

您可以為觸發程序類型設定特定的個別執行個體並行，藉以覆寫多數觸發程序的並行預設值。 對於許多觸發程序，您可以在 host.json 檔案中設定並行設定。 例如，Azure 服務匯流排觸發程序會在MaxConcurrentCalls中同時提供MaxConcurrentSessions和設定。 這些設定會一起運作，以控制每個函式應用程式在每個執行個體上同時處理的訊息數目上限。

在某些以目標為基礎的調整案例中，例如當您使用 Apache Kafka 或 Azure Cosmos DB 觸發程序時，並行設定位於函式宣告中，而不是在 host.json 檔案中。 其他觸發程序類型具有內建機制可跨執行個體平衡叫用過程的負載。 例如，Azure 事件中樞和 Azure Cosmos DB 都會使用分割區型配置。

對於支援並行組態的觸發器類型，並行設定會套用至所有執行中的執行個體。 如此一來，您就可以控制每個執行個體上函數的最大並行數。 例如，當您的函數是 CPU 密集型或資源密集型時，您可以選擇限制並行以保持執行個體運作狀態良好。 在此情況下，您可以依靠擴展來處理增加的負載。 同樣地，當您的函數向受到節流的下游服務發出請求時，您也應該考慮限制並行，以避免下游服務超載。

HTTP 觸發程序並行

僅適用於彈性取用方案

HTTP 觸發程序並發性是一種特殊類型的固定單個實例並發性。 在HTTP觸發器並發中，預設並發也取決於 實例大小。

Flex 使用量方案會將所有 HTTP 觸發程序函數當作一個群組來加以縮放。 如需詳細資訊，請參閱個別函式調整。

下表指出根據設定的執行個體的記憶體大小，在某一執行個體上 HTTP 觸發的預設的並行處理設定：

執行個體大小 (MB)	預設並行*
512	4
2,048	16
4,096	32

^*在 Python 應用程式中，所有執行個體大小預設都會使用 1 的 HTTP 觸發程式並行層級。

這些預設值在大多數情況下應該都適用良好，您可以從它們開始。 假設有指定數目的 HTTP 要求，增加 HTTP 並行值可減少處理 HTTP 要求所需的執行個體數目。 同樣地，減少 HTTP 並行值需要更多執行個體來處理相同的負載。

如果您需要微調 HTTP 並行，可以使用 Azure CLI 來執行此動作。 如需詳細資訊，請參閱設定 HTTP 並行限制。

上表中的預設並行值只有在您未設定自己的 HTTP 並行設定時才適用。 當您尚未明確設定 HTTP 並行設定時，預設並行會在您變更執行個體大小時增加，如資料表所示。 在您特別設定 HTTP 並行值之後，即使執行個體大小發生變更，仍會維持該值。

決定最佳固定每個實例的並行度

固定個別執行個體並行設定可讓您控制特定觸發行為，例如函式的節流。 但可能很難確定這些設定的最佳值。 一般而言，您必須透過負載測試的反覆程序來達到可接受的值。 即使您決定了一組適用於特定負載設定檔的值，從連線服務到達的事件數也可能會每天變更。 這種可變性可能會導致您的應用程式以次優值執行。 例如，函式應用程式可能會在一週的最後一天處理較高的訊息承載，這需要您調降並行。 不過，在本週的其餘時間裡，訊息承載可能會較輕，這表示您可以在本週的剩餘時間使用較高的並行層級。

理想情況下，系統應允許執行個體處理盡可能多的工作，同時保持每個執行個體運作良好且延遲較低。 動態並發就是為此目的而設計的。

動態並行

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

附註

目前僅支援動態並發，適用於 Azure Blob 儲存體、Azure 佇列儲存體和 Service Bus 觸發程式。 此外，您必須使用本文稍後的 延伸模組支援中列出的延伸模組版本。

優點

動態並行提供下列優點：

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

動態並行設定

您可以在 host.json 檔案的主機層級開啟動態並行。 開啟時，會視需要自動調整任何支援此功能的繫結延伸的並行層級。 在這些情況下，動態並行設定會覆寫任何手動設定的並行設定。

依預設，動態並行會關閉。 當您開啟動態並行時，並行會從每個函數的 1 層級開始。 並行層級會調整至主機所決定的最佳值。

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

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

當 snapshotPersistenceEnabled 為 true時，這是預設值，則學習的並行值會定期保存至儲存體。 新的執行個體可從這些值著手，而不是從頭開始且須重新學習。

並行管理員

在幕後，當動態並行開啟時，並行管理員程序會在背景執行。 此管理員會持續監視執行個體健康情況計量 (例如 CPU 和執行緒使用率)，並視需要變更節流。 開啟一或多個節流時，函式並行會向下調整，直到主機再度狀況良好為止。 當節流功能被關閉時，並發可以增加。 各種啟發學習法用於根據這些節流，以智慧方式視需要向上或向下調整並行。 隨著時間的推移，每個函式的並行都會穩定至特定層級。 因為判斷最佳並行值可能需要一些時間，所以只有在最初或一段時間閒置之後，您的解決方案可以接受次優值時，才使用動態並行。

系統會針對每個個別函式管理並行層級。 具體來說，系統在需要低並行等級的資源密集型函數和可以處理較高並發的更輕量級函數之間取得平衡。 每個函式的並行平衡有助於維護函式應用程式執行個體的整體健康情況。

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

延伸模組支援

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

分機	版本	描述
佇列儲存體	5.x 版 （儲存體延伸）	「佇列儲存」觸發器有自己的訊息輪詢迴圈。 當您使用固定的每個執行個體組態時， BatchSize 和 NewBatchThreshold 組態選項會控管並行。 當您使用動態並行時，會忽略這些組態值。 動態並行會整合到訊息迴圈中，因此每個疊代擷取的訊息數會動態調整。 節流開啟時，主機會超載。 訊息處理會暫停，直到節流控制關閉為止。 節流關閉時，並行會增加。
Blob 儲存體	5.x 版 （儲存體延伸）	在內部，Blob 儲存體觸發程式使用的架構與佇列儲存體觸發程式使用的相同。 當需要處理新的或更新的 Blob 時，訊息會寫入平台管理的控制佇列。 該佇列是使用用於佇列儲存體觸發程式的相同邏輯來處理。 開啟動態並行時，會動態管理該控制佇列處理的並行。
服務匯流排	5.x 版	服務匯流排觸發程序目前支援三個執行模型。 動態並行會以下列方式影響這些執行模型： 單一分派主題/佇列處理：函數的每次呼叫都會處理單一訊息。 當您使用固定的每個執行個體組態時，MaxConcurrentCalls 組態選項會管理並行處理。 當您使用動態並行時，會忽略該組態值，並動態調整並行。 工作階段型單一分派主題/佇列處理：函式的每個叫用過程都會處理單一訊息。 視主題或佇列的作用中工作階段數目而定，每個執行個體都會租用一或多個工作階段。 每個工作階段中的訊息都會循序處理，以保證在工作階段中排序。 當您不使用動態並行時，設定 MaxConcurrentSessions 會控管並行。 開啟動態並行時，會忽略該 MaxConcurrentSessions 值，並動態調整每個執行個體處理的工作階段數。 批次處理：函數的每次調用都會處理一批訊息，由設定控 MaxMessageCount 管。 由於批次調用是序列式的，因此批次觸發函式的並行一律為 1，且動態並行不適用。

後續步驟

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

• 可靠 Azure Functions 的最佳做法
• Azure Functions 開發人員指南
• Azure Functions 觸發程序和繫結