共用方式為

Azure Functions 中的事件驅動調整

  • 發行項

在使用量、Flex 使用量和進階方案中，Azure Functions 會根據觸發函式的事件數目來新增更多執行個體，以縮放資源。

重要

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

函式應用程式的縮放方式取決於主控方案：

  • 使用量方案：使用量方案中的每個 Functions 主機執行個體都有設限，通常是 1.5 GB 的記憶體和一個 CPU。 主機的執行個體會支援整個函式應用程式。 因此，函式應用程式內共用執行個體資源的所有函式會同時縮放。 當函式應用程式共用相同的使用量方案時，其仍會獨立縮放。

  • Flex 使用量方案：此方案會使用確定性的個別函式縮放策略，每個函式會獨立縮放，但 HTTP、Blob 和 Durable Functions 觸發的函式除外，其會在自己的群組中縮放。 如需詳細資訊，請參閱個別函式縮放。 這些執行個體隨後會根據要求的並行來縮放。

  • 進階方案：進階方案的具體大小會決定該執行個體上該方案中所有應用程式的可用記憶體和 CPU。 該方案會根據方案中應用程式的縮放需求擴增其執行個體，應用程式則視需要在方案內縮放。

函式程式碼檔案會儲存在函式主要儲存體帳戶的 Azure 檔案儲存體共用上。 當您刪除函數應用程式的主要儲存體帳戶時，將會刪除函式程式碼檔案，且無法復原。

執行階段調整

Azure Functions 使用名為縮放控制器的元件來監視事件的速率，並判斷是擴增或縮減。 縮放控制器會在每種觸發程序類型使用啟發學習法。 例如，當您使用 Azure 佇列儲存體觸發程序時，其會使用以目標為基礎的調整。

Azure Functions 的縮放單位是函數應用程式。 當函數應用程式擴增時，會配置更多資源來執行 Azure Functions 主機的多個執行個體。 反之，當計算需求降低時，縮放控制器會移除 Functions 主機的執行個體。 執行個體的數目最終會在函數應用程式中沒有任何函式執行時縮減。

監視事件和建立執行個體的縮放控制器

冷啟動

如果函式應用程式閒置幾分鐘，平台可能會決定將應用程式執行所在的執行個體數目縮小至零。 下一個要求會將調整的延遲從零增加至一。 此延遲稱為「冷啟動」。 函數應用程式所需的相依性數目可能會影響冷啟動時間。 冷啟動更會是同步作業問題，例如必須傳回回應的 HTTP 觸發。 如果冷啟動會影響您的函式，請考慮使用使用量以外的方案。 其他方案會提供這些策略以減輕或消除冷啟動：

  • 進階方案：同時支援預熱的執行個體和永遠就緒的執行個體，且至少會有一個執行個體。

  • Flex 使用量方案：支援選擇性數目的永遠就緒執行個體，可針對每個執行個體的縮放來進行定義。

  • 專用方案：方案本身不會動態縮放，但您可以在啟用 [Always On] 設定的情況下持續執行您的應用程式。

了解調整行為

縮放比例會因為各種因素而有所不同，應用程式也會因為選取的觸發程序和語言不同，而進行不同的規模調整。 以下為調整行為需注意的一些複雜細節：

  • 執行個體數目上限：單一函數應用程式只能擴增至該方案允許的上限。 不過，單一執行個體可以一次處理多個訊息或要求。 您可以視需要指定較低的上限來節流調整。
  • 新執行個體速率：若為 HTTP 觸發程序，最多會每秒配置一次新執行個體。 若為非 HTTP 觸發程序，系統會以最多每 30 秒一個的速率配置新執行個體。 在進階方案中執行時，調整速度會更快。
  • 目標型縮放：目標型縮放可為客戶提供快速且直覺的縮放模型，且目前支援用於服務匯流排佇列和主題、儲存體佇列、事件中樞、Apache Kafka 和 Azure Cosmos DB 延伸模組。 請務必檢閱目標型縮放，以了解其縮放行為。
  • 個別函式縮放：在 Flex 使用量方案中執行的函式會在獨立執行個體上縮放，但有一些值得注意的例外狀況。 這些例外狀況包括 HTTP 觸發程序和 Blob 儲存體 (事件方格) 觸發程序。 這些觸發程序類型都會在相同執行個體上以群組的形式一起縮放。 同樣地，所有 Durable Functions 觸發程序也會一起共用執行個體和縮放。 如需詳細資訊，請參閱個別函式縮放。

