Azure Functions 中的事件驅動調整

事件驅動擴展不適用於專用（App Service）方案。 專用計畫不會根據事件動態擴展。 關於專用方案的擴展選項，請參見 Azure App 服務 中的擴展應用程式。

在 Azure 容器應用程式 上執行函式時，事件驅動擴展不適用。 當託管於容器應用程式時，擴展性由容器應用程式環境管理。 如需詳細資訊，請參閱在 Azure 容器應用程式中設定調整規則 (機器翻譯)。

執行階段調整

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

Azure Functions 的縮放單位是函數應用程式。 當函式應用程式擴展時，會分配更多資源來執行多個 Azure Functions 主機實例。 相反地，隨著計算需求減少，縮放控制器會移除函式主機實例。 執行個體的數目最終會在函式應用程式中沒有任何函式執行時「縮減」。

Consumption 計畫中每個 Functions 主機實例都有限制，通常為 1.5 GB 記憶體與一顆 CPU。 主機的實例支援整個函數應用程式，因此應用程式中的所有函式都能共享資源並同時擴展。 當功能應用程式共享相同的消費方案時，它們仍會獨立擴展。

Premium 方案的具體大小決定了該方案中所有應用程式在該實例中可用的記憶體和 CPU。 該方案會根據方案中應用程式的調整需求擴增其執行個體，應用程式則視需要在方案內調整。

與其他動態方案不同，Flex Consumption 方案採用可預測的以函式為單位延展模型。 在此模型中，每個函式都會根據事件數量和並行設定獨立縮放；但 HTTP、Blob 和 orchestration (Durable) 觸發函式除外，因為這些函式會以各自的群組為單位進行縮放。 如需詳細資訊，請參閱個別函式調整。

平台管理新增實例的速度（規模曲線），與最大實例數分開管理。 關於比例曲線的運作方式、限速行為及高速率縮放的最佳實務，請參見 擴展率。

冷啟動

如果你的功能應用程式閒置幾分鐘，平台可能會將執行應用程式的實例數縮減到零。 下一個請求會因從零到一而增加延遲。 此延遲稱為「冷啟動」。 你的功能應用程式需要的依賴數量會影響冷啟動時間。 冷啟動對同步作業的影響更為明顯，例如必須即時返回回應的 HTTP 觸發程序。 如果冷啟動影響了你的功能，請考慮採用支持緩解策略的計畫：

如你在這張表中所見，Flex Consumption 和 Premium 方案都提供了消除應用程式中冷啟動的方法。

了解調整行為

縮放可能會因多種因素而異。 應用程式會根據觸發條件和所選語言的不同調整。 請注意這些擴展行為的細節：

• 最大實例： 單一功能應用程式會擴展到 計畫允許的最大值。 不過，單一執行個體可以一次處理多個訊息或要求。 您可以視需要指定較低的上限來節流調整。

• 新實例率： 對於 HTTP 觸發器，平台最多每秒分配一次新實例。 對於非 HTTP 觸發器，平台最多每 30 秒分配一次新實例。 在進階方案中執行時，調整速度會更快。

• 目標導向縮放： 基於目標的擴展為客戶提供快速且直覺的擴展模型。 目前，此擴展方法已支援服務匯流排佇列與主題、儲存佇列、事件中心、Apache Kafka 及 Azure Cosmos 資料庫擴充。 請務必檢閱目標型調整，以了解其調整行為。

• 個別函式調整：在彈性使用量方案中執行的函式會在獨立執行個體上調整，但有一些值得注意的例外狀況。 這些例外狀況包括 HTTP 觸發程序和 Blob 儲存體 (事件網格) 觸發程序。 這些觸發程序類型都會在相同執行個體上以群組的形式一起調整。 同樣地，所有 Durable Functions 的觸發程序也會共用執行個體，並一起調整。 如需詳細資訊，請參閱個別函式調整。

• 最大監控觸發點： 目前，比例控制器最多只能監控 100 個觸發器來做縮放決策。 當你的應用程式有超過 100 個事件觸發器時，規模決策僅基於前 100 個執行的觸發器。 如需詳細資訊，請參閱可調整應用程式的最佳做法與模式。

