Azure Functions 中的事件驅動調整

在使用情況和進階方案中,Azure Functions 會藉由新增 Functions 主機的其他執行個體來調整 CPU 和記憶體資源。 執行個體數目取決於觸發函式的事件數量。

使用情況方案中的每個 Functions 主機執行個體的限制為 1.5 GB 記憶體和一個 CPU。 主機的執行個體是整個函數應用程式,表示函數應用程式內的所有函式都會共用執行個體內的資源,且同時進行規模調整。 共用相同使用情況方案的函數應用程式會個別進行調整。 在進階方案中,方案大小會決定該執行個體上該方案中所有應用程式的可用記憶體和 CPU。

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

執行階段調整

Azure Functions 使用名為「縮放控制器」的元件來監視事件的速率,並判斷是否擴增或縮減。 縮放控制器會在每種觸發程序類型使用啟發學習法。 例如,當使用 Azure 佇列儲存體觸發程序時,會根據佇列長度和最舊佇列訊息的壽命調整規模。

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

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

冷啟動

在函數應用程式閒置幾分鐘後,平台可能會調整應用程式減少至零的執行個體數量。 下一個要求有從零調整為一的增加延遲。 此延遲稱為「冷啟動」。 函式應用程式所需的相依性數目可能會影響冷啟動時間。 冷啟動更會是同步作業問題,例如必須傳回回應的 HTTP 觸發。 如果冷啟動會影響您的函式,請考慮在進階方案中執行,或在已啟用一律開啟設定的專用方案中執行。

了解規模調整行為

大小調整會因為許多因素而有所不同,也會因為選取的觸發程序和語言不同,而進行不同的規模調整。 以下為調整行為需注意的一些複雜細節:

  • 執行個體數目上限:單一函數應用程式最多只能擴增至 200 個執行個體。 單一執行個體可能會一次處理一個以上的訊息或要求,因此並未設定同時執行的數目限制。 您可以視需要指定較低的上限來節流調整。
  • 新執行個體速率:若為 HTTP 觸發程序,最多會每秒配置一次新執行個體。 若為非 HTTP 觸發程序,最多會每 30 秒配置一次新執行個體。 在進階方案中執行時,調整速度會更快。
  • 調整效率:針對服務匯流排觸發,請對資源使用管理權限,以獲得最有效率的調整。 使用接聽權限時,調整並不精確,因為佇列長度無法用來通知調整決策。 若要深入了解在服務匯流排存取原則中設定權限,請參閱共用存取授權原則。 如需事件中樞觸發程序,請參閱此調整指導

限制擴增

您可能會想要限制應用程式用於擴增的執行個體數目上限。當下游元件 (如資料庫) 的輸送量受到限制時,這是最常見的案例。 根據預設,使用情況方案函式會擴增至多達 200 個執行個體,而進階方案函式會擴增至多達 100 個執行個體。 您可以藉由修改 functionAppScaleLimit 值,為特定應用程式指定較低的上限。 functionAppScaleLimit 可以設定為 0null,表示不受限制,或介於 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

相應縮小行為

事件驅動的調整會在對函式的需求降低時自動減少容量。 其會藉由關閉函式應用程式的背景工作角色執行個體來執行此動作。 在關閉執行個體之前,系統會停止將新的事件傳送至執行個體。 此外,目前正在執行的函式會有時間來完成執行。 此行為會記錄為清空模式。 此關機期間最多可以延長到 10 分鐘 (若為取用方案應用程式) 和 60 分鐘 (若為進階方案應用程式)。 事件驅動的調整和此行為不適用於專用方案應用程式。

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

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

事件中樞觸發程序

本節說明當您的函式使用事件中樞觸發程序IoT 中樞觸發程序時,調整的運作方式。 在這些案例中,由事件所觸發的函式,其每個執行個體只會由單一 EventProcessorHost 執行個體來提供支援。 觸發程序 (由事件中樞提供) 會確保只有 1 個 EventProcessorHost 執行個體可以在指定的分割區上取得租用。

例如,請考慮以下事件中樞:

  • 10 個資料分割
  • 1000 個平均散佈於所有分割區上的事件,且每個分割區中有 100 個訊息

當您的函式首次啟用時,只會有 1 個該函式的執行個體。 讓我們將第一個函式執行個體稱為 Function_0Function_0 函式具有單一 EventProcessorHost 的執行個體,這個執行個體在全部 10 個分割區全都擁有租用。 此執行個體會從分割區 0-9 讀取事件。 從這裡開始,會發生下列其中一件事:

  • 不需要新的函式執行個體Function_0 能夠在 Functions 的規模調整邏輯開始生效之前完全處理這 1000 個事件。 在此情況下,Function_0 會完全處理這 1000 個訊息。

  • 再新增 1 個函式執行個體:如果 Functions 規模調整邏輯判斷 Function_0 所擁有的數目比能夠處理的數目還多,就會建立一個新的函數應用程式執行個體 (Function_1)。 這個新的函式也會具有相關聯的 EventProcessorHost 執行個體。 當基礎事件中樞偵測到新的主控件執行個體正在嘗試讀取訊息時,會在主控件執行個體之間進行分割區的負載平衡。 例如,分割區 0-4 可能會指派給 Function_0,分割區 5-9 則指派給 Function_1

  • 再新增 N 個函式執行個體:如果 Functions 規模調整邏輯判斷 Function_0Function_1 所擁有的訊息都比能夠處理的還多,則會建立新的 Functions_N 函數應用程式執行個體。 系統會將應用程式建立到 N 大於事件中樞分割區數目的點。 在本例中,事件中樞同樣會將分割區負載平衡,在此案例中,會跨執行個體 Function_0...Functions_9 來進行。

發生規模調整時,N 個執行個體是大於事件中樞分割區數目的數字。 使用這個模式以確保 EventProcessorHost 執行個體可用來在分割區變成可從其他執行個體使用時,取得這些分割區的鎖定。 您只需針對函式執行個體執行時所使用的資源付費。 換句話說,您不需要針對這個過度佈建付費。

當所有函式執行完成時 (不論有無錯誤),系統就會在相關聯的儲存體帳戶中新增檢查點。 當檢查點檢查成功時,就永遠不會再次擷取所有的 1000 個訊息。

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

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

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

計費模式

Azure Functions 價格頁面會詳細說明不同方案的計費方式。 使用量是在函式應用程式層級彙總,且只會計算函式程式碼執行的時間。 計費單位如下︰

  • 以十億位元組-秒 (GB-s) 為單位的資源取用量。 會計算為在函數應用程式中執行之所有函式的記憶體大小和執行時間組合。
  • 執行。 每次函式為回應事件觸發程序而執行,就算一次。

如需有關如何了解您的使用量帳單的實用查詢和資訊,請參閱帳單常見問題集

後續步驟