共用方式為


Azure Functions 中的並行

本文說明 Azure Functions 中事件驅動觸發程序的並行行為。 其中也會比較靜態和動態並行模型。

重要

Flex 使用量方案目前為預覽狀態。

在 Functions 中,您可以在單一計算執行個體上同時執行指定函式的多個執行程序。 例如,假設您在函數應用程式中有三個不同的函式,而函數應用程式擴增為多個執行個體來處理增加的負載。 在此案例中,每個函式都會針對這三個執行個體中的個別叫用而執行,而指定的執行個體可以處理相同類型的多個叫用。 請記住,在單一執行個體上執行的函式會共用相同的記憶體、CPU 和連線資源。 由於每個執行個體上可執行多個函式執行,因此每個函式都必須有管理平行執行數目的方式。

當應用程式裝載於動態縮放方案 (使用量、Flex 使用量或進階方案) 時,主機會根據傳入事件數目來擴大或縮減函式應用程式執行個體數目。 若要深入了解,請參閱事件驅動調整。 當您在專用 (App Service) 方案中裝載函式時,您必須手動設定執行個體或設定自動調整配置

這些調整決策也會直接被指定執行個體上的執行並行所影響。 當動態縮放方案中的應用程式達到並行限制時,即可能需要進行縮放來跟上傳入的需求。

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

  • 靜態並行您可以設定主機層級的並行限制,這是專屬於個別觸發程序的限制。 這是 Functions 的預設並行行為。

  • 動態並行針對某些觸發程序類型,Functions 主機可以自動為應用程式中該觸發程序判斷最佳並行層級。 您必須選擇加入此並行模型

靜態並行

根據預設,大部分觸發程序都支援主機層級的靜態設定模型。 在此模型中,每個觸發程序類型都有個別執行個體的並行限制。 不過,針對大部分的觸發程序,您也可以針對該觸發程序類型要求特定的個別執行個體並行。 例如,服務匯流排觸發程序會在 host.json 檔案中提供 MaxConcurrentCallsMaxConcurrentSessions 設定。 這些設定可一起控制每個函式在每個執行個體上同時處理的訊息數目上限。 其他觸發程序類型具有內建機制可跨執行個體平衡引動過程的負載。 例如,事件中樞和 Azure Cosmos DB 都會使用分割區型配置。

針對支援並行設定的觸發程序類型,您選擇的設定會套用至所有執行中的執行個體。 這可讓您控制每個執行個體上的函式並行上限。 例如,當函式耗用大量 CPU 或資源時,您可選擇限制並行,讓執行個體保持良好狀態,並依賴縮放來處理增加的負載。 同樣地,當函式對進行節流的下游服務提出要求時,您也應該考慮限制並行,以避免下游服務負載過重。

HTTP 觸發程序並行

只適用於 Flex 使用量方案 (預覽)

Flex 使用量方案會將所有 HTTP 觸發程序函數當作一個群組來加以縮放。 如需詳細資訊,請參閱個別函式調整。 下表根據設定的執行個體記憶體大小,指出指定執行個體上 HTTP 觸發程序的預設並行設定。

執行個體大小 (MB) 預設並行*
2048 16
4096 32

*對於 Python 應用程式,所有執行個體大小的預設 HTTP 觸發程序並行為 1

這些預設值應可適用於大部分的情況,而您會從這些預設值開始。 假設有指定數目的 HTTP 要求,增加 HTTP 並行值可減少處理 HTTP 要求所需的執行個體數目。 同樣地,減少 HTTP 並行值會需要更多執行個體來處理相同的負載。

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

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

判斷最佳的靜態並行

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

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

動態並行

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

注意

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

福利

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

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

動態並行設定

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

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

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

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

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

並行管理員

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

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

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

延伸模組支援

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

副檔名 版本 描述
佇列儲存體 5.x 版 (儲存體擴充) Azure 佇列儲存體觸發程序有自己的訊息輪詢迴圈。 使用靜態設定時,並行是由 BatchSize/NewBatchThreshold 設定選項所控管。 使用動態並行時,這些組態值會被忽略。 動態並行已整合到訊息迴圈中,因此會動態調整每次反覆項目擷取的訊息數目。 啟用節流 (主機多載) 時,訊息處理將會暫停,直到節流停用為止。 停用節流後,並行將會增加。
Blob 儲存體 5.x 版 (儲存體擴充) 在內部,Azure Blob 儲存體觸發程序會使用 Azure 佇列觸發程序所使用的相同基礎結構。 需要處理全新/已更新的 Blob 時,訊息會寫入平台受控控制佇列,並使用用於 QueueTrigger 的相同邏輯來處理該佇列。 啟用動態並行後,將會動態管理該控制佇列的並行處理。
服務匯流排 5.x 版 服務匯流排觸發程序目前支援三個執行模型。 動態並行會影響這些執行模型,如下所示:

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

下一步

如需詳細資訊,請參閱以下資源: