Azure Functions 的規模調整和主控Azure Functions scale and hosting

Azure Functions 在兩種不同的模式中執行:取用方案或 Azure App Service 方案。Azure Functions runs in two different modes: Consumption plan and Azure App Service plan. 取用方案會在程式碼執行時自動配置計算能力。The Consumption plan automatically allocates compute power when your code is running. 您的應用程式會在需要處理負載時相應放大,並在程式碼未執行時相應減少。Your app is scaled out when needed to handle load, and scaled down when code is not running. 您不必支付閒置虛擬機器的費用,或預先保留容量。You don't have to pay for idle VMs or reserve capacity in advance.


Linux 適用的取用量方案現正處於公開預覽Consumption plan for Linux is now in Public Preview.

如果您還不熟悉 Azure Functions,請參閱 Azure Functions 概觀If you aren't familiar with Azure Functions, see the Azure Functions overview.

建立函式應用程式時,您可以針對應用程式中的函式選擇主控方案。When you create a function app, you choose the hosting plan for functions in the app. 不管用哪一種方案,都是以 Azure Functions 主機的執行個體來執行函式。In either plan, an instance of the Azure Functions host executes the functions. 方案的類型控制:The type of plan controls:

  • 主控件執行個體如何向外延展。How host instances are scaled out.
  • 每個主控件可用的資源。The resources that are available to each host.


您必須在函式應用程式建立期間選擇主控方案類型。You must choose the type of hosting plan during the creation of the function app. 之後便無法更改。You can't change it afterward.

在 App Service 方案中,您可以在各層之間調整,以配置不同的資源量。On an App Service plan, you can scale between tiers to allocate different amount of resources. 在取用方案中,Azure Functions 會自動處理所有的資源配置。On the Consumption plan, Azure Functions automatically handles all resource allocation.

取用方案Consumption plan

當使用取用方案時,會根據傳入事件的數目,動態新增和移除 Azure Functions 主機。When you're using a Consumption plan, instances of the Azure Functions host are dynamically added and removed based on the number of incoming events. 此無伺服器方案會自動調整,您只需支付函式執行時使用的計算資源。This serverless plan scales automatically, and you're charged for compute resources only when your functions are running. 在取用方案中,函式執行會在一段可設定的時間之後逾時。On a Consumption plan, a function execution times out after a configurable period of time.

帳單是根據執行數目、執行時間以及使用的記憶體。Billing is based on number of executions, execution time, and memory used. 帳單會跨函式應用程式內的所有函式進行彙總。Billing is aggregated across all functions within a function app. 如需詳細資訊,請參閱 Azure Functions 價格頁面For more information, see the Azure Functions pricing page.

取用方案是預設主控方案,具有下列優點︰The Consumption plan is the default hosting plan and offers the following benefits:

  • 只有當您的函式執行時才需付費。Pay only when your functions are running.
  • 自動調整規模,即使在高負載期間也會。Scale out automatically, even during periods of high load.

App Service 方案App Service plan

在專用的 App Service 方案中,您的函式應用程式是依據基本、標準、進階和隔離 SKU 在專用的 VM 上執行,就像其他 App Service 應用程式一樣。In the dedicated App Service plan, your function apps run on dedicated VMs on Basic, Standard, Premium, and Isolated SKUs, which is the same as other App Service apps. 會配置專用的 VM 給您的函式應用程式,這表示函式主機可以不間斷地執行Dedicated VMs are allocated to your function app, which means the functions host can be always running. App Service 方案支援 Linux。App Service plans support Linux.

在下列情況中請考慮使用 App Service 方案︰Consider an App Service plan in the following cases:

  • 您有現有的、使用量過低的 VM 已在執行其他 App Service 執行個體。You have existing, underutilized VMs that are already running other App Service instances.
  • 您的函式應用程式會連續執行或接近連續執行。Your function apps run continuously, or nearly continuously. 在此情況下,App Service 方案可以更符合成本效益。In this case, an App Service Plan can be more cost-effective.
  • 您需要的 CPU 或記憶體選項比取用方案所提供的更多。You need more CPU or memory options than what is provided on the Consumption plan.
  • 您的程式碼必須執行時間超過允許的最大執行時間取用方案上。Your code needs to run longer than the maximum execution time allowed on the Consumption plan.
  • 您需要 App Service 方案才有提供的功能,例如 App Service 環境、VNET/VPN 連線和較大 VM 大小的支援。You require features that are only available on an App Service plan, such as support for App Service Environment, VNET/VPN connectivity, and larger VM sizes.
  • 您想要在 Linux 上執行函數應用程式,或想要在其上提供自訂映像以執行函數。You want to run your function app on Linux, or you want to provide a custom image on which to run your functions.

VM 可以減少執行數目、執行時間以及使用記憶體的成本。A VM decouples cost from number of executions, execution time, and memory used. 如此一來,您不會支付超過您配置的 VM 執行個體的成本。As a result, you won't pay more than the cost of the VM instance that you allocate. 如需 App Service 方案運作方式的詳細資訊,請參閱 Azure App Service 方案深入概觀For details about how the App Service plan works, see the Azure App Service plans in-depth overview.

使用 App Service 方案時,您可以透過手動新增更多 VM 執行個體來相應放大,或者您可以啟用自動規模調整。With an App Service plan, you can manually scale out by adding more VM instances, or you can enable autoscale. 如需詳細資訊,請參閱手動或自動調整執行個體計數規模For more information, see Scale instance count manually or automatically. 您也可以透過選擇不同的 App Service 方案來相應增加。You can also scale up by choosing a different App Service plan. 如需詳細資訊,請參閱在 Azure 中為應用程式進行相應增加For more information, see Scale up an app in Azure.

在 App Service 方案上執行 JavaScript 函式時,您應該選擇 vCPU 數目較少的方案。When running JavaScript functions on an App Service plan, you should choose a plan that has fewer vCPUs. 如需詳細資訊,請參閱 < 選擇單一核心 App Service 方案For more information, see Choose single-core App Service plans.

Always OnAlways On

如果您執行 App Service 方案,應該啟用 [永遠開啟] 設定,以讓您的函數應用程式能夠正確執行。If you run on an App Service plan, you should enable the Always on setting so that your function app runs correctly. 在 App Service 方案中,函式的執行階段會在無作用幾分鐘後進入閒置狀態,因此只有 HTTP 觸發程序會「喚醒」您的函式。On an App Service plan, the functions runtime goes idle after a few minutes of inactivity, so only HTTP triggers will "wake up" your functions. 只有 App Service 方案具備「永遠開啟」選項。Always on is available only on an App Service plan. 在取用方案中,平台會自動啟動函數應用程式。On a Consumption plan, the platform activates function apps automatically.

函式應用程式逾時持續期間Function app timeout duration

FunctionTimeout 屬性中所定義的函式應用程式的逾時持續時間host.json專案檔。The timeout duration of a function app is defined by the functionTimeout property in the host.json project file. 下表顯示的預設值和最大值,以分鐘為單位的這兩個方案和兩個執行階段版本:The following table shows the default and maximum values in minutes for both plans and in both runtime versions:

規劃Plan Runtime 版本Runtime Version 預設值Default 最大值Maximum
耗用量Consumption 1.x1.x 55 1010
耗用量Consumption 2.x2.x 55 1010
App Service 方案App Service 1.x1.x 無限Unlimited 無限Unlimited
App Service 方案App Service 2.x2.x 3030 無限Unlimited


函式應用程式逾時設定,無論 230 秒會是 HTTP 觸發函式可以長時間來回應要求的最大數量。Regardless of the function app timeout setting, 230 seconds is the maximum amount of time that an HTTP triggered function can take to respond to a request. 這是因為預設的 Azure Load Balancer 的閒置逾時This is because of the default idle timeout of Azure Load Balancer. 對於較長的處理時間,請考慮使用長期函式非同步模式或是延後實際工作,並傳回立即回應For longer processing times, consider using the Durable Functions async pattern or defer the actual work and return an immediate response.

我的主控方案是什麼What is my hosting plan

