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

當您在 Azure 中建立函數應用程式時,您必須選擇主控方案,您的應用程式。When you create a function app in Azure, you must choose a hosting plan for your app. 有適用於 Azure Functions 可用的三個的主控方案:取用方案Premium 方案,以及App Service 方案There are three hosting plans available for Azure Functions: Consumption plan, Premium plan, and App Service plan.

您選擇主控方案規定下列行為:The hosting plan you choose dictates the following behaviors:

  • 如何調整您的函式應用程式。How your function app is scaled.
  • 每個函式應用程式執行個體可用的資源。The resources available to each function app instance.
  • 進階功能,例如 VNET 連線能力的支援。Support for advanced features, such as VNET connectivity.

耗用量和進階方案會自動新增的計算能力,您的程式碼執行時。Both Consumption and Premium plans automatically add compute power when your code is running. 您的應用程式是相應放大,以處理負載,需要時,且程式碼停止執行時相應減少。Your app is scaled out when needed to handle load, and scaled down when code stops running. 取用方案中,您也不必支付閒置 Vm 或預先保留容量。For the Consumption plan, you also don't have to pay for idle VMs or reserve capacity in advance.

進階方案會提供額外的功能,例如進階計算執行個體,可將無限期保留執行個體暖和 VNet 連線能力。Premium plan provides additional features, such as premium compute instances, the ability to keep instances warm indefinitely, and VNet connectivity.

App Service 方案可讓您充分利用您所管理的專用基礎結構。App Service plan allows you to take advantage of dedicated infrastructure, which you manage. 函式應用程式無法擴充以事件為基礎,也就是永遠不會降至零的標尺。Your function app doesn't scale based on events, which means is never scales down to zero. (需要Always on已啟用。)(Requires that Always on is enabled.)


您可以藉由變更計劃屬性,函式應用程式資源耗用量和進階方案之間切換。You can switch between Consumption and Premium plans by changing the plan property of the function app resource.

裝載方案支援Hosting plan support

功能支援可分為下列兩種類別:Feature support falls into the following two categories:

  • 正式推出 (GA) : 完全支援和核准用於生產環境。Generally available (GA): fully supported and approved for production use.
  • 預覽: 完全尚無法支援和核准用於生產環境。Preview: not yet fully supported and approved for production use.

在 Windows 或 Linux 上執行時下, 表會指出目前的層級的三個的主控方案的支援:The following table indicates the current level of support for the three hosting plans, when running on either Windows or Linux:

取用方案Consumption plan 進階方案Premium plan 專用的方案Dedicated plan
WindowsWindows GAGA previewpreview GAGA
LinuxLinux previewpreview N/AN/A GAGA

取用方案Consumption plan

當您使用取用方案時,Azure Functions 主控件執行個體以動態方式加入和移除的內送事件數量而定。When you're using the 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

在相同的區域中的函式應用程式指派至相同的耗用量計劃。Function apps in the same region can be assigned to the same Consumption plan. 沒有任何缺點或擁有相同的耗用量方案中執行的多個應用程式的影響。There's no downside or impact to having multiple apps running in the same Consumption plan. 將多個應用程式指派給相同的耗用量計劃有彈性、 延展性或每個應用程式的可靠性不影響。Assigning multiple apps to the same consumption plan has no impact on resilience, scalability, or reliability of each app.

進階方案 (預覽)Premium plan (preview)

當您使用 「 進階 」 方案時,Azure Functions 主控件執行個體加入和移除就像取用方案的內送事件數量而定。When you're using the Premium plan, instances of the Azure Functions host are added and removed based on the number of incoming events just like the Consumption plan. 進階方案支援下列功能:Premium plan supports the following features:

  • 永久暖的執行個體,以避免任何冷啟動Perpetually warm instances to avoid any cold start
  • VNet 連線VNet connectivity
  • 無限制的執行持續時間Unlimited execution duration
  • 進階大小的執行個體 (一個核心、 雙核心和四個核心執行個體)Premium instance sizes (one core, two core, and four core instances)
  • 更可預測的定價More predictable pricing
  • 用於多個函式應用程式的計劃的高密度應用程式配置High-density app allocation for plans with multiple function apps

如何設定這些選項的詳細資訊可在Azure Functions premium 方案的文件Information on how you can configure these options can be found in the Azure Functions premium plan document.