限制擴增

你可能會決定限制應用程式在擴展時能使用的最大實例數量。這種限制最常見於像資料庫這類下游元件吞吐量有限的情況。 如需執行各種主控方案時的調整上限，請參閱調整限制。

根據預設，在彈性使用量方案中執行的應用程式，其執行個體總數上限為 100 個。 目前，最大執行個體數的可設定下限為 1，而支援設定的上限最高為 1000。 當您使用 az functionapp create 命令在彈性使用量方案中建立函式應用程式時，請使用 --maximum-instance-count 參數來設定應用程式的執行個體數上限。

最大實例數適用於每個 功能規模群組 （function group）中的按需實例，而非應用程式的合併實例。 隨時準備的實例 不受最大實例數限制，也不計入最大實例數。

雖然你可以將 Flex Consumption 應用程式的最大實例數調整到 1000 個，但你的應用程式配額上限會在達到該數之前就已經達成。 如需詳細資訊，請檢閱區域訂用帳戶記憶體配額。

此範例會建立一個最大執行個體數為 200 的應用程式：

az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <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>

$resource = Get-AzResource -ResourceType Microsoft.Web/sites -ResourceGroupName <RESOURCE_GROUP> -Name <FUNCTION_APP-NAME>/config/web
$resource.Properties.functionAppScaleLimit = <SCALE_LIMIT>
$resource | Set-AzResource -Force

規模化率

在 彈性消費方案中，平台也會管理新增實例的 速率 （縮放曲線），與 最大實例數分開管理。 關於縮放曲線的運作方式、限速行為及高速率縮放的最佳實務，請參見 擴展速率。

規模化率

在消費型和進階型方案中，擴縮控制器會管理新增執行個體的速率。 若為 HTTP 觸發程序，系統最多每秒只會配置一個新的執行個體。 對於非 HTTP 觸發器，新實例最多每 30 秒分配一次。 在進階方案中執行時，調整速度會更快。

縮減行為

事件驅動的調整，會在對函式的需求降低時自動減少容量。 它會先排空執行個體的現有函式執行工作，待其完成後，再將這些執行個體移除，從而實現縮減。 此行為會被記錄為排空模式。 對於執行中的函式，其寬限期上限依方案而異：使用量方案最長為 10 分鐘；彈性使用量與進階方案最長可達 60 分鐘。 事件驅動的調整和此行為不適用於專用方案應用程式。

下列考量適用於縮減行為：

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

個別函式調整

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

考慮一個由彈性消費方案託管的功能應用程式，具備以下功能：

在此範例中：

• 兩個 HTTP 觸發的函式 (function1 和 function2) 會根據 HTTP 並行設定，在它們自己的執行個體上一起執行和調整。
• 兩個 Durable 函式 (function3 和 function4) 會根據所設定的並行節流，在它們自己的執行個體上一起執行和調整。
• 服務匯流排觸發的函式 function5 會根據服務匯流排佇列和主題的目標型調整規則，自行執行並獨立調整。
• 服務匯流排觸發的函式 function6 會根據服務匯流排佇列和主題的目標型調整規則，自行執行並獨立調整。
• 事件中樞觸發程序 (function7) 會根據事件中樞的目標型調整規則，在自己的執行個體中執行並獨立調整。

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

函式應用程式的許多面向會影響其擴展性，包括主機設定、執行時佔用量及資源效率。 如需詳細資訊，請參閱效能考量文章中的可擴縮性一節。 您也應注意，連線行為會隨著函式應用程式的調整而變化。 如需詳細資訊，請參閱如何管理 Azure Functions 中的連線。

如果你的應用程式有超過 100 個使用事件觸發的功能，建議將應用程式拆分成一個或多個應用程式，每個應用程式的事件導向功能少於 100 個。

欲了解更多關於 Python 與 Node.js擴展的資訊，請參閱 Azure Functions Python 開發者指南中的擴展與效能章節，以及 Azure Functions Node.js 開發者指南中的擴展與並行部分。