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:取用 方案、高階 方案專用 (App Service) 方案There are three basic hosting plans available for Azure Functions: Consumption plan, Premium plan, and Dedicated (App Service) plan. 所有主控方案都已在 Linux 和 Windows 虛擬機器上正式推出 (GA) 。All hosting plans are generally available (GA) on both Linux and Windows virtual machines.

您選擇的主控方案會指定下列行為: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.

當您的程式碼正在執行時,耗用量和高階方案都會自動新增計算能力。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 it never scales in to zero. (需要啟用 [ 永遠開啟 ]。 ) (Requires that Always on is enabled.)

如需各種主控方案之間的詳細比較 (包括以 Kubernetes 為基礎的裝載) ,請參閱「 主控方案比較」一節For a detailed comparison between the various hosting plans (including Kubernetes-based hosting), see the Hosting plans comparison section.

使用情況方案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. 使用量會在函式應用程式內的所有函式中匯總。Usage 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

當您使用高階方案時,會根據傳入事件的數目(如同取用方案)來新增和移除 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
  • 無限制的執行持續期間 (60 分鐘保證) Unlimited execution duration (60 minutes guaranteed)
  • 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

若要瞭解如何在 Premium 方案中建立函數應用程式,請參閱 Azure Functions premium 方案To learn how you can create a function app in a Premium plan, see Azure Functions Premium plan.

高階方案的計費是根據實例之間配置的核心秒數和記憶體數目,而不是每次執行的計費和所耗用的記憶體。Instead of billing per execution and memory consumed, billing for the Premium plan is based on the number of core seconds and memory allocated across instances. Premium 方案沒有執行費用。There is no execution charge with the Premium plan. 每個方案必須隨時配置至少一個實例。At least one instance must be allocated at all times per plan. 這會導致每個作用中方案的每月最低成本,無論函式為使用中或閒置。This results in a minimum monthly cost per active plan, regardless if the function is active or idle. 請記住,高階方案中的所有函數應用程式都會共用已配置的實例。Keep in mind that all function apps in a Premium plan share allocated 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.
  • 您需要的功能只適用于 Premium 方案,例如虛擬網路連線能力。You require features that are only available on a Premium plan, such as virtual network connectivity.

專用 (App Service) 方案Dedicated (App Service) plan