而不是每個執行和耗用記憶體的計費,「 進階 」 方案的計費根據 core 秒、 執行時間和所需和保留執行個體使用的記憶體數目。Instead of billing per execution and memory consumed, billing for the Premium plan is based on the number of core seconds, execution time, and memory used across needed and reserved instances. 至少一個執行個體必須是暖在所有的時間。At least one instance must be warm at all times. 這表示每個作用中的方案,不論執行次數的固定每月成本。This means that there is a fixed monthly cost per active plan, regardless of the number of executions.

Azure Functions 的進階方案,在下列情況下,請考慮:Consider the Azure Functions premium plan in the following situations:

  • 您的函式應用程式會連續執行或接近連續執行。Your function apps run continuously, or nearly continuously.
  • 您需要更多的 CPU 或記憶體選項比取用方案所提供的內容。You need more CPU or memory options than what is provided by the Consumption plan.
  • 您的程式碼必須執行時間超過允許的最大執行時間取用方案上。Your code needs to run longer than the maximum execution time allowed on the Consumption plan.
  • 您需要只適用於 Premium 方案,例如 VNET/VPN 連線能力的功能。You require features that are only available on a Premium plan, such as VNET/VPN connectivity.


高階方案預覽目前僅支援 Azure Functions 在 Windows 上。The premium plan preview currently only supports Azure Functions on Windows.

當執行進階方案的 JavaScript 函式,您應該選擇 Vcpu 數目較少的執行個體。When running JavaScript functions on a Premium plan, you should choose an instance that has fewer vCPUs. 如需詳細資訊,請參閱 < 選擇單一核心 Premium 方案For more information, see the Choose single-core Premium plans.

專用的 (App Service) 計劃Dedicated (App Service) plan

函式應用程式也可以為其他 App Service 應用程式 (基本、 標準、 進階和隔離 Sku) 相同的專用 Vm 上執行。Your function apps can also run on the same dedicated VMs as other App Service apps (Basic, Standard, Premium, and Isolated SKUs).

請考慮下列情況中的 App Service 方案:Consider an App Service plan in the following situations:

  • 您有現有的、使用量過低的 VM 已在執行其他 App Service 執行個體。You have existing, underutilized VMs that are already running other App Service instances.
  • 您想要提供自訂的映像,用來執行您的函式。You want to provide a custom image on which to run your functions.

您需支付相同函式應用程式,App Service 方案中其他的 App Service 資源,例如 web 應用程式一樣。You pay the same for function apps in an App Service Plan as you would for other App Service resources, like web apps. 如需 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. 您也可以啟用自動調整規模。You can also 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 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.

即使已啟用 [永遠開啟] 選項,個別函式的執行逾時還是由 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.

判斷現有的應用程式主控方案Determine the hosting plan of an existing application

若要判斷您函式應用程式所用的主控方案,請在 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. 此命令的輸出時ElasticPremium,函式應用程式處於 「 進階 」 方案。When the output from this command is ElasticPremium, your function app is in the Premium plan. 所有其他值則表示不同的 App Service 方案層。All other values indicate different tiers of an App Service plan.

儲存體帳戶的需求Storage account requirements

任何計劃,函式應用程式都需要支援 Azure Blob、 佇列、 檔案和資料表儲存體的一般 Azure 儲存體帳戶。On any plan, a function app requires a general Azure Storage account, which supports Azure Blob, Queue, Files, and Table storage. 這是因為函式的作業,例如管理觸發程序和記錄函數執行依賴 Azure 儲存體,但有些儲存體帳戶不支援佇列和資料表。This is because Functions rely 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 and premium plans work

在耗用量和進階方案,Azure Functions 的基礎結構會調整 CPU 和記憶體資源,藉由新增其他函式主控件執行個體,根據其函式被觸發的事件數目。In the consumption and premium plans, the Azure Functions infrastructure 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 的記憶體和 CPU。Each instance of the Functions host in the consumption plan is limited to 1.5 GB of memory and one CPU. 主控件執行個體是整個函式應用程式,這表示函式應用程式共用內的資源執行個體和向內的所有函式,在相同的時間。An instance of the host is the entire 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. 在 「 進階 」 方案,您的方案大小會判斷可用的記憶體和 CPU 的所有應用程式在該執行個體上的該計劃中。In the premium plan, your plan size will determine the available memory and CPU for all apps in that plan on that instance.

