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 Dedicated (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.
  • 支援先進的功能,例如 Azure 虛擬網路連線能力。Support for advanced features, such as Azure Virtual Network connectivity.

當您的程式碼執行時,耗用量和 Premium 方案都會自動增加計算能力。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 in when code stops running. 針對取用方案,您也不需要支付閒置 Vm 的費用,或預先保留容量。For the Consumption plan, you also don't have to pay for idle VMs or reserve capacity in advance.

Premium 方案提供額外的功能,例如高階計算實例、可無限期地保留實例,以及 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.)

主控方案支援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 nor 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 方案Premium plan 專用方案Dedicated plan
WindowsWindows 正式上市GA 正式上市GA 正式上市GA
LinuxLinux 正式上市GA 正式上市GA 正式上市GA

使用量方案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.

若要深入瞭解如何在取用方案中執行時預估成本,請參閱瞭解耗用量方案成本To learn more about how to estimate costs when running in a Consumption plan, see Understanding Consumption plan costs.

Premium 方案Premium plan

當您使用 Premium 方案時,會根據傳入事件的數目來新增和移除 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 方案支援下列功能:Premium plan supports the following features:

  • 永久暖實例以避免任何冷啟動Perpetually warm instances to avoid any cold start
  • VNet 連線VNet connectivity
  • 無限制的執行持續時間Unlimited execution duration
  • Premium 實例大小(一個核心、兩個核心和四個核心實例)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.

高階方案的計費是根據所需和預先準備就緒的實例所使用的核心秒數和記憶體,而不是每次執行計費和耗用記憶體。Instead of billing per execution and memory consumed, billing for the Premium plan is based on the number of core seconds and memory used across needed and pre-warmed instances. 在每個計畫中,至少有一個實例必須為暖。At least one instance must be warm at all times per plan. 這表示每個使用中的計畫每月最低成本,不論執行次數為何。This means that there is a minimum monthly cost per active plan, regardless of the number of executions. 請記住,Premium 方案中的所有函式應用程式會共用預先準備就緒和作用中的實例。Keep in mind that all function apps in a Premium plan share pre-warmed and active instances.

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

  • 您的函式應用程式會連續執行或接近連續執行。Your function apps run continuously, or nearly continuously.
  • 您有很多的小型執行,而且在取用方案中具有高用量計費但低 GB 的第二個帳單。You have a high number of small executions and have a high execution bill but low GB second bill in the Consumption plan.
  • 您需要的 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.
  • 您需要的功能僅適用于高階方案,例如虛擬網路連線能力。You require features that are only available on a Premium plan, such as virtual network connectivity.

在高階計畫上執行 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 應用程式相同的專用 Vm 上執行(基本、標準、高階和隔離的 Sku)。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 apps)相同。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

函數應用程式的超時期間是由主機. json專案檔中的 functionTimeout 屬性所定義。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 the different runtime versions:

方案Plan 執行階段版本Runtime Version 預設Default 最大值Maximum
消費Consumption 1.x1.x 55 1010
消費Consumption 2.x2.x 55 1010
消費Consumption 3.x3.x 55 1010
App ServiceApp Service 1.x1.x 無限制Unlimited 無限制Unlimited
App ServiceApp Service 2.x2.x 3030 無限制Unlimited
App ServiceApp Service 3.x3.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. 針對較長的處理時間,請考慮使用Durable Functions 非同步模式,或延遲實際的工作並傳回立即回應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時,您的函數應用程式會在 Premium 方案中。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 儲存體帳戶,其支援 Azure Blob、佇列、檔案和表格儲存體。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 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.

您的函式應用程式所使用的相同儲存體帳戶也可供您的觸發程式和系結用來儲存應用程式資料。The same storage account used by your function app can also be used by your triggers and bindings to store your application data. 不過,針對需要大量儲存體的作業,您應該使用個別的儲存體帳戶。However, for storage-intensive operations, you should use a separate storage account.

有可能會有多個函式應用程式共用相同的儲存體帳戶,而不會有任何問題。It's certainly possible for multiple function apps to share the same storage account without any issues. (有一個很好的例子,就是當您使用 Azure 儲存體模擬器在本機環境中開發多個應用程式時,它的作用就像一個儲存體帳戶)。(A good example of this is when you develop multiple apps in your local environment using the Azure Storage Emulator, which acts like one storage account.)

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

耗用量和 premium 方案的工作方式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. 耗用量方案中的每個函式實例都限制為 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. 在 Premium 方案中,您的方案大小會決定該實例上該方案中所有應用程式的可用記憶體和 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.

執行階段調整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 in 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.

如需有關在 Python 和 node.js 中進行調整的詳細資訊,請參閱Azure Functions python 開發人員指南-調整和並行存取和Azure Functions node.js 開發人員指南-調整和並行存取。For additional information on scaling in Python and Node.js, see Azure Functions Python developer guide - Scaling and concurrency and Azure Functions Node.js developer guide - Scaling and concurrency.

計費模式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 方案Premium plan App Service 方案1App Service plan1
相應放大Scale out 事件驅動Event driven 事件驅動Event driven 手動/自動調整Manual/autoscale
執行個體上限Max instances 200200 100100 10-2010-20
預設超時時間(分鐘)Default timeout duration (min) 55 3030 302302
最大超時持續時間(分鐘)Max timeout duration (min) 1010 6060 無界限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
每個實例的ACUACU 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 無界限5unbounded5
App Service 方案App Service plans 每個區域100100 per region 每個資源群組 100 個100 per resource group 每個資源群組 100 個100 per resource group
儲存體6Storage6 1GB1 GB 250 GB250 GB 50-1000 GB50-1000 GB
每個應用程式的自訂網域Custom domains per app 50075007 500500 500500
自訂網域 SSL 支援Custom domain SSL support 包含未系結的 SNI SSL 連線unbounded SNI SSL connection included 包含未系結的 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 計畫中的函式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.