限制擴增

您可能會決定限制應用程式可用於擴增的執行個體數目上限。這在資料庫之類的下游元件輸送量有限的情況下最常見。 如需執行各種主控方案時的縮放上限，請參閱縮放限制。

Flex 使用量方案

根據預設，在 Flex 使用量方案中執行的應用程式有整體 100 個執行個體的限制。 最低的執行個體計數上限值目前是 40，所支援的最高執行個體計數上限值是 1000。 當您使用 az functionapp create 命令在 Flex 使用量方案中建立函式應用程式時，請使用 --maximum-instance-count 參數來設定應用程式的執行個體計數上限。 此範例會建立執行個體計數上限為 200 的應用程式：

az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage <STORAGE_ACCOUNT_NAME> --runtime <LANGUAGE_RUNTIME> --runtime-version <RUNTIME_VERSION> --flexconsumption-location <REGION> --maximum-instance-count 200

此範例會使用 az functionapp scale config set 命令，將現有應用程式的執行個體計數上限變更為 150：

az functionapp scale config set --resource-group <RESOURCE_GROUP> --name <APP_NAME> --maximum-instance-count 150

使用量/進階方案

在使用量或彈性進階方案中，您可以藉由修改 functionAppScaleLimit 網站組態設定的值，為應用程式指定較低的上限。 functionAppScaleLimit 可以設定為 0 或 null，表示不受限制，或介於 1 和應用程式上限之間的有效值。

az resource update --resource-type Microsoft.Web/sites -g <RESOURCE_GROUP> -n <FUNCTION_APP-NAME>/config/web --set properties.functionAppScaleLimit=<SCALE_LIMIT>

相應縮小行為

事件驅動的調整會在對函式的需求降低時自動減少容量。 其做法是清空其目前函式執行的執行個體，然後將其移除。 此行為會記錄為清空模式。 目前執行中的函式寬限期可延長至 10 分鐘 (若為使用量方案應用程式) 和 60分鐘 (若為進階方案應用程式)。 事件驅動的調整和此行為不適用於專用方案應用程式。

下列考量適用於相應縮小行為：

  • 針對在使用量方案中的 Windows 上執行的應用程式，預設只有在 2021 年 5 月之後建立的應用程式才會啟用清空模式行為。
  • 若要使用服務匯流排觸發程序為函式啟用正常關機，請使用 4.2.0 版或更新版本的服務匯流排擴充功能。

個別函式縮放

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

Flex 使用量方案很特別，因為其會實作個別函式縮放行為。 在個別函式縮放中，除了 HTTP 觸發程序、Blob (事件方格) 觸發程序和 Durable Functions 以外，應用程式中的所有其他函式觸發程序類型都會在獨立執行個體上進行縮放。 應用程式中的 HTTP 觸發程序全部會在相同執行個體上以群組的形式一起縮放，所有 Blob (事件方格)，以及具有自有共用執行個體的所有 Durable Functions 觸發程序也一樣。

請設想裝載了具有下列函式之 Flex 使用量方案的函式應用程式：

function1 function2 function3 function4 function5 function6 function7
HTTP 觸發程序 HTTP 觸發程序 協調流程觸發程序 (Durable) 活動觸發程序 (Durable) 服務匯流排觸發程序 服務匯流排觸發程序 事件中樞觸發程序

在此範例中：

可調整應用程式的最佳做法與模式

函式應用程式中有多個面向會影響其調整的規模，包括主機設定、執行階段耗用量和資源效率。 如需詳細資訊，請參閱效能考量文章中的延展性一節。 您也應了解在縮放函式應用程式後，連線會如何運作。 如需詳細資訊，請參閱如何管理 Azure Functions 中的連線。

如需有關在 Python 和 Node.js 中調整的詳細資訊，請參閱 Azure Functions Python 開發人員指南 - 調整和並行和 Azure Functions Node.js 開發人員指南 - 調整和並行。

下一步

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