函式程式碼檔案會儲存在 Azure 檔案共用上的函式的主要儲存體帳戶。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. 若要避免此冷啟動延遲,請使用 「 進階 」 方案,或使用Event Grid 觸發程序To avoid this cold-start delay, use the Premium plan, 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.

適用於 Azure Functions 單位是縮放的函式應用程式。The unit of scale for Azure Functions 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. 有一些錯綜複雜的規模調整行為,要注意的:There are a few intricacies of scaling behaviors to be aware of:

  • 單一函式應用程式只能相應增加至最多 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 different plans 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.

有用的查詢,以及如何了解耗用量計費的詳細資訊,請參閱計費的常見問題集 >Useful queries and information on how to understand your consumption bill can be found on the billing FAQ.

服務限制Service limits

下表指出套用至函式應用程式,在各種不同的主控方案中執行時的限制:The following table indicates the limits that apply to function apps when running in the various hosting plans:

資源Resource 取用方案Consumption plan 進階方案Premium plan App Service 方案1App Service plan1
相應放大Scale out 事件驅動Event driven 事件驅動Event driven 手動/自動調整規模Manual/autoscale
預設值逾時持續時間(分鐘)Default time out duration (min) 55 3030 302302
最大逾時持續時間(分鐘)Max time out duration (min) 1010 無限制unbounded 未繫結3unbounded3
輸出連線數目上限 (每個執行個體)Max outbound connections (per instance) 600 個作用中 (1200年總計)600 active (1200 total) 無限制unbounded 無限制unbounded
最大要求大小 (MB)4Max request size (MB)4 100100 100100 100100
查詢字串的最大長度4Max query string length4 40964096 40964096 40964096
要求 URL 的最大長度4Max request URL length4 81928192 81928192 81928192
ACU每個執行個體ACU per instance 100100 210-840210-840 100-840100-840
最大記憶體 (每個執行個體的 GB)Max memory (GB per instance) 1.51.5 3.5-143.5-14 1.75-141.75-14
每個計劃的函式應用程式Function apps per plan 100100 100100 unbounded5unbounded5
App Service 方案App Service plans 每 100 個區域100 per region 每個資源群組 100 個100 per resource group 每個資源群組 100 個100 per resource group
儲存體6Storage6 1 GB1 GB 250 GB250 GB 50-1000 GB50-1000 GB
每個應用程式的自訂網域Custom domains per app 50075007 500500 500500
自訂網域 SSL 支援Custom domain SSL support 不支援,萬用字元憑證 *。 預設為可用的 azurewebsites.netNot supported, wildcard certificate for * available by default 無限制的 SNI SSL 和 1 包含的 IP SSL 連線unbounded SNI SSL and 1 IP SSL connections included 無限制的 SNI SSL 和 1 包含的 IP SSL 連線unbounded SNI SSL and 1 IP SSL connections included

1如需各種 App Service 計劃選項的特定限制,請參閱App Service 方案限制1 For specific limits for the various App Service plan options, see the App Service plan limits.
2根據預設,App Service 方案中的 Functions 1.x 執行階段的逾時是未繫結。2 By default, the timeout for the Functions 1.x runtime in an App Service plan is unbounded.
3需要 App Service 方案設為Always On3 Requires the App Service plan be set to Always On. 用多少付多少標準費率Pay at standard rates.
4這些限制主應用程式中設定4 These limits are set in the host.
5函式應用程式可裝載的實際數目取決於應用程式的活動、 機器執行個體和對應的資源使用率的大小。5 The actual number of function apps that you can host depends on the activity of the apps, the size of the machine instances, and the corresponding resource utilization. 6的儲存體限制是總內容大小暫存儲存體中跨所有應用程式相同的 App Service 方案中。6 The storage limit is the total content size in temporary storage across all apps in the same App Service plan. 取用方案會使用 Azure 檔案的暫存儲存體。Consumption plan uses Azure Files for temporary storage.
7函式應用程式中的裝載時耗用量計劃,支援只有 [CNAME] 選項。7 When your function app is hosted in a Consumption plan, only the CNAME option is supported. 函式中的應用程式進階方案App Service 方案,您可以將自訂網域使用 CNAME 或 A 記錄對應。For function apps in a Premium plan or an App Service plan, you can map a custom domain using either a CNAME or an A record.