Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Podczas tworzenia aplikacji funkcji na platformie Azure należy wybrać opcję hostingu dla aplikacji. Platforma Azure udostępnia następujące opcje hostingu dla kodu funkcji:
| Opcja hostingu | Usługa | Dostępność | Obsługa kontenerów |
|---|---|---|---|
| Plan Konsumpcji Flex | Azure Functions | Wersja ogólnie dostępna | Brak |
| Plan Premium | Azure Functions | ogólna dostępność | Linuxa |
| Dedykowany plan | Azure Functions | ogólna dostępność | Linuxa |
| Aplikacje kontenerowe | Azure Container Apps | ogólna dostępność | Linuxa |
| Plan zużycia | Azure Functions | Windows — ogólna dostępność Linux — wycofany |
Brak |
Ważne
Po 30 września 2028 r. opcja hostowania aplikacji funkcji w systemie Linux w planie Zużycie zostanie wycofana. Aby uniknąć zakłóceń, zmigruj istniejące aplikacje planu Zużycia działające w systemie Linux do planu Flex Consumption przed tą datą. Ta zmiana nie ma wpływu na aplikacje działające w systemie Windows w planie Zużycie. Aby uzyskać więcej informacji, zobacz powiadomienie o wycofaniu planu zużycia systemu Linux.
Opcje hostingu Azure Functions są obsługiwane przez infrastrukturę usługi Azure App Service na maszynach wirtualnych z systemami Linux i Windows. Wybrana opcja hostingu określa następujące zachowania:
- Sposób skalowania aplikacji funkcyjnej.
- Zasoby dostępne dla każdego wystąpienia aplikacji funkcjonalnej.
- Obsługa zaawansowanych funkcji, takich jak łączność z usługą Azure Virtual Network.
- Obsługa kontenerów systemu Linux.
Wybrany plan ma również wpływ na koszty uruchamiania kodu funkcjonalnego. Aby uzyskać więcej informacji, zobacz Rozliczenia.
Ten artykuł zawiera szczegółowe porównanie różnych opcji hostingu. Aby dowiedzieć się więcej na temat uruchamiania kodu funkcji i zarządzania nim w kontenerach systemu Linux, zobacz Obsługa kontenerów systemu Linux w usłudze Azure Functions.
Omówienie planów
Poniżej przedstawiono podsumowanie korzyści z różnych opcji hostingu usługi Azure Functions:
| Opcja | Świadczenia |
|---|---|
| Plan Konsumpcji Flex | Korzystaj z szybkiego skalowania w poziomie, elastycznych opcji obliczeniowych, integracji sieci wirtualnej oraz bezserwerowego modelu rozliczeń płatności zgodnie z rzeczywistym użyciem. W planie Flex Consumption wystąpienia funkcji są dynamicznie skalowane (do 1000 wystąpień) na podstawie skonfigurowanej współbieżności na wystąpienie, zdarzeń przychodzących i obciążenia poszczególnych funkcji w celu uzyskania optymalnej wydajności. Rozważ plan Flex Consumption w następujących przypadkach: ✔ Potrzebujesz hosta bezserwerowego dla kodu Twojej funkcji, płacisz tylko za wykonania na żądanie. ✔ Wymagana jest łączność sieci wirtualnej w celu zapewnienia bezpiecznego dostępu do zasobów platformy Azure. ✔ Obciążenia są zmienne i mogą przechodzić od braku aktywności do wymagających szybkiego, zdarzeniowego skalowania. ✔ Chcesz dostosować zasoby obliczeniowe do rozmiarów pamięci (512 MB, 2048 MB lub 4096 MB) i zredukować zimne starty poprzez jedno lub więcej wystąpień wstępnego aprowizowania (zawsze gotowych do działania). |
| Plan Premium | Automatycznie skaluje się na podstawie zapotrzebowania, wykorzystując wstępnie przygotowanych pracowników, którzy uruchamiają aplikacje bez opóźnień po okresie bezczynności, działa na bardziej wydajnych instancjach i łączy się z sieciami wirtualnymi. Rozważ plan usługi Azure Functions w warstwie Premium w następujących sytuacjach: ✔ Aplikacje funkcjonalne działają ciągle lub niemal ciągle. ✔ Chcesz mieć większą kontrolę nad instancjami i wdrożyć wiele aplikacji funkcji w tym samym planie, korzystając ze skalowania opartego na zdarzeniach. ✔ Masz dużą liczbę małych wykonań i wysoki rachunek za wykonanie, ale niskie GB sekund w planie Zużycie. ✔ Potrzebujesz więcej opcji procesora lub pamięci niż są oferowane przez plany zużycia. ✔ Kod musi działać dłużej niż maksymalny czas wykonywania dozwolony w planie Zużycie. ✔ Wymagana jest łączność sieci wirtualnej w celu zapewnienia bezpiecznego dostępu do zasobów platformy Azure. ✔ Chcesz udostępnić niestandardowy obraz systemu Linux, w którym będą uruchamiane funkcje. |
| Dedykowany plan | Uruchamiaj swoje funkcje w ramach planu App Service według standardowych stawek planu App Service. Najlepsze rozwiązanie w przypadku długotrwałych scenariuszy, gdy nie można skorzystać z Durable Functions. Rozważ plan usługi App Service w następujących sytuacjach: ✔ Masz istniejące i niedostatecznie wykorzystywane maszyny wirtualne, które już uruchamiają inne wystąpienia usługi App Service. ✔ Musisz mieć w pełni przewidywalne fakturowanie albo ręcznie skalować wystąpienia. ✔ Chcesz uruchamiać wiele aplikacji internetowych i funkcji na tym samym planie ✔ Potrzebujesz dostępu do opcji większych rozmiarów obliczeniowych. ✔ Pełna izolacja obliczeniowa i bezpieczny dostęp sieciowy zapewniany przez środowisko App Service Environment (ASE). ✔ Bardzo wysokie użycie pamięci i wysoka skala (ASE). |
| Aplikacje kontenerowe | Tworzenie i wdrażanie konteneryzowanych aplikacji funkcji w w pełni zarządzanym środowisku hostowanym przez usługę Azure Container Apps. Użyj modelu programowania Azure Functions, aby tworzyć bazujące na zdarzeniach, bezserwerowe aplikacje funkcji chmurowe. Uruchom funkcje wraz z innymi mikrousługami, interfejsami API, witrynami internetowymi i przepływami pracy jako programy hostowane w kontenerach. Rozważ hostowanie funkcji w usłudze Container Apps w następujących sytuacjach: ✔ Chcesz mieć kontrolę nad obrazem kontenera i spakować niestandardowe biblioteki wraz z kodem funkcji, aby wspierać aplikacje biznesowe dla konkretnej linii działalności. ✔ Należy przeprowadzić migrację wykonywania kodu z aplikacji lokalnych lub starszych do natywnych mikrousług w chmurze uruchomionych w kontenerach. ✔ Jeśli chcesz uniknąć nakładu pracy i złożoności zarządzania klastrami Kubernetes i dedykowanymi obliczeniami. ✔ Funkcje wymagają wysokiej klasy mocy obliczeniowej zapewnianej przez dedykowane zasoby obliczeniowe procesora GPU. |
| Plan zużycia | Płać za zasoby obliczeniowe tylko wtedy, gdy funkcje są uruchomione (model płatności pay-as-you-go) w systemie Windows z automatycznym skalowaniem. W Planie Zużycia wystąpienia funkcji są dynamicznie dodawane i usuwane na podstawie liczby nadchodzących zdarzeń. Rozważ plan zużycia, gdy: ✔ Masz zależność od systemu Windows, np. przy użyciu środowiska uruchomieniowego w wersji 1, pełnego programu .NET Framework lub funkcji specyficznych dla systemu Windows, takich jak niektóre moduły programu PowerShell ✔ Potrzebujesz modelu rozliczeń bezserwerowego i płacisz tylko wtedy, gdy funkcje są uruchomione. |
Pozostałe tabele w tym artykule porównują opcje hostingu na podstawie różnych funkcji i zachowań.
Obsługa systemów operacyjnych
W tej tabeli przedstawiono obsługę systemu operacyjnego dla opcji hostingu.
| Hosting | Wdrożenie systemu Linux1 | Wdrożenie systemu Windows2 |
|---|---|---|
| Plan Konsumpcji Flex |
✅ Tylko kod ❌ Kontener (nieobsługiwany) |
❌ Nieobsługiwane |
| Plan Premium |
✅ Tylko kod ✅ Kontener |
✅ Tylko kod |
| Dedykowany plan |
✅ Tylko kod ✅ Kontener |
✅ Tylko kod |
| Aplikacje kontenerowe | ✅ Tylko kontener | ❌ Nieobsługiwane |
| Plan zużycia3 |
✅ Tylko kod (wycofany) ❌ Kontener (nieobsługiwany) |
✅ Tylko kod |
- Linux jest jedynym obsługiwanym systemem operacyjnym dla stosu środowiska uruchomieniowego Python.
- Wdrożenia systemu Windows opierają się wyłącznie na kodzie. Funkcje nie obsługują obecnie kontenerów systemu Windows.
- Możliwość uruchamiania aplikacji w systemie Linux w planie Zużycie ma zostać wycofana 30 września 2028 r. Aby uzyskać więcej informacji, zobacz Plan zużycia.
Czas trwania limitu czasowego aplikacji funkcji
Limit czasu funkcji w aplikacji funkcyjnej jest definiowany za pomocą właściwości functionTimeout w pliku projektu host.json. Ta właściwość ma zastosowanie specjalnie do wykonywania funkcji. Po uruchomieniu wyzwalacza funkcja musi zwrócić/odpowiedzieć przed upływem limitu czasu. Aby uniknąć przekroczenia limitu czasu, ważne jest, aby pisać niezawodne funkcje. Aby uzyskać więcej informacji, zobacz Zwiększanie wydajności i niezawodności usługi Azure Functions.
W poniższej tabeli przedstawiono wartości domyślne i maksymalne (w minutach) dla określonych planów:
| Planowanie | Wartość domyślna | Maksymalnie1 |
|---|---|---|
| Plan Konsumpcji Flex | 30 | Nieograniczony2 |
| Plan Premium | 304 | Nieograniczony2 |
| Dedykowany plan | 304 | Nieograniczony3 |
| Aplikacje kontenerowe | 30 | Nieograniczony5 |
| Plan zużycia | 5 | 10 |
- Niezależnie od ustawienia limitu czasu aplikacji funkcji 230 sekund jest maksymalnym czasem, przez który funkcja wyzwalana przez protokół HTTP może odpowiedzieć na żądanie. Jest to spowodowane domyślnym limitem czasu bezczynności usługi Azure Load Balancer. W przypadku dłuższych czasów przetwarzania rozważ użycie asynchronicznego wzorca Durable Functions lub opóźnienie realizacji rzeczywistej pracy i zwrócenie natychmiastowej odpowiedzi.
- Nie jest wymuszana maksymalna długość limitu czasu wykonywania. Jednak okres prolongaty dla wykonania funkcji wynosi 60 minut w czasie skalowania dla planów Flex Consumption i Premium, a okres prolongaty wynosi 10 minut podczas aktualizacji platformy.
- Wymaga ustawienia planu usługi App Service na zawsze włączone. Okres karencji 10 minut jest przyznawany podczas aktualizacji platformy.
- Domyślny limit czasu dla wersji 1.x środowiska uruchomieniowego hosta usługi Functions jest niezwiązany.
- Gdy minimalna liczba replik jest ustawiona na zero, domyślny limit czasu zależy od określonych wyzwalaczy używanych w aplikacji.
Wartości w tej tabeli zakładają, że proces hosta usługi Azure Functions został uruchomiony i działa poprawnie. Maksymalny limit czasu wynoszący 60 sekund można użyć na rozpoczęcie procesu roboczego specyficznego dla języka. Limit czasu uruchamiania procesu roboczego nie jest obecnie konfigurowalny.
Obsługa języków
Aby uzyskać szczegółowe informacje na temat bieżącej obsługi stosu języka natywnego w usłudze Functions, zobacz Obsługiwane języki w usłudze Azure Functions.
Skala
W poniższej tabeli porównaliśmy zachowania skalowania różnych planów hostingu.
Maksymalna liczba wystąpień jest podawana dla poszczególnych aplikacji funkcjonalnych (Zużycie) lub na podstawie planu (Premium/Dedykowana), chyba że określono inaczej.
| Planowanie | Skalowanie poziome | Maksymalna liczba wystąpień |
|---|---|---|
| Plan Konsumpcji Flex | Szybkie decyzje dotyczące skalowania opartego na zdarzeniach są obliczane na podstawie poszczególnych funkcji, nazywane skalowaniem poszczególnych funkcji, co zapewnia bardziej deterministyczny sposób skalowania funkcji w aplikacji. Z wyjątkiem protokołu HTTP, usługi Blob Storage (Event Grid) i funkcji Durable Functions, wszystkie inne typy wyzwalaczy funkcji w Twojej aplikacji działają na niezależnych instancjach. Wszystkie wyzwalacze HTTP w aplikacji są skalowane razem jako grupa w tych samych wystąpieniach, co wszystkie wyzwalacze usługi Blob Storage (Event Grid). Wszystkie wyzwalacze Durable Functions również współdzielą wystąpienia i skalują się razem. | 10001 |
| Plan Premium | Sterowane zdarzeniami. Automatyczne skalowanie w poziomie nawet w okresach dużego obciążenia. Infrastruktura usługi Azure Functions skaluje zasoby procesora CPU i pamięci przez dodanie większej liczby wystąpień hosta usługi Functions na podstawie liczby zdarzeń wyzwalanych przez jego funkcje. |
Windows: 1006 Linux: 20-1002,6 |
| Dedykowany plan | Ręczne/automatyczne skalowanie | 10-303 100 (ASE) |
| Aplikacje kontenerowe | Sterowane zdarzeniami. Automatyczne skalowanie w poziomie nawet w okresach dużego obciążenia. Infrastruktura usługi Azure Functions skaluje zasoby procesora CPU i pamięci przez dodanie większej liczby wystąpień hosta usługi Functions na podstawie liczby zdarzeń wyzwalanych przez jego funkcje. | 300-10004 |
| Plan zużycia | Sterowane zdarzeniami. Automatyczne skalowanie na podstawie źródła zdarzeń. Infrastruktura usługi Functions skaluje zasoby przez dodanie większej liczby wystąpień hosta funkcji na podstawie liczby przychodzących zdarzeń wyzwalacza. |
Windows: 200 Linux: 1005 |
- Plan Flex Consumption ma regionalną kwotę subskrypcji, która ogranicza całkowite wykorzystanie pamięci przez wszystkie instancje w danym regionie. Aby uzyskać więcej informacji, zobacz Regionalne limity przydziału pamięci subskrypcji. Plany Flex Consumption obecnie obsługują tylko system Linux.
- W niektórych regionach aplikacje systemu Linux w planie Premium mogą być skalowane do 100 wystąpień. Aby uzyskać więcej informacji, zobacz artykuł Dotyczący planu Premium.
- Aby uzyskać szczegółowe limity dla różnych opcji planu usługi App Service, zobacz Limity planu usługi App Service.
- W usłudze Container Apps wartość domyślna to 10 wystąpień, ale można ustawić maksymalną liczbę replik, która ma maksymalnie 1000 wystąpień. Ustawienie to jest honorowane, o ile istnieje wystarczający limit rdzeni. Aby uzyskać więcej informacji, zobacz Limity przydziału dla usługi Azure Container Apps. Podczas tworzenia aplikacji funkcji w portalu Azure jesteś ograniczony do 300 instancji.
- Podczas skalowania poziomego, obecnie obowiązuje limit 500 wystąpień na subskrypcję na godzinę dla aplikacji systemu Linux w planie zużycia.
- W przypadku wyzwalaczy HTTP ograniczonych do prywatnego punktu końcowego, skalowanie w poziomie jest ograniczone do maksymalnie 20 wystąpień.
Zachowanie zimnego startu
| Planowanie | Szczegóły |
|---|---|
| Plan Konsumpcji Flex | Ulepszony zimny start nawet w przypadku skalowania do zera. Obsługuje zawsze gotowe wystąpienia , aby jeszcze bardziej zmniejszyć opóźnienie podczas aprowizowania nowych wystąpień. |
| Plan Premium | Obsługuje zawsze gotowe wystąpienia, aby uniknąć zimnych startów, umożliwiając utrzymanie jednego lub więcej zawsze ciepłych wystąpień. |
| Dedykowany plan | W przypadku uruchamiania w ramach planu dedykowanego host usługi Functions może działać w sposób ciągły na określonej liczbie wystąpień, co oznacza, że zimny start nie jest naprawdę problemem. |
| Aplikacje kontenerowe |
Zależy od minimalnej liczby replik: • Jeśli ustawiono wartość zero: aplikacje mogą być skalowane do zera w przypadku bezczynności, a niektóre żądania mogą mieć większe opóźnienia podczas uruchamiania. • W przypadku ustawienia co najmniej jednego: proces hosta jest uruchamiany w sposób ciągły, co oznacza, że zimny start nie jest problemem. |
| Plan zużycia | Aplikacje mogą być skalowane do zera w przypadku bezczynności, co oznacza, że niektóre żądania mogą mieć większe opóźnienia podczas uruchamiania. Plan wykorzystania ma pewne optymalizacje, które ułatwiają skrócenie czasu zimnego startu, w tym korzystanie z wstępnie rozgrzanych funkcji zastępczych, z już uruchomionymi procesami hosta i języka. |
Limity usługi
| Zasób | Plan konsumpcji elastycznej | Plan Premium | Dedykowany plan/ASE | Aplikacje kontenerowe | Plan zużycia |
|---|---|---|---|---|---|
| Domyślny limit czasu (min) | 30 | 30 | 301 | 3016 | 5 |
| Maksymalny limit czasu (min) | nieograniczony9 | nieograniczony9 | nieograniczony2 | nieograniczony17 | 10 |
| Maksymalna liczba połączeń wychodzących (na wystąpienie) | bezgraniczny | bezgraniczny | bezgraniczny | bezgraniczny | 600 aktywnych (łącznie 1200) |
| Maksymalny rozmiar żądania (MB)3 | 210 | 210 | 210 | 210 | 210 |
| Maksymalna długośćciągu zapytania 3 | 4096 | 4096 | 4096 | 4096 | 4096 |
| Maksymalna długośćadresu URL żądania 3 | 8192 | 8192 | 8192 | 8192 | 8192 |
| ACU na wystąpienie | 210-840 | 100-840/210-250 10 | Różni się | 100 | Różni się |
| Maksymalna ilość pamięci (GB na wystąpienie) | 414 | 3.5-14 | 1.75-256/8-256 | Różni się | 1.5 |
| Maksymalna liczba wystąpień (Windows | Linux)15 | n/a | 1000 | 20-100 | 10-30 (100 ASE)11 | 300-100018 | 200 | 100 |
| Aplikacje funkcyjne na planie13 | 1 | 100 | nieograniczony4 | nieograniczony4 | 100 |
| Plany usługi App Service | nie dotyczy | 100 na grupę zasobów | 100 na grupę zasobów | nie dotyczy | 100 na region |
| Sloty wdrożeniowe na aplikację12 | nie dotyczy | 3 | 1–2011 | nieobsługiwane | 2 |
| Magazyn (tymczasowy)5 | 0,8 GB | 21–140 GB | 11–140 GB | nie dotyczy | 0,5 GB |
| Przechowywanie (trwale zapisane) | 0 GB 7 | 250 GB | 10–1000 GB11 | nie dotyczy | 1 GB6,7 |
| Domeny niestandardowe dla każdej aplikacji | 258 | 500 | 500 | nieobsługiwane | 5008 |
| Obsługa TLS/SSL dla niestandardowej domeny | nielimitowane połączenie SNI SSL i jedno połączenie SSL IP w zestawie | nielimitowane połączenie SNI SSL i jedno połączenie SSL IP w zestawie | nielimitowane połączenie SNI SSL i jedno połączenie SSL IP w zestawie | nieobsługiwane | dołączone nielimitowane połączenie SSL SNI |
Uwagi dotyczące limitów usług:
- Domyślnie limit czasu dla środowiska uruchomieniowego usługi Functions 1.x w planie usługi App Service jest nieograniczony.
- Wymaga ustawienia planu usługi App Service na zawsze włączone. Płać według standardowych stawek. Okres prolongaty 10 minut jest podawany dla funkcji wyzwalanych przez protokół HTTP podczas aktualizacji platformy, ale nie dla innych wyzwalaczy.
- Te limity są ustawiane na hoście.
- Rzeczywista liczba aplikacji funkcji, które można hostować, zależy od aktywności aplikacji, rozmiaru wystąpień maszyny i odpowiedniego wykorzystania zasobów.
- Limit magazynu to całkowity rozmiar zawartości w magazynie tymczasowym we wszystkich aplikacjach w tym samym planie usługi App Service. W przypadku planów zużycia w systemie Linux magazyn wynosi obecnie 1,5 GB.
- Plan użycia wykorzystuje udział Azure Files dla trwałego magazynu. Podczas użycia własnego udziału w usłudze Azure Files, specyficzne limity rozmiaru udziału zależą od konta magazynu, które ustawisz dla WEBSITE_CONTENTAZUREFILECONNECTIONSTRING.
- W systemie Linux musisz jawnie zainstalować własny udział usługi Azure Files.
- Jeśli aplikacja funkcji jest hostowana w planie Zużycia, obsługiwana jest tylko opcja CNAME. W przypadku aplikacji funkcjonalnych w Planie Premium lub Planie Usługi App Service można przypisać domenę niestandardową za pomocą rekordu CNAME lub A.
- Nie jest wymuszany maksymalny limit czasu wykonywania. Jednak okres prolongaty dla wykonywania funkcji wynosi 60 minut w czasie zmniejszania skali i 10 minut podczas aktualizacji platformy.
- Procesy robocze to role, które hostują aplikacje klienta. Procesy robocze są dostępne w trzech stałych rozmiarach: jeden procesor wirtualny/3,5 GB pamięci RAM; Dwa procesory wirtualne/7 GB pamięci RAM; Cztery procesory wirtualne/14 GB pamięci RAM.
- Aby uzyskać szczegółowe informacje, zobacz Limity usługi App Service.
- Uwzględnianie okna produkcyjnego.
- Obecnie w danej subskrypcji istnieje limit 5000 aplikacji funkcjonalnych.
- Rozmiary wystąpień planu Flex Consumption są obecnie zdefiniowane jako 512 MB, 2048 MB lub 4096 MB. Aby uzyskać więcej informacji, zobacz Pamięć wystąpienia.
- Aby uzyskać szczegółowe informacje, zobacz artykuł Skalowanie w artykule Porównanie hostingu.
- Gdy minimalna liczba replik jest ustawiona na zero, domyślny limit czasu zależy od określonych wyzwalaczy używanych w aplikacji.
- Gdy minimalna liczba replik jest ustawiona na co najmniej jedną.
Funkcje sieci
| Funkcja | Plan konsumpcji elastycznej | Plan zużycia | Plan Premium | Dedykowany plan/ASE | Container Apps1 |
|---|---|---|---|---|---|
| Ograniczenia przychodzącego adresu IP | ✔ | ✔ | ✔ | ✔ | ✔ |
| Prywatne punkty końcowe przychodzące | ✔ | ✔ | ✔ | ||
| Integracja sieci wirtualnej | ✔ | ✔cyfra arabska | ✔3 | ✔ | |
| Ograniczenia adresów IP dla ruchu wychodzącego | ✔ | ✔ | ✔ | ✔ |
- Aby uzyskać więcej informacji, zobacz Networking in Azure Container Apps environment (Sieć w środowisku usługi Azure Container Apps).
- Podczas pracy z wyzwalaczami sieci wirtualnej należy wziąć pod uwagę szczególną uwagę.
- Tylko dedykowany plan ASE obsługuje integrację z siecią wirtualną, która jest wymagana przez bramę.
Rozliczenia
| Planowanie | Szczegóły |
|---|---|
| Plan Konsumpcji Flex | Rozliczenia są oparte na liczbie wykonań, pamięci wystąpień, gdy aktywnie wykonują funkcje, oraz kosztem wszystkich zawsze gotowych wystąpień. Aby uzyskać więcej informacji, zobacz Rozliczenia na planie Flex Consumption. |
| Plan Premium | Plan Premium jest oparty na liczbie sekund zużycia rdzenia i pamięci używanej w wymaganych i wstępnie uruchomionych wystąpieniach. Co najmniej jedna instancja na planie musi być zawsze utrzymywana w gotowości. Ten plan zapewnia najbardziej przewidywalne ceny. |
| Dedykowany plan | Opłaty są takie same w przypadku aplikacji funkcji w planie usługi App Service, jak w przypadku innych zasobów usługi App Service, takich jak aplikacje internetowe. W przypadku środowiska ASE istnieje płaska miesięczna stawka, która obejmuje koszty infrastruktury i nie zmienia się wraz z rozmiarem środowiska ASE. Istnieje również koszt na procesor wirtualny (vCPU) dla każdego planu usługi App Service. Wszystkie aplikacje hostowane w środowisku ASE znajdują się w jednostce SKU wyceny „izolowanej” (Isolated). Aby uzyskać więcej informacji, zobacz artykuł omówienie ASE. |
| Aplikacje kontenerowe | Rozliczenia w usłudze Azure Container Apps są oparte na typie planu. Aby uzyskać więcej informacji, zobacz Rozliczenia w usłudze Azure Container Apps. |
| Plan zużycia | Płacisz tylko za czas działania funkcji. Rozliczenia zależą od liczby wykonań, czasu wykonania oraz użytej pamięci. |
Aby uzyskać bezpośrednie porównanie kosztów między dynamicznymi planami hostingu (Zużycie, Flex Consumption i Premium), zobacz stronę cennika usługi Azure Functions. Aby uzyskać informacje o cenach różnych opcji planu dedykowanego, zobacz stronę cennika usługi App Service. Aby uzyskać informacje na temat hostingu usługi Container Apps, zobacz Cennik usługi Azure Container Apps.
Ograniczenia dotyczące tworzenia nowych aplikacji funkcji w istniejącej grupie zasobów
W niektórych przypadkach podczas próby utworzenia nowego planu hostingu dla aplikacji funkcji w istniejącej grupie zasobów może zostać wyświetlony jeden z następujących błędów:
- Ta warstwa cenowa nie jest dopuszczalna w tej grupie zasobów
- <Pracownicy SKU_name nie są dostępni w grupie zasobów >resource_group_name<
Może się to zdarzyć, gdy spełnione są następujące warunki:
- Aplikację funkcji można utworzyć w istniejącej grupie zasobów, która kiedykolwiek zawierała inną aplikację funkcji lub aplikację internetową. Na przykład, aplikacje typu Consumption dla systemu Linux nie są obsługiwane w tej samej grupie zasobów co plany dedykowane dla systemu Linux lub plany premium dla systemu Linux.
- Twoja nowa aplikacja funkcjonalna została utworzona w tym samym regionie co poprzednia aplikacja.
- Poprzednia aplikacja jest w jakiś sposób niezgodna z nową aplikacją. Ten błąd może wystąpić między jednostkami SKU, systemami operacyjnymi lub innymi funkcjami na poziomie platformy, takimi jak obsługa stref dostępności.
Przyczyną takiej sytuacji jest sposób mapowania planów aplikacji funkcjonalnych i aplikacji internetowych na różne pule zasobów, kiedy są tworzone. Różne jednostki SKU wymagają innego zestawu możliwości infrastruktury. Podczas tworzenia aplikacji w grupie zasobów ta grupa zasobów jest mapowana i przypisywana do określonej puli zasobów. Jeśli spróbujesz utworzyć inny plan w tej grupie zasobów, a zamapowana pula nie ma wymaganych zasobów, ten błąd wystąpi.
Gdy wystąpi ten błąd, zamiast tego utwórz swoją aplikację funkcjonalną i plan hostingu w nowej grupie zasobów.