您的函數應用程式也可以在與其他 App Service 應用程式相同的專用 Vm 上執行, (基本、標準、Premium 和隔離的 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 資源(例如 web 應用程式),您會在 App Service 方案中針對函數應用程式支付相同的費用。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 實例來手動相應放大。Using an App Service plan, you can manually scale out by adding more VM instances. 您也可以啟用自動調整規模,不過自動調整的速度會比高階方案的彈性規模更慢。You can also enable autoscale, though autoscale will be slower than the elastic scale of the Premium plan. 如需詳細資訊,請參閱手動或自動調整執行個體計數規模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.

App Service 環境 (ASE) 中執行,可讓您完全隔離您的函式,並利用比 App Service 計畫更高的實例數目。Running in an App Service Environment (ASE) lets you fully isolate your functions and take advantage of higher number of instances than an App Service Plan.

Always OnAlways On

如果您在 App Service 方案上執行,您應該啟用 Always on 設定,讓函數應用程式正確執行。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

函數應用程式的逾時持續時間是由 host. 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
PremiumPremium 1.x1.x 3030 無限制Unlimited
PremiumPremium 2.x2.x 3030 無限制Unlimited
PremiumPremium 3.x3.x 3030 無限制Unlimited
App Service 方案App Service 1.x1.x 無限制Unlimited 無限制Unlimited
App Service 方案App Service 2.x2.x 3030 無限制Unlimited
App Service 方案App 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 in the Overview tab for the function app in the Azure portal. 若要查看定價層,請選取 App Service 方案的名稱,然後從左窗格選取 [ 屬性 ]。To see the pricing tier, select the name of the App Service Plan, and then select Properties from the left pane.

在入口網站中檢視調整方案

您也可以使用 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 Functions 依賴 Azure 儲存體來進行作業,例如管理觸發程式和記錄函式執行,但有些儲存體帳戶並不支援佇列和資料表。This is because Azure Functions relies on Azure Storage for operations such as managing triggers and logging function executions, but some storage accounts don't 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 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.

在區域資料存放區中In Region Data Residency

當所有客戶資料都必須保留在單一區域內時,與函數應用程式相關聯的儲存體帳戶必須是 在區域冗余中的一個。When necessary for all customer data to remain within a single region, the storage account associated with the function app must be one with in region redundancy. 區域內多餘的儲存體帳戶也需要與 Azure Durable Functions 搭配使用 Durable Functions。An in-region redundant storage account would also need to be used with Azure Durable Functions for Durable Functions.

當裝載于內部 Load Balancer App Service 環境 (或 ILB ASE) 時,其他平臺管理的客戶資料只會儲存在區域內。Other platform-managed customer data will only be stored within the region when hosting in an Internal Load Balancer App Service Environment (or ILB ASE). 您可以在 ASE 區域冗余中找到詳細資料。Details can be found in ASE zone redundancy.

耗用量和進階方案的運作方式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. 在高階方案中,您的方案大小將決定該實例上該方案中所有應用程式的可用記憶體和 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.

縮放控制器能監視事件及建立執行個體

冷啟動Cold Start

當您的函式應用程式閒置數分鐘後,該平臺可能會將您的應用程式執行的實例數目調整為零。After your function app has been idle for a number of minutes, the platform may scale the number of instances on which your app runs down to zero. 下一個要求的新增延遲是從零調整為一。The next request has the added latency of scaling from zero to one. 這項延遲稱為 冷啟動This latency is referred to as a cold start. 您的函數應用程式必須載入的相依性數目可能會影響冷開始時間。The number of dependencies that must be loaded by your function app can impact the cold start time. 冷啟動是同步作業的問題,例如必須傳迴響應的 HTTP 觸發程式。Cold start is more of an issue for synchronous operations, such as HTTP triggers that must return a response. 如果冷啟動影響您的函式,請考慮在高階方案中執行,或在已啟用 Always on 的專用方案中執行。If cold starts are impacting your functions, consider running in a Premium plan or in a Dedicated plan with Always on enabled.

了解規模調整行為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 out 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. 您可以 指定較低的最大值 ,以視需要調整規模。You can specify a lower maximum to throttle scale as required.
  • 針對 HTTP 觸發程式,每秒最多會配置一個新的實例。For HTTP triggers, new instances are allocated, at most, once per second.
  • 若為非 HTTP 觸發程式,則會每隔30秒配置一次新的實例。For non-HTTP triggers, new instances are allocated, at most, once every 30 seconds. 在高階 方案中執行時,縮放比例會更快。Scaling is faster when running in a Premium plan.
  • 針對服務匯流排觸發程式,請使用資源的 管理 許可權,以獲得最有效率的調整。For Service Bus triggers, use Manage rights on resources for the most efficient scaling. 使用 接聽 許可權時,縮放比例不會正確,因為佇列長度無法用來通知調整決策。With Listen rights, scaling isn't as accurate because the queue length can't be used to inform scaling decisions. 若要深入瞭解如何設定服務匯流排存取原則中的許可權,請參閱 共用存取授權原則To learn more about setting rights in Service Bus access policies, see Shared Access Authorization Policy.
  • 針對事件中樞觸發程式,請參閱參考文章中的 調整指導 方針。For Event Hub triggers, see the scaling guidance in the reference article.

限制 scale outLimit scale out

您可能會想要限制應用程式相應放大的實例數目。You may wish to restrict the number of instances an app scales out to. 這最常見的情況是,下游元件(例如資料庫)的輸送量有限。This is most common for cases where a downstream component like a database has limited throughput. 根據預設,取用方案函式將會相應放大至最多200個實例,而高階方案函式將會相應放大至多達100個實例。By default, consumption plan functions will scale out to as many as 200 instances, and premium plan functions will scale out to as many as 100 instances. 您可以藉由修改值,為特定應用程式指定較低的最大 functionAppScaleLimit 值。You can specify a lower maximum for a specific app by modifying the functionAppScaleLimit value. functionAppScaleLimit可以設定為0或 null (不受限制)或介於1和應用程式最大值之間的有效值。The functionAppScaleLimit can be set to 0 or null for unrestricted, or a valid value between 1 and the app maximum.

az resource update --resource-type Microsoft.Web/sites -g <resource_group> -n <function_app_name>/config/web --set properties.functionAppScaleLimit=<scale_limit>

可調整應用程式的最佳做法與模式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 more 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執行。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.

主機方案比較Hosting plans comparison

下列比較表顯示可協助您決定 Azure Functions 應用程式主控方案選項的所有重要層面:The following comparison table shows all important aspects to help the decision of Azure Functions App hosting plan choice:

方案摘要Plan summary

取用方案Consumption plan 當您的函式執行時,自動調整規模並只支付計算資源的費用。Scale automatically and only pay for compute resources when your functions are running. 在取用方案中,會根據傳入事件的數目,動態新增和移除函式主機的實例。On the Consumption plan, instances of the Functions host are dynamically added and removed based on the number of incoming events.
✔預設主控方案。✔ Default hosting plan.
✔只有在您的函式執行時才需付費。✔ Pay only when your functions are running.
✔自動相應放大,即使在高負載期間也是如此。✔ scale-out automatically, even during periods of high load.
進階方案Premium plan 自動根據需求進行調整時,請使用預先準備就緒的背景工作角色來執行應用程式,而不會在閒置後延遲、在更強大的實例上執行,以及連接到 Vnet。While automatically scaling based on demand, use pre-warmed workers to run applications with no delay after being idle, run on more powerful instances, and connect to VNETs. 在下列情況下,除了 App Service 方案的所有功能之外,請考慮 Azure Functions Premium 方案:Consider the Azure Functions Premium plan in the following situations, in addition to all features of the App Service plan:
✔您的函式應用程式會持續執行,或幾乎持續執行。✔ 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.
✔您需要的功能只適用于 Premium 方案,例如虛擬網路連線能力。✔ You require features that are only available on a Premium plan, such as virtual network connectivity.
專用方案1Dedicated plan1 以一般 App Service 方案費率在 App Service 方案內執行您的函式。Run your functions within an App Service plan at regular App Service plan rates. 適用于長時間執行的作業,以及需要更多預測性調整和成本的情況。Good fit for long running operations, as well as when more predictive scaling and costs are required. 在下列情況下,請考慮 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.
ASE1ASE1 App Service 環境 (ASE) 是一項 App Service 功能,可提供完全隔離和專用的環境,以安全地大規模執行 App Service 應用程式。App Service Environment (ASE) is an App Service feature that provides a fully isolated and dedicated environment for securely running App Service apps at high scale. Ase 適用于需要下列需求的應用程式工作負載:ASEs are appropriate for application workloads that require:
✔非常高的規模。✔ Very high scale.
✔完整的計算隔離和安全的網路存取。✔ Full compute isolation and secure network access.
✔高記憶體使用量。✔ High memory utilization.
KubernetesKubernetes Kubernetes 提供在 Kubernetes 平臺上執行的完全隔離且專用的環境。Kubernetes provides a fully isolated and dedicated environment running on top of the Kubernetes platform. Kubernetes 適用于需要下列各項的應用程式工作負載:Kubernetes is appropriate for application workloads that require:
✔自訂的硬體需求。✔ Custom hardware requirements.
✔隔離和安全的網路存取。✔ Isolation and secure network access.
✔能夠在混合式或多重雲端環境中執行。✔ Ability to run in hybrid or multi-cloud environment.
✔與現有的 Kubernetes 應用程式和服務一起執行。✔ Run alongside existing Kubernetes applications and services.

1 針對各種 App Service 方案選項的特定限制,請參閱 App Service 方案限制1 For specific limits for the various App Service plan options, see the App Service plan limits.

作業系統/執行時間Operating system/runtime

Linux1Linux1
僅限程式碼Code-only
Windows2Windows2
僅限程式碼Code-only
Linux1、3Linux1,3
Docker 容器Docker container
取用方案Consumption plan .NET Core.NET Core
Node.jsNode.js
JavaJava
PythonPython
.NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core
不支援No support
進階方案Premium plan .NET Core.NET Core
Node.jsNode.js
JavaJava
PythonPython
.NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core
.NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core
PythonPython
專用方案4Dedicated plan4 .NET Core.NET Core
Node.jsNode.js
JavaJava
PythonPython
.NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core
.NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core
PythonPython
ASE4ASE4 .NET Core.NET Core
Node.jsNode.js
JavaJava
PythonPython
.NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core
.NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core
PythonPython
KubernetesKubernetes n/an/a n/an/a .NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core
PythonPython

1Linux 是 Python 執行時間堆疊唯一支援的作業系統。1Linux is the only supported operating system for the Python runtime stack.
2Windows 是 PowerShell 執行時間堆疊唯一支援的作業系統。2Windows is the only supported operating system for the PowerShell runtime stack.
3Linux 是 Docker 容器唯一支援的作業系統。3Linux is the only supported operating system for Docker containers. 4 針對各種 App Service 方案選項的特定限制,請參閱 App Service 方案限制4 For specific limits for the various App Service plan options, see the App Service plan limits.

調整Scale

擴增Scale out 最大實例數目Max # instances
取用方案Consumption plan 事件驅動。Event driven. 自動調整規模,即使在高負載期間也會。Scale out automatically, even during periods of high load. Azure Functions 基礎結構會根據觸發函式的事件數目,新增函式主機的其他實例,以調整 CPU 和記憶體資源。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. 200200
進階方案Premium plan 事件驅動。Event driven. 自動調整規模,即使在高負載期間也會。Scale out automatically, even during periods of high load. Azure Functions 基礎結構會根據觸發函式的事件數目,新增函式主機的其他實例,以調整 CPU 和記憶體資源。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. 100100
專用方案1Dedicated plan1 手動/自動調整Manual/autoscale 10-2010-20
ASE1ASE1 手動/自動調整Manual/autoscale 100100
KubernetesKubernetes 使用 KEDAKubernetes 叢集的事件驅動自動調整。Event-driven autoscale for Kubernetes clusters using KEDA. 依叢集而有所不同     。  Varies by cluster.  

1 針對各種 App Service 方案選項的特定限制,請參閱 App Service 方案限制1 For specific limits for the various App Service plan options, see the App Service plan limits.

冷啟動行為Cold start behavior

取用   方案Consumption plan 如果閒置一段時間,應用程式可能會調整為零,這表示某些要求可能會在啟動時產生額外的延遲。Apps may scale to zero if idle for a period of time, meaning some requests may have additional latency at startup. 取用方案有一些優化有助於減少冷開始時間,包括從已執行函式主機和語言進程的預先準備就緒預留位置函式中提取。The consumption plan does have some optimizations to help decrease cold start time, including pulling from pre-warmed placeholder functions that already have the function host and language processes running.
進階方案Premium plan 永久暖實例,以避免任何冷啟動。Perpetually warm instances to avoid any cold start.
專用方案1Dedicated plan1 在專用方案中執行時,函式主機可以連續執行,這表示冷啟動不是真正的問題。When running in a Dedicated plan, the Functions host can run continuously, which means that cold start isn’t really an issue.
ASE1ASE1 在專用方案中執行時,函式主機可以連續執行,這表示冷啟動不是真正的問題。When running in a Dedicated plan, the Functions host can run continuously, which means that cold start isn’t really an issue.
KubernetesKubernetes 取決於 KEDA 設定。Depends on KEDA configuration. 您可以將應用程式設定為一律執行,而且永遠不會有冷啟動,或設定為將其調整為零,這會導致冷啟動新的事件。Apps can be configured to always run and never have cold start, or configured to scale to zero, which results in cold start on new events.

1 針對各種 App Service 方案選項的特定限制,請參閱 App Service 方案限制1 For specific limits for the various App Service plan options, see the App Service plan limits.

服務限制Service limits

資源Resource 取用方案Consumption plan 進階方案Premium plan 專用方案Dedicated plan ASEASE KubernetesKubernetes
預設逾時持續時間 (分鐘)Default timeout duration (min) 55 3030 301301 3030 3030
最大逾時持續時間 (分鐘)Max timeout duration (min) 1010 無限制7unbounded7 無限制2unbounded2 無限制unbounded 無限制unbounded
連出連線上限 (每個執行個體)Max outbound connections (per instance) 600 個作用中 (總計 1200)600 active (1200 total) 無限制unbounded 無限制unbounded 無限制unbounded 無限制unbounded
要求大小上限 (MB)3Max request size (MB)3 100100 100100 100100 100100 取決於叢集Depends on cluster
查詢字串長度上限3Max query string length3 40964096 40964096 40964096 40964096 取決於叢集Depends on cluster
要求 URL 長度上限3Max request URL length3 81928192 81928192 81928192 81928192 取決於叢集Depends on cluster
每個執行個體的 ACUACU per instance 100100 210-840210-840 100-840100-840 210-2508210-2508 AKS 定價AKS pricing
記憶體上限 (每個執行個體的 GB)Max memory (GB per instance) 1.51.5 3.5-143.5-14 1.75-141.75-14 3.5 - 143.5 - 14 支援任何節點Any node is supported
每個方案的函式應用程式Function apps per plan 100100 100100 無限制4unbounded4 無限制unbounded 無限制unbounded
App Service 方案App Service plans 每個區域 100 個100 per region 每個資源群組 100 個100 per resource group 每個資源群組 100 個100 per resource group - -
儲存體5Storage5 5 TB5 TB 250 GB250 GB 50-1000 GB50-1000 GB 1 TB1 TB n/an/a
每個應用程式的自訂網域Custom domains per app 50065006 500500 500500 500500 n/an/a
自訂網域 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 包含無限制的 SNI SSL 和 1 個 IP SSL 連線unbounded SNI SSL and 1 IP SSL connections included n/an/a

1根據預設,App Service 方案中 Functions 1.x 執行階段的逾時不受限制。1 By default, the timeout for the Functions 1.x runtime in an App Service plan is unbounded.
2 需要將 App Service 方案設定為 Always On2 Requires the App Service plan be set to Always On. 以標準費率付費。Pay at standard rates.
3 這些限制設定於主機3 These limits are set in the host.
4 您可以裝載的實際函式應用程式數目,會視應用程式的活動、電腦執行個體的大小,及對應的資源使用率而定。4 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.
5 儲存體限制是在暫存儲存體中相同 App Service 方案中所有應用程式的內容總大小。5 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.
6 當您的函式應用程式裝載於取用方案時,僅支援 CNAME 選項。6 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.
7 保證最多60 分鐘。7 Guaranteed for up to 60 minutes.
8背景工作角色是裝載客戶應用程式的角色。8 Workers are roles that host customer apps. 背景工作角色可以三個固定的大小提供:一個 vCPU/3.5 GB RAM;兩個 vCPU/7 GB 的 RAM;四個 vCPU/14 GB RAM。Workers are available in three fixed sizes: One vCPU/3.5 GB RAM; Two vCPU/7 GB RAM; Four vCPU/14 GB RAM.

網路功能Networking features

功能Feature 取用方案Consumption plan 進階方案Premium plan 專用方案Dedicated plan ASEASE KubernetesKubernetes
輸入 IP 限制和私人網站存取Inbound IP restrictions and private site access ✅是✅Yes ✅是✅Yes ✅是✅Yes ✅是✅Yes ✅是✅Yes
虛擬網路整合Virtual network integration ❌否❌No ✅是 (區域性)✅Yes (Regional) ✅是 (區域性和閘道)✅Yes (Regional and Gateway) ✅是✅Yes ✅是✅Yes
虛擬網路觸發程序 (非 HTTP)Virtual network triggers (non-HTTP) ❌否❌No ✅是✅Yes ✅是✅Yes ✅是✅Yes ✅是✅Yes
混合式連線 (僅限 Windows)Hybrid connections (Windows only) ❌否❌No ✅是✅Yes ✅是✅Yes ✅是✅Yes ✅是✅Yes
輸出 IP 限制Outbound IP restrictions ❌否❌No ✅是✅Yes ✅是✅Yes ✅是✅Yes ✅是✅Yes

計費Billing

取用方案Consumption plan 您只需針對函式執行的時間付費。Pay only for the time your functions run. 帳單是根據執行數目、執行時間以及使用的記憶體。Billing is based on number of executions, execution time, and memory used.
進階方案Premium plan Premium 方案是根據所需和預先準備就緒的實例所使用的核心秒數和記憶體數。Premium plan is based on the number of core seconds and memory used across needed and pre-warmed instances. 每個方案至少有一個實例必須隨時保持暖。At least one instance per plan must be kept warm at all times. 此方案提供更可預測的定價。This plan provides more predictable pricing.
專用方案1Dedicated plan1 如同針對其他 App Service 資源(例如 web 應用程式),您會在 App Service 方案中針對函數應用程式支付相同的費用。You pay the same for function apps in an App Service Plan as you would for other App Service resources, like web apps.
ASE1ASE1 ASE 的固定每月費率會支付基礎結構,且不會隨著 ASE 的大小而變更。there's a flat monthly rate for an ASE that pays for the infrastructure and doesn't change with the size of the ASE. 此外,每 App Service 計畫 vCPU 都有成本。In addition, there's a cost per App Service plan vCPU. ASE 中裝載的所有應用程式都會位於隔離價格 SKU 中。All apps hosted in an ASE are in the Isolated pricing SKU.
KubernetesKubernetes 您只需支付 Kubernetes 叢集的成本;函數沒有額外的計費。You pay only the costs of your Kubernetes cluster; no additional billing for Functions. 您的函式應用程式會以應用程式工作負載的形式在您的叢集上執行,就像一般的應用程式一樣。Your function app runs as an application workload on top of your cluster, just like a regular app.

1 針對各種 App Service 方案選項的特定限制,請參閱 App Service 方案限制1 For specific limits for the various App Service plan options, see the App Service plan limits.

後續步驟Next steps