若要判斷您函式應用程式所用的主控方案,請在 Azure 入口網站中,參閱函式應用程式 [概觀] 中的 [App Service 方案 / 定價層]。To determine the hosting plan used by your function app, see App Service plan / pricing tier in the Overview tab for the function app in the Azure portal. 如果是 App Service 方案,則會同時指出定價層。For App Service plans, the pricing tier is also indicated.


您也可以使用 Azure CLI 來判斷方案,如下所示:You can also use the Azure CLI to determine the plan, as follows:

appServicePlanId=$(az functionapp show --name <my_function_app_name> --resource-group <my_resource_group> --query appServicePlanId --output tsv)
az appservice plan list --query "[?id=='$appServicePlanId'].sku.tier" --output tsv

如果此命令的輸出是 dynamic,表示函式應用程式在取用方案中。When the output from this command is dynamic, your function app is in the Consumption plan. 所有其他值皆代表 App Service 方案的層級。All other values indicate tiers of an App Service plan.

即使已啟用 [永遠開啟] 選項,個別函式的執行逾時還是由 host.json 專案檔的 functionTimeout 設定來控制。Even with Always On enabled, the execution timeout for individual functions is controlled by the functionTimeout setting in the host.json project file.

儲存體帳戶的需求Storage account requirements

不論是取用方案或 App Service 方案,函式應用程式都需要有支援 Azure Blob、佇列、檔案、表格儲存體的一般 Azure 儲存體帳戶。On either a Consumption plan or an App Service plan, a function app requires a general Azure Storage account, which supports Azure Blob, Queue, Files, and Table storage. 這是因為函式依賴 Azure 儲存體來執行作業,例如管理觸發程序和記錄函式執行等,但有些儲存體帳戶不支援佇列和表格。This is because Functions relies on Azure Storage for operations such as managing triggers and logging function executions, but some storage accounts do not support queues and tables. 這些帳戶 (包括僅限 Blob 的儲存體帳戶 (包含進階儲存體) 和搭配區域備援儲存體複寫的一般用途儲存體帳戶) 會在您建立函式應用程式時,從現有儲存體帳戶選項中篩選出來。These accounts, which include blob-only storage accounts (including premium storage) and general-purpose storage accounts with zone-redundant storage replication, are filtered-out from your existing Storage Account selections when you create a function app.

若要深入了解儲存體帳戶類型,請參閱 Azure 儲存體服務簡介To learn more about storage account types, see Introducing the Azure Storage services.

取用方案的運作方式How the Consumption plan works

在取用方案中,調整控制器會根據事件函式被觸發的事件數目,新增額外的 Functions 主機執行個體,藉此自動調整 CPU 和記憶體資源。In the Consumption plan, the scale controller automatically scales CPU and memory resources by adding additional instances of the Functions host, based on the number of events that its functions are triggered on. Functions 主機的每個執行個體僅限於 1.5 GB 記憶體。Each instance of the Functions host is limited to 1.5 GB of memory. 主機的執行個體是函數應用程式,表示函數應用程式內的所有函式都會共用執行個體內的資源,同時進行規模調整。An instance of the host is the function app, meaning all functions within a function app share resource within an instance and scale at the same time. 共用相同取用方案的函數應用程式會個別進行調整。Function apps that share the same Consumption plan are scaled independently.

使用取用主控方案時,函式程式碼檔案會儲存在函式之主要儲存體帳戶的 Azure 檔案共用上。When you use the Consumption hosting plan, function code files are stored on Azure Files shares on the function's main storage account. 當您刪除函式應用程式的主要儲存體帳戶時,函式程式碼檔案會被刪除,且無法復原。When you delete the main storage account of the function app, the function code files are deleted and cannot be recovered.


在取用方案中使用 Blob 觸發程序時,處理新 Blob 時最多會有 10 分鐘的延遲。When you're using a blob trigger on a Consumption plan, there can be up to a 10-minute delay in processing new blobs. 當函式應用程式已進入閒置狀態時,就會發生此延遲。This delay occurs when a function app has gone idle. 在函數應用程式開始執行之後,會立即處理 blob。After the function app is running, blobs are processed immediately. 若要避免這樣的冷啟動延遲,請使用 App Service 方案並啟用 [永遠開啟] 選項,或使用事件方格觸發程序。To avoid this cold-start delay, use an App Service plan with Always On enabled, or use the Event Grid trigger. 如需詳細資訊,請參閱 blob 觸發程序繫結參考文件For more information, see the blob trigger binding reference article.

