Spolehlivost ve službě Azure Functions

Azure Functions je výpočetní služba řízená událostmi, která spouští malé bloky kódu nebo functions bez explicitního zřizování nebo správy infrastruktury. Funkce můžou reagovat na události, jako jsou požadavky HTTP, časovače, zprávy fronty a změny v jiných službách Azure. Díky této funkci jsou funkce dobře vhodné pro zpracování dat, integraci systému a úlohy na pozadí.

Při používání Azure je spolehlivost sdílenou odpovědností. Microsoft nabízí celou řadu možností, které podporují odolnost a obnovení. Zodpovídáte za pochopení toho, jak tyto možnosti fungují ve všech službách, které používáte, a výběrem možností, které potřebujete ke splnění vašich obchodních cílů a cílů dostupnosti.

Tento článek popisuje, jak zajistit odolnost funkcí vůči různým potenciálním výpadkům a problémům, včetně přechodných chyb, selhání zón dostupnosti a selhání v celé oblasti. Zvýrazňuje také klíčové informace o smlouvě o úrovni služeb (SLA) služby Functions.

Doporučení pro nasazení do produkčního prostředí

Azure Well-Architected Framework poskytuje doporučení týkající se spolehlivosti, zabezpečení, nákladů, provozu a výkonu. Informace o tom, jak tyto oblasti vzájemně ovlivňují a přispívají ke spolehlivému řešení Functions, najdete v tématu Osvědčené postupy architektury pro službu Functions.

Přehled architektury spolehlivosti

Při nasazování funkcí je důležité se seznámit s těmito koncepty:

  • Plány hostování: Plány představují hostitelské prostředí pro vaše aplikace funkcí. Plán určuje dostupné výpočetní prostředky, cenový model a chování škálování.

  • Účty úložiště: Při vytváření aplikace funkcí musíte zadat účet úložiště hostitele. Účet úložiště spravuje aspekty interních operací aplikace funkcí, včetně úložiště kódu funkce, protokolování a správy souběžnosti (například zapůjčení objektů blob pro konkrétní typy triggerů).

    K nasazení můžete použít také účet úložiště. Tento účet úložiště může být stejný jako váš hostitelský účet úložiště nebo jiný účet úložiště.

    Důležité

    Účty úložiště jsou důležitou součástí architektury spolehlivosti služby Functions. Nakonfigurujte je tak, aby splňovaly požadavky vaší aplikace funkcí na odolnost.

  • Triggery a vazby: Triggery a vazby umožňují vaší funkci reagovat na události, přijímat data z jiných služeb a zapisovat data do jiných služeb.

  • Odolné funkce: Odolné funkce jsou funkcí služby Functions. Poskytuje stavové funkce, jako jsou dlouhotrvající orchestrace a stavové entity.

    Při použití trvalých funkcí nakonfigurujete poskytovatele úložiště , který ukládá stav. Vyhodnoťte charakteristiky spolehlivosti úložiště stavu, které zvolíte, a nakonfigurujte ho tak, aby splňovalo vaše požadavky na odolnost.

Odolnost proti přechodným chybám

Přechodné chyby jsou krátká, přerušovaná selhání ve složkách. V distribuovaném prostředí, jako je cloud, se vyskytují často a jsou normální součástí provozu. Přechodné chyby se opravují po krátké době. Je důležité, aby vaše aplikace mohly zpracovávat přechodné chyby, obvykle opakováním ovlivněných požadavků.

Všechny aplikace hostované v cloudu by měly postupovat podle Azure pokynů pro zpracování přechodných chyb, když komunikují s libovolnými rozhraními API, databázemi a dalšími komponentami hostovanými v cloudu. Další informace najdete v tématu Doporučení pro zpracování přechodných chyb.

