Azure Functions 裝載選項
在 Azure 中建立函數應用程式時，必須為應用程式選擇主控方案。 Azure Functions 提供三個基本 Azure Functions 主控方案：使用量方案、進階版方案和專用 (App Service) 方案。 這些主控方案是由 Azure App Service 基礎結構所促成，而且在 Linux 和 Windows 虛擬機器上正式推出。
您選擇的 Azure Functions 主控方案會指定下列行為：
- 函式應用程式的縮放方式。
- 每個函式應用程式執行個體可用的資源。
- 支援進階功能，例如 Azure 虛擬網路連線。
除了 Azure Functions 裝載之外，您也可以在可部署到 Kubernetes 叢集或 Azure Container Apps 的容器中裝載容器化函式應用程式。 如果選擇在 Kubernetes 叢集中裝載函式，請考慮使用已啟用 Azure Arc 的 Kubernetes 叢集。 若要深入了解如何部署自訂容器應用程式，請參閱 Azure Functions 的 Azure Container Apps 裝載。
本文提供各種主控方案間的詳細比較，包括容器型主控選項。
注意
在已啟用 Azure Arc 的 Kubernetes 叢集和 Azure Container Apps 上裝載 Azure Functions 容器目前處於預覽狀態。
方案概觀
以下是三個主要 Azure Functions 主控方案的優點摘要：
| 計劃 | 福利 |
|---|---|
| 取用方案 | 可自動調整，並僅需支付執行函式時的計算資源。 採用使用量方案時，系統會根據傳入事件的數目，動態新增和移除 Functions 主機的執行個體。 ✔ 預設主控方案。 ✔ 只有執行函式時需要付費。 ✔ 自動調整，包括高負載期間。 |
| 進階方案 | 使用預先準備的背景工作角色，根據需求自動調整，這些背景工作角色會在閒置後無延遲地執行應用程式、在更強大的執行個體上執行，並連線到虛擬網路。 下列情況請考慮 Azure Functions 進階方案： ✔ 您的函數應用程式會不間斷執行，或幾乎是不間斷執行。 ✔ 您有大量的小型執行和高執行帳單，但使用量方案提供低 GB 秒。 ✔ 您需要更多 CPU 或記憶體選項，超出使用量方案所能提供。 ✔ 您的程式碼執行時間較長，超出使用量方案允許的上限執行時間。 ✔ 使用量方案未提供您需要的功能，例如虛擬網路連線。 ✔ 您想提供自訂 Linux 映像執行函式。 |
| 專用方案 | 以 App Service 方案費率，定期在 App Service 方案中執行函式。 最適合無法使用 Durable Functions 的長時間執行情節。 下列情況請考慮使用 App Service 方案︰ ✔ 您現有使用量過低的 VM 已在執行其他 App Service 執行個體。 ✔ 需要預測縮放和成本。 |
本文中的比較表也包含下列裝載選項，並提供執行函式應用程式最高的控制和隔離量。
| 主控選項 | 詳細資料 |
|---|---|
| ASE | App Service Environment (ASE) 是 App Service 功能，可提供完全隔離專用環境，以便安全地大規模執行 App Service 應用程式。 ASE 適合有下列需求的應用程式工作負載： ✔ 規模極大。 ✔ 完整計算隔離並保護網路存取。 ✔ 高記憶體使用量。 |
| Azure 容器應用程式 | Azure 容器應用程式是完全受控的環境，可讓您在無伺服器平台上執行微服務和容器化應用程式。 Azure Container Apps 可讓您使用基礎 Azure Kubernetes Service (AKS) 的強大功能來執行函式，同時消除使用 Kubernetes API 的複雜度。 |
| Kubernetes (直接或 Azure Arc) |
Kubernetes 提供在 Kubernetes 平台上執行的完全隔離專用環境。 Kubernetes 適合有下列需求的應用程式工作負載： ✔ 自訂硬體需求。 ✔ 隔離並保護網路存取。 ✔ 在混合式或多重雲端環境中執行的能力。 ✔ 與現有的 Kubernetes 應用程式和服務同時執行。 |
本文中其餘的資料表會比較各種功能與行為的方案。 如需動態主控方案 (使用量方案和進階方案) 之間的成本比較，請參閱 Azure Functions 定價頁面。 關於各種專用方案選項的定價，請參閱 App Service 定價頁面。
作業系統/執行階段
下表顯示主控方案的作業系統和語言支援。
| Linux1、2 僅限程式碼 |
僅限 Windows 程式碼 | Linux1、2、3 Docker 容器 |
|
|---|---|---|---|
| 取用方案 | C# JavaScript Java Python PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
不支援 |
| 進階方案 | C# JavaScript Java Python PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| 專用方案 | C# JavaScript Java Python TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| ASE | C# JavaScript Java Python TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| Kubernetes (直接) | n/a | n/a | C# JavaScript Java PowerShell Core Python TypeScript |
| Azure Arc (預覽) | C# JavaScript Java Python TypeScript |
n/a | C# JavaScript Java PowerShell Core Python TypeScript |
1 Linux 是 Python 執行階段堆疊唯一支援的作業系統。
2 Linux 上的 PowerShell 支援目前處於預覽狀態。
3 Linux 是 Docker 容器唯一支援的作業系統。
函數應用程式逾時持續時間
函數應用程式內的函式逾時持續時間是由 host. json 專案檔中的 functionTimeout 屬性所定義。 此屬性特別適用於函式執行。 觸發程序啟動函式執行之後，函式必須在逾時持續時間內傳回/回應。 如需詳細資訊，請參閱改善Azure Functions 效能語可靠性。
下表顯示特定方案的預設值和最大值 (以分鐘為單位)：
| 計劃 | 預設 | 最大值 1 |
|---|---|---|
| 取用方案 | 5 | 10 |
| 進階方案 | 302 | 無限制的3 |
| 專用方案 | 302 | 無限制的3 |
1 不論函數應用程式逾時設定為何，230 秒是 HTTP 觸發函式回應要求所能花費的最大時間量。 這是因為 Azure Load Balancer 的預設閒置逾時。 對於較長的處理時間，請考慮使用 Durable Functions 非同步模式或延遲實際工作並傳回立即回應。
2 1.x 版 Functions 執行階段的預設逾時為「無限制」。
3 保證最多 60 分鐘。 OS 和執行階段修補、弱點修補和行為調整仍然可以取消函式執行，因此請確保撰寫強固的函式。
調整
下表比較各種主控方案的調整行為。
除非另有指示，否則會根據個別函數應用程式 (取用) 或個別方案 (進階/專用) 來指定執行個體上限。
| 計劃 | 擴增 | 執行個體數目上限 |
|---|---|---|
| 取用方案 | 事件驅動。 即使在高負載期間，也會自動擴增。 根據傳入的觸發事件數目，Azure Functions 基礎結會新增額外的函示主控執行個體，然後調整 CPU 和記憶體資源。 | Windows：200 Linux：1001 |
| 進階方案 | 事件驅動。 即使在高負載期間，也會自動擴增。 根據事件函式被觸發的事件數目，Azure Functions 基礎結構會新增額外的函式主控執行個體，然後調整 CPU 和記憶體資源。 | Windows：100 Linux：20-1002 |
| 專用方案3 | 手動/自動調整 | 10-30 |
| ASE3 | 手動/自動調整 | 100 |
| Kubernetes | 使用 KEDA 的 Kubernetes 叢集事件驅動自動調整。 | 因叢集而異 |
1 在擴增期間，對於取用方案上的 Linux 應用程式，目前有每小時每個訂用帳戶 500 個執行個體的限制。
2 在某些區域中，進階方案上的 Linux 應用程式可以調整為 100 個執行個體。 如需詳細資訊，請參閱進階方案一文。
3 如需各種 App Service 方案選項的特定限制，請參閱 App Service 方案限制。
冷啟動行為
| 計畫 | 詳細資料 |
|---|---|
| 取用方案 | 閒置時應用程式可能調整為零，即啟動時部分要求可能出現額外的延遲。 使用量方案確實有經過部分最佳化處理，有助減少冷啟動時間，包括從預先準備的預留位置函式 (已有函式主控) 及執行的語言程序進行提取。 |
| 進階方案 | 避免任何冷啟動的永久暖執行個體。 |
| 專用方案 | 在專用方案中執行時，函式主控可以持續執行，亦即冷啟動其實不是問題。 |
| ASE | 在專用方案中執行時，函式主控可以持續執行，亦即冷啟動其實不是問題。 |
| Kubernetes | 視 KEDA 設定而定，您可以設定應用程式避免冷啟動。 如果設定是調整為零，新事件會遇到冷啟動。 |
服務限制
| 資源 | 取用方案 | 進階方案 | 專用方案 | ASE | Kubernetes |
|---|---|---|---|---|---|
| 預設逾時持續時間 (分鐘) | 5 | 30 | 301 | 30 | 30 |
| 最大逾時持續時間 (分鐘) | 10 | 無限制7 | 無限制2 | 無限制 | 無限制 |
| 連出連線上限 (每個執行個體) | 600 個作用中 (總計 1200) | 無限制 | 無限制 | 無限制 | 無限制 |
| 要求大小上限 (MB)3 | 100 | 100 | 100 | 100 | 取決於叢集 |
| 查詢字串長度上限3 | 4096 | 4096 | 4096 | 4096 | 取決於叢集 |
| 要求 URL 長度上限3 | 8192 | 8192 | 8192 | 8192 | 取決於叢集 |
| 每個執行個體的 ACU | 100 | 210-840 | 100-840 | 210-2508 | AKS 定價 |
| 記憶體上限 (每個執行個體的 GB) | 1.5 | 3.5-14 | 1.75-14 | 3.5 - 14 | 支援任何節點 |
| 執行個體計數上限 (Windows/Linux) | 200/100 | 100/20 | 因 SKU 而異9 | 1009 | 取決於叢集 |
| 每個方案的函式應用程式11 | 100 | 100 | 無限制4 | 無限制 | 無限制 |
| App Service 方案 | 每個區域 100 個 | 每個資源群組 100 個 | 每個資源群組 100 個 | - | - |
| 每個應用程式的部署位置10 | 2 | 3 | 1-209 | 20 | n/a |
| 儲存體5 | 5 GB | 250 GB | 50-1000 GB | 1 TB | n/a |
| 每個應用程式的自訂網域 | 5006 | 500 | 500 | 500 | n/a |
| 自訂網域 SSL 支援 | 包含無限制的 SNI SSL 連線 | 包含無限制的 SNI SSL 和 1 個 IP SSL 連線 | 包含無限制的 SNI SSL 和 1 個 IP SSL 連線 | 包含無限制的 SNI SSL 和 1 個 IP SSL 連線 | n/a |
1根據預設，App Service 方案中 Functions 1.x 執行階段的逾時不受限制。
2 需要將 App Service 方案設定為 Always On。 以標準費率付費。
3 這些限制設定於主機。
4 您可以裝載的實際函式應用程式數目，會視應用程式的活動、電腦執行個體的大小，及對應的資源使用率而定。
5 儲存體限制是在暫存儲存體中相同 App Service 方案中所有應用程式的內容總大小。 取用方案會使用 Azure 檔案儲存體作為暫存儲存體。
6 當您的函式應用程式裝載於取用方案時，僅支援 CNAME 選項。 對於進階方案或 App Service 方案中的函式應用程式，您可以使用 CNAME 或 A 記錄對應自訂網域。
7 保證最多60 分鐘。
8背景工作角色是裝載客戶應用程式的角色。 背景工作角色有三個固定大小：一個 vCPU/3.5 GB RAM、兩個 vCPU/7 GB RAM、四個 vCPU/14 GB RAM。
9如需詳細資料，請參閱 App Service 限制。
10包括生產位置。
11 在指定的訂用帳戶中，目前有 5000 個函式應用程式的限制。
在現有資源群組中建立新函數應用程式的限制
在某些情況下，嘗試在現有資源群組中建立函數應用程式的新主控方案時，您可能會收到下列其中一個錯誤：
- 此資源群組中不允許定價層
- 資源群組 <resource_group_name> 中無法使用 <SKU_name> 背景工作角色
這可能會在符合下列條件時發生：
- 您可以在已包含另一個函數應用程式或 Web 應用程式的現有資源群組中建立函數應用程式。 例如，Linux 使用量應用程式不支援與 Linux 專用或 Linux 進階方案相同的資源群組。
- 您的新函數應用程式會建立在與先前應用程式相同的區域中。
- 先前的應用程式與新的應用程式在某個方面不相容。 這可能會在 SKU 或作業系統之間或因其他平台層級功能 (例如可用性區域支援) 而發生。
發生此情況的原因是建立時函數應用程式和 Web 應用程式方案對應至不同資源集區的方式。 不同的 SKU 需要一組不同的基礎結構功能。 當您在資源群組中建立應用程式時，會將該資源群組對應並指派給特定資源集區。 如果您嘗試在該資源群組中建立另一個方案，而所對應的集區沒有必要的資源，則會發生此錯誤。
發生此錯誤時，請改為在新的資源群組中建立函數應用程式和主控方案。
網路功能
| 功能 | 取用方案 | 進階方案 | 專用方案 | ASE |
|---|---|---|---|---|
| 輸入 IP 限制 | ✅是 | ✅是 | ✅是 | ✅是 |
| 輸入私人端點 | ❌否 | ✅是 | ✅是 | ✅是 |
| 虛擬網路整合 | ❌否 | ✅是 (區域性) | ✅是 (區域性和閘道) | ✅是 |
| 虛擬網路觸發程序 (非 HTTP) | ❌否 | ✅是 | ✅是 | ✅是 |
| 混合式連線 (僅限 Windows) | ❌否 | ✅是 | ✅是 | ✅是 |
| 輸出 IP 限制 | ❌否 | ✅是 | ✅是 | ✅是 |
計費
| 計畫 | 詳細資料 |
|---|---|
| 取用方案 | 您只需按照函式執行的時間付費。 帳單是根據執行數目、執行時間以及使用的記憶體。 |
| 進階方案 | 進階方案以預熱的所需執行個體使用的核心秒數和記憶體為基礎。 每個方案至少一個執行個體必須一直暖待命。 此方案提供最可預測的定價。 |
| 專用方案 | App Service 方案中的函式應用程式，與其他 App Service 資源 (例如 Web 應用程式) 支付的費用相同。 |
| App Service Environment (ASE) | ASE 每月的固定費率涵蓋基礎結構，而且不因 ASE 的大小變更。 每個 App Service方案 vCPU 也有成本。 ASE 中裝載的所有應用程式都會位於隔離價格 SKU 中。 |
| Kubernetes | 您只需支付 Kubernetes 叢集的成本，亦即函式沒有額外的計費。 您的函式應用程式會和一般應用程式一樣，以應用程式工作負載的形式，在叢集最上層執行。 |