執行階段調整Runtime scaling

Azure Functions 使用名為「縮放控制器」的元件來監視事件的速率,並判斷是否相應放大或相應縮小。Azure Functions uses a component called the scale controller to monitor the rate of events and determine whether to scale out or scale in. 縮放控制器會在每種觸發程序類型使用啟發學習法。The scale controller uses heuristics for each trigger type. 例如,當使用 Azure 佇列儲存體觸發程序時,會根據佇列長度和最舊佇列訊息的壽命調整規模。For example, when you're using an Azure Queue storage trigger, it scales based on the queue length and the age of the oldest queue message.

調整的單位是函數應用程式。The unit of scale is the function app. 當函式應用程式相應放大時,會配置額外資源來執行 Azure Functions 主機的多個執行個體。When the function app is scaled out, additional resources are allocated to run multiple instances of the Azure Functions host. 反之,當計算需求降低時,縮放控制器會移除 Functions 主機的執行個體。Conversely, as compute demand is reduced, the scale controller removes function host instances. 執行個體的數目最終會在函數應用程式中沒有任何函式執行時相應減少至零個。The number of instances is eventually scaled down to zero when no functions are running within a function app.


了解規模調整行為Understanding scaling behaviors

縮放比例會因為許多因素而有所不同,也會因為選取的觸發程序和語言不同,而進行不同的規模調整。Scaling can vary on a number of factors, and scale differently based on the trigger and language selected. 不過,現在系統中存在數個面向的縮放行為:However there are a few aspects of scaling that exist in the system today:

  • 單一函式應用程式只能相應增加至最多 200 個執行個體。A single function app only scales up to a maximum of 200 instances. 單一執行個體可能會一次處理一個以上的訊息或要求,因此沒有設定平行執行的數目上限。A single instance may process more than one message or request at a time though, so there isn't a set limit on number of concurrent executions.
  • HTTP 觸發程序,新的執行個體將只會配置最多一次每 1 秒。For HTTP triggers, new instances will only be allocated at most once every 1 second.
  • 非 HTTP 觸發程序,新的執行個體將只會配置最多一次每隔 30 秒。For non-HTTP triggers, new instances will only be allocated at most once every 30 seconds.

不同的觸發程序可能也會有不同的縮放限制,包含下方文件中所述的限制:Different triggers may also have different scaling limits as well as documented below:

可調整應用程式的最佳做法與模式Best practices and patterns for scalable apps

函數應用程式中有多個面向會影響其調整規模的效果,包括主機設定、執行階段耗用量和資源效率。There are many aspects of a function app that will impact how well it will scale, including host configuration, runtime footprint, and resource efficiency. 如需詳細資訊,請參閱效能考量文章中的延展性一節For more information, see the scalability section of the performance considerations article. 您也應了解在縮放函式應用程式後,連線會如何運作。You should also be aware of how connections behave as your function app scales. 如需詳細資訊,請參閱如何管理 Azure Functions 中的連線For more information, see How to manage connections in Azure Functions.

計費模式Billing model

Azure Functions 價格頁面會詳細說明取用方案的計費方式。Billing for the Consumption plan is described in detail on the Azure Functions pricing page. 使用量是在函式應用程式層級彙總,且只會計算函式程式碼執行的時間。Usage is aggregated at the function app level and counts only the time that function code is executed. 計費單位如下︰The following are units for billing:

  • 以十億位元組-秒 (GB-s) 為單位的資源取用量Resource consumption in gigabyte-seconds (GB-s). 會計算為在函數應用程式中執行之所有函式的記憶體大小和執行時間組合。Computed as a combination of memory size and execution time for all functions within a function app.
  • 執行Executions. 每次函式為回應事件觸發程序而執行,就算一次。Counted each time a function is executed in response to an event trigger.