Zvažte následující doporučení pro zpracování přechodných chyb v aplikacích funkcí:

  • Triggery a vazby: Platforma Functions zahrnuje integrované zpracování přechodných chyb pro triggery a vazby. Pokud dojde k dočasné chybě při aktivaci podporované spouště nebo při čtení či zápisu dat pomocí podporované vazby, platforma může operaci automaticky provést znovu. Toto předdefinované chování opakování zajišťuje, že dočasné problémy s připojením nebo přerušení služby nezabrání spuštění vaší funkce. Další informace najdete v tématu Zpracování chyb a opakování funkcí.

    Tato ochrana se týká pouze přechodných chyb. Platforma neopakuje trvalá selhání, jako je například chybně nakonfigurovaný řetězec připojení nebo odstraněný prostředek.

    Platforma zachází s trvalými selháními a opakovanými přechodnými selháními jako s chybami. Nakonfigurujte protokolování pro zaznamenání informací o chybách spuštění funkce. Další informace najdete v tématu Konfigurace monitorování pro službu Functions.

  • Kód vaší funkce: V kódu funkce zodpovídáte za zpracování přechodných chyb, když vaše funkce volá externí služby. Implementujte logiku opětovného pokusu, časové limity a vzory jističe dle potřeby pro volání externích služeb ve vašem funkčním kódu. Pokud je to možné, navrhněte funkce tak, aby byly idempotentní, aby opakované pokusy nevytvářely duplicitní vedlejší účinky.

  • Klienty: Klientské aplikace, které se připojují k funkcím synchronně, například prostřednictvím připojení HTTP, by měly být odolné vůči přechodným chybám.

Odolnost proti chybám zóny dostupnosti

Zóny dostupnosti jsou fyzicky oddělené skupiny datacenter v rámci oblasti Azure. Když jedna zóna selže, mohou služby přejít na jednu ze zbývajících zón.

Plány spotřeby nepodporují zóny dostupnosti. Pokud je pro vaši úlohu potřeba redundance zón, zvažte místo toho použití plánů Flex Consumption, Premium nebo Dedicated (Azure App Service).

Plány Flex Consumption podporují zónově redundantní nasazení.

Plány Premium podporují zónově redundantní nasazení.

Pokud je povolená redundance zón, platforma automaticky rozdělí instance vašeho plánu do všech zón dostupnosti ve vybrané oblasti. Pokud dojde k problémům v některé z dostupnostních zón v této oblasti, vaše funkce budou pokračovat v běhu za pomoci instancí ve zdravých zónách.

V účtu úložiště hostitele musíte povolit zónově redundantní úložiště (ZRS), které zajišťuje odolnost proti výpadkům zón.

Diagram znázorňující plán zónově redundantních funkcí, který má tři instance rozložené mezi tři zóny a účet ZRS

Plán Dedicated (App Service) podporuje zónově redundantní nasazení. Pokud je povolená redundance zón, platforma automaticky rozdělí vaše instance do všech zón dostupnosti ve vybrané oblasti. V plánu nakonfigurujete redundanci zón. Další informace o tom, jak Azure App Service zpracovává redundanci zón, najdete v tématu Spolehlivost ve službě App Service.

Pokud nepovolíte redundanci zón, je váš plán nezonální nebo regionální . Platforma může umístit instance plánů do jakékoli zóny dostupnosti v oblasti nebo ve stejné zóně. Instance plánu nejsou odolné vůči selháním zóny dostupnosti. Váš tarif může zaznamenat výpadek během výpadku v jakékoli zóně v regionu.

Požadavky

  • Podpora oblastí: Zónově redundantní plány Flex Consumption můžete nasadit do konkrétní sady oblastí. Aktuální seznam podporovaných oblastí můžete načíst pomocí Azure CLI. Další informace najdete v tématu Zobrazení oblastí, které podporují zóny dostupnosti.

  • Podpora oblastí: Zónově redundantní plány Premium můžete nasadit do následujících oblastí.

    Severní a Jižní Amerika Evropa Střední východ Africa Asie a Tichomoří
    Brazílie – jih Francie – střed Izrael – střed Jižní Afrika – sever Austrálie – východ
    Kanada – střed Německo – středozápad Katar – střed Indie – střed
    Střed USA Itálie – sever Spojené arabské emiráty – sever Čína – sever 3
    USA – východ​ Severní Evropa Východní Asie
    USA – východ 2 Norsko – východ Japonsko – východ
    Střed USA – jih Švédsko – střed Jihovýchodní Asie
    USA – západ 2​ Švýcarsko – sever
    USA – západ 3 Velká Británie – jih
    Západní Evropa

  • Operace systémů: Platforma podporuje nasazení zónově redundantních plánů Windows a Linuxu.

  • Minimální počet instancí: Redundance zón pro plány Premium vyžaduje minimálně dvě vždy připravené instance.

  • Účet úložiště hostitele: Musíte nakonfigurovat výchozí účet úložiště hostitele vaší funkční aplikace tak, aby používal ZRS. Pokud používáte účet úložiště hostitele, který není nakonfigurovaný pro ZRS, může se vaše aplikace chovat neočekávaně během výpadku zóny.
  • Účet úložiště kontejneru nasazení: Pokud pro kontejner nasazení aplikace použijete samostatný účet úložiště, aktualizujte ho také tak, aby byl zónově redundantní.

Úvahy

Neruntime chování: Zónová redundance zaručuje pouze nepřetržitou dobu provozu pro nasazené aplikace. Výpadek zóny dostupnosti může mít vliv na aspekty služby Functions, i když aplikace nadále obsluhuje provoz. Mezi tato chování patří škálování plánu, vytváření aplikací, konfigurace aplikace a publikování aplikací.

Distribuce instancí napříč zónami

Když nakonfigurujete aplikace plánu Flex Consumption jako zónově redundantní, platforma automaticky rozloží instance plánů mezi více zón ve vybrané oblasti s různými pravidly pro instance vždy připravené a na vyžádání:

  • Vždy připravené instance se distribuují nejméně mezi dvě zóny pomocí round-robin distribuce.

    Aby byla zajištěna odolnost zón, platforma automaticky udržuje alespoň dvě vždy připravené instance pro každou funkci škálování nebo skupinu bez ohledu na vždy připravenou konfiguraci aplikace. Instance, které platforma vytvoří, jsou spravované platformou, fakturované jako vždy připravené instance a nemění nastavení konfigurace vždy připravené.

  • Instance na vyžádání vznikají z objemů zdrojů událostí, vzhledem k tomu, že aplikace se škáluje nad rámec počtu vždy připravených instancí. Instance na vyžádání se distribuují napříč zónami dostupnosti na základě maximálního úsilí. Platforma upřednostňuje rychlejší horizontální škálování před rovnoměrnou distribucí napříč zónami. Platforma se snaží vyrovnat distribuci v průběhu času.

Když nakonfigurujete plány aplikace funkcí Elastic Premium jako zónově redundantní, platforma automaticky rozloží instance plánů mezi více zón ve vybrané oblasti. Šíření instance se řídí těmito pravidly, i při škálování aplikace dovnitř i ven:

  • Minimální počet instancí funkční aplikace je dvě.

  • Pokud zadáte kapacitu větší než počet zón, instance jsou rovnoměrně rozloženy pouze v případě, že je kapacita násobkem počtu zón.

  • U hodnoty kapacity větší než počet zón vynásobených počtem instancí se extra instance rozdělí mezi zbývající zóny.

Když služba Functions přiděluje instance plánu Premium redundantní zóny, používá best-effort zone balancing, který poskytuje podkladová Škálovací sady virtuálních počítačů Azure. Azure považuje plán Premium balanced, pokud má každá zóna stejný počet virtuálních počítačů jako ostatní zóny v plánu, o jeden virtuální počítač více či méně.

Náklady

Pokud povolíte redundanci zóny, nebudou vám účtovány žádné další poplatky. Ceny pro zónově redundantní plán jsou stejné jako plán s jednou zónou. Povolení redundance zóny ale ovlivňuje minimální počet instancí ve vašem plánu.

Když v aplikaci povolíte zóny dostupnosti s konfigurací instance vždy připraveného typu, která zahrnuje méně než dvě instance pro každou funkci nebo skupinu škálování, platforma automaticky vytvoří dvě instance typu vždy připraveného pro každou funkci nebo skupinu škálování. Tyto nové instance se také účtují jako neustále připravené instance.

Pokud povolíte zóny dostupnosti v plánu, který má méně než dvě instance, platforma vynutí minimální počet instancí dvou pro tento plán a za obě instance se vám budou účtovat poplatky.

Úplné podrobnosti o cenách najdete v tématu Ceny služby Functions.

Konfigurujte podporu zón dostupnosti

  • Vytvořte nový plán zónově redundantních funkcí. Redundanci zón můžete povolit při vytváření nového plánu. Další informace najdete v tématu Vytvoření zónově redundantní aplikace funkcí.

  • Povolte redundanci zón u existujícího plánu. U stávajících plánů Elastic Premium můžete zapnout nebo vypnout zóny dostupnosti. Plány Elastic Premium mají specifické chování kapacity, které se liší od plánů Dedicated (App Service) a vyžadují další kroky konfigurace. Podrobný postup najdete v tématu Povolení redundance zón u existujícího plánu.

  • Vytvořte nový plán zónově redundantních funkcí. Redundanci zón můžete povolit při vytváření nového plánu. Další informace najdete v tématu Vytvoření zónově redundantní aplikace funkcí.

  • Povolte redundanci zón u existujícího plánu. V případě plánů Premium můžete povolit redundanci zón pouze během vytváření plánu. Existující plán Premium nejde převést na zónově redundantní. Místo toho migrujte aplikaci tak, že vytvoříte souběžné nasazení v nové aplikaci plánu Premium. Další informace najdete v tématu Povolení redundance zón u existujícího plánu.

Plánování a řízení kapacit

Zónově redundantní aplikace funkcí se budou dál spouštět i v případě výpadku zón v oblasti.

Během výpadku zóny služba Functions detekuje ztracené instance a automaticky se pokusí vyhledat nebo vytvořit náhradní instance v zónách, které jsou v pořádku. Platforma tento proces provádí na základě nejlepšího úsilí a nezaručuje úspěch. Pokud vaše úloha vyžaduje určitý počet instancí, aby zachovala očekávanou úroveň služby, zvažte nadměrné zřízení počtu instancí, které jsou vždy připravené. Overprovisioning umožňuje řešení tolerovat ztrátu kapacity a nadále fungovat bez snížení výkonu. Další informace najdete v tématu Správa kapacity prostřednictvím nadměrného zřízení.

Chování, když jsou všechny zóny v pořádku

Tato část popisuje, co očekávat, když je plán zónově redundantní, účet hostitelského úložiště používá zónově redundantní úložiště a všechny zóny dostupnosti jsou funkční.

  • Operace napříč zónami: Když nakonfigurujete redundanci zóny ve službě Functions, požadavky se automaticky rozdělí mezi instance v každé zóně dostupnosti. Požadavek může přejít na libovolnou instanci v jakékoli zóně dostupnosti.

  • Replikace dat mezi zónami: Functions je bezstavová výpočetní služba, takže mezi zónami není potřeba replikovat žádná data. Platforma replikuje konfiguraci napříč zónami automaticky.

    Pokud váš hostitelský účet úložiště používá ZRS, Azure Storage synchronně replikuje data napříč několika zónami dostupnosti.

    V případě trvalých funkcí si projděte poskytovatele úložiště a zjistěte, jak replikuje data napříč zónami.

Chování při selhání zóny

Tato část popisuje, co očekávat, když je plán zónově redundantní, účet hostitelského úložiště používá ZRS a dojde k výpadku zóny dostupnosti.

  • Detekce a odpověď: Platforma Functions zodpovídá za detekci selhání v zóně dostupnosti. Nemusíte zahájit převzetí zóny při selhání.
  • Oznámení: Microsoft vás automaticky neoznámí, když je zóna mimo provoz. Pomocí Azure Resource Health ale můžete monitorovat stav jednotlivých prostředků a můžete nastavit výstrahy Resource Health, které vás upozorní na problémy. Pomocí služby Azure Service Health můžete také porozumět celkovému stavu služby, včetně jakýchkoli selhání zón, a můžete nastavit upozornění služby Service Health , která vás upozorní na problémy.

  • Aktivní požadavky: Pokud je zóna dostupnosti nedostupná, probíhající požadavky, které se připojují k instanci v vadné zóně dostupnosti, se ukončí a musí se opakovat. Podle pokynů pro zpracování přechodných chyb se ujistěte, že jsou vaše aplikace připravené.

  • Očekávaná ztráta dat: Selhání zón se neočekává, že by způsobila ztrátu dat, protože Functions je bezstavová služba.

    Pokud váš hostitelský účet úložiště používá ZRS, služba Storage zajistí, aby nedošlo ke ztrátě dat ze selhání zóny.

    V případě trvalých funkcí zkontrolujte svého poskytovatele úložiště, abyste zjistili, zda je možná ztráta dat v případě selhání zóny.

  • Očekávaný výpadek: Během výpadků zóny mohou připojení zaznamenat krátká přerušení, která obvykle trvají několik sekund během redistribuce provozu. Podle pokynů pro zpracování přechodných chyb se ujistěte, že jsou vaše aplikace připravené.

  • Přesměrování provozu: Funkce zjistí ztracené instance z této zóny a pokusí se najít nové náhradní instance. Jakmile služba Functions najde náhrady, podle potřeby distribuuje provoz mezi nové instance.

    Důležité

    Azure nezaručuje, že požadavky na další instance budou v situaci mimo zónu úspěšné. Platforma se pokusí o nahrazení ztracených instancí v rámci svých možností. Pokud potřebujete garantovanou kapacitu během selhání zóny dostupnosti, vytvořte a nakonfigurujte plány pro kompenzaci ztráty zóny tím, že kapacitu přeinvestujete.

  • Neruntime chování: Aplikace v plánu aplikace s redundancí v zónách se budou dál spouštět a obsluhovat provoz i v případě výpadku zóny dostupnosti. Chování, které neprobíhá v době běhu, však mohou být během výpadku zóny dostupnosti ovlivněna. Mezi tato chování patří škálování aplikace funkcí, vytvoření aplikace, konfigurace aplikace a publikování aplikací.

Obnovení zóny

Když se zóna dostupnosti obnoví, služba Functions automaticky obnoví instance v zóně dostupnosti, odebere dočasné instance vytvořené v jiných zónách dostupnosti a směruje provoz mezi vašimi instancemi jako obvykle.

Testování poruch zón

Platforma Functions spravuje směrování provozu, přepnutí při selhání a obnovení zón pro zdroje s zónovou redundancí. Nemusíte nic inicializovat. Azure tuto funkci plně spravuje, takže nemusíte ověřovat procesy selhání zóny dostupnosti.

Odolnost proti selháním v celé oblasti

Functions je služba pro jednu region. Pokud se oblast stane nedostupnou, váš prostředek Functions je také nedostupný.

Vlastní řešení pro více regionů pro odolnost systémů

Abyste se vyhnuli přerušení vaší služby během výpadků v celém regionu, můžete s redundancí nasadit stejné funkce do funkčních aplikací ve více regionech.

Zodpovídáte za:

  • Nasazení funkčních aplikací do několika oblastí

  • Správa distribuce provozu mezi oblastmi

  • Implementace mechanismů převzetí služeb při selhání

  • Zajištění konzistence dat napříč oblastmi (pokud je to možné)

  • Monitorování a správa nasazení mezi oblastmi

Když spustíte stejný kód funkce ve více oblastech, zvažte vzory aktivní-aktivní a aktivní-pasivní . Následující části představují tyto vzory, ale neposkytují podrobné pokyny ani kroky konfigurace.

Model aktivní-aktivní pro funkce triggeru HTTP

V modelu aktivní-aktivní, funkce v obou oblastech aktivně spouští a zpracovávají události, a to buď duplicitním způsobem, nebo v obměně. V kombinaci s Azure Front Door použijte vzor aktivní-aktivní pro vaše kritické funkce aktivované protokolem HTTP, který může směrovat a rozdělovat požadavky HTTP metodou round-robin mezi funkcemi běžícími v několika oblastech. Azure Front Door také může pravidelně kontrolovat stav každého koncového bodu. Pokud funkce v jedné oblasti přestane reagovat na kontroly stavu, Azure Front Door ji odebere z rotace a přesměruje provoz pouze do zbývajících funkcí, které jsou v pořádku.

Diagram který ukazuje příklad architektury typu aktivní-aktivní. Azure Front Door směruje mezi Functions aplikacemi v různých oblastech které mají vlastní databázi.

Model aktivní-pasivní pro funkce triggeru jiného typu než HTTP

U funkcí řízených událostmi, které nejsou aktivované protokolem HTTP (například Azure Service Bus a triggery Azure Event Hubs), použijte model aktivní-pasivní. V modelu aktivní-pasivní jsou instance funkcí spuštěny v oblasti, která přijímá události, zatímco instance v sekundární oblasti zůstanou nečinné. Tento model zajišťuje, že každá zpráva zpracovává pouze jednu funkci, která pomáhá udržovat konzistenci dat. Poskytuje také způsob, jak přepnout na sekundární region v případě katastrofy, například při výpadku regionu.

Zvažte převzetí služeb při selhání aplikace funkcí společně s chováním převzetí služeb při selhání jiných služeb, které používáte, například:

Představte si příklad topologie, která používá trigger služby Event Hubs, kde je obor názvů služby Event Hubs nakonfigurovaný pro geografické zotavení po havárii. V tomto případě model aktivní-pasivní vyžaduje následující komponenty:

  • Obory názvů služby Event Hubs nasazené v primární i sekundární oblasti.

  • Geografické zotavení po havárii umožňuje spárovat primární a sekundární centra událostí. Tato konfigurace také vytvoří alias , pomocí kterého se můžete připojit k oboru názvů služby Event Hubs a přepnout alias z primární na sekundární beze změn informací o připojení.

  • Aplikace Function Apps nasazené v primární i sekundární oblasti. Aplikace v sekundární oblasti zůstává nečinná, protože nepřijímá zprávy.

  • Triggery každé aplikace funkcí používají připojovací řetězec direct (nonalias) pro příslušný obor názvů služby Event Hubs.

  • Vydavatelé publikují do oboru názvů Event Hubs pomocí alias připojovací řetězec.

Diagram znázorňující příklad architektury typu aktivní-pasivní Geografické zotavení po havárii služby Event Hubs zahrnuje několik oblastí a samostatné aplikace funkcí a databáze v každé oblasti.

Před převzetím služeb při selhání směrují vydavatelé, kteří posílají události na sdílený alias, provoz do primárního centra událostí. Hlavní funkční aplikace naslouchá výhradně primárnímu centru událostí. Sekundární aplikace funkcí zůstává pasivní a nečinná.

Při spuštění převzetí služeb jsou vydavatelé, odesílající události do sdíleného aliasu, směrováni do sekundárního centra událostí. Sekundární aplikace funkce se aktivuje a spustí automaticky. Centrum událostí může řídit celý proces převzetí služeb při selhání a každá aplikace funkcí běží jenom v případě, že je aktivní odpovídající centrum událostí.

Odolné funkce

Informace o zotavení po havárii v rámci více oblastí pro trvalé funkce najdete v tématu Obnova po havárii a geografická distribuce v Azure trvalých funkcích.

Odolnost vůči údržbě služeb

Funkce provádějí pravidelné upgrady služeb a další úlohy údržby.

  • Přechodná odolnost proti chybám: Během údržby služby můžou instance, které spouští vaši aplikaci funkcí, restartovat nebo zaznamenat dočasné přerušení. Ujistěte se, že klientské aplikace, které pracují s vaší aplikací funkcí, jsou odolné vůči přechodným chybám.
  • Povolení redundance zón: Když ve svém plánu povolíte redundanci zón, zlepšíte také odolnost při aktualizacích platformy. Nasazení několika instancí v plánu a povolení redundance zón pro váš plán přidá další vrstvu odolnosti, pokud instance nebo zóna během upgradu není v pořádku.

  • Další dočasné instance: Aby se během upgradu zachovala očekávaná kapacita, platforma během procesu upgradu automaticky přidá další instance plánu.

  • Povolení redundance zón: Když ve svém plánu povolíte redundanci zón, zlepšíte také odolnost při aktualizacích platformy. Aktualizační domény se skládají z kolekcí virtuálních počítačů, které během aktualizace přecházejí do režimu offline, a mapují se na zóny dostupnosti. Nasazení více instancí v plánu a povolení redundance zón pro váš plán přidá další vrstvu odolnosti, pokud instance nebo zóna během upgradu není v pořádku.

  • App Service Environment: Pokud hostujete aplikaci funkcí ve službě App Service Environment, můžete cyklus upgradu přizpůsobit. Pokud musíte ověřit účinek upgradů na pracovní zatížení, povolte ruční upgrady. Tento přístup použijte k ověření a otestování neprodukční instance před použitím upgradů na produkční instanci.

    Další informace o předvolbách údržby najdete v tématu Předvolby upgradu pro plánovanou údržbu služby App Service Environment.

Odolnost proti nasazení aplikací

Nasazení aplikací představují riziko problémů v produkčním prostředí. Pokud dojde k problémům, připravte se na vrácení aktualizace. Řiďte, jak se aktualizace zavádějí, aby se snížilo přerušení při restartování aplikace.

Plány Flex Consumption podporují strategie aktualizace webu, které poskytují různé způsoby nasazení aktualizací aplikací. Mezi tyto strategie patří postupné aktualizace pro nasazení s nulovými výpadky.

Funkce slotů nasazení umožňují nasazení vašich aplikací funkcí bez výpadků. Pomocí slotů nasazení minimalizujte účinek nasazení a změn konfigurace pro vaše uživatele. Sloty nasazení také snižují pravděpodobnost restartování aplikace. Restartování aplikace způsobuje přechodné chyby.

Smlouva o úrovni služeb

Smlouva o úrovni služeb (SLA) pro služby Azure popisuje očekávanou dostupnost každé služby a podmínky, které musí vaše řešení splnit, aby bylo dosaženo očekávané dostupnosti. Další informace najdete v tématu Smlouvy SLA pro online služby.

Azure Functions poskytují jedinečné SLA dostupnosti pro plán typu Consumption a pro jiné typy plánů.

Související obsah

  • Last updated on