Sdílet prostřednictvím

Spolehlivost ve službě Azure Functions

Azure Functions je výpočetní služba řízená událostmi, která umožňuje spouštět malé bloky kódu (funkcí), aniž byste museli explicitně zřizovat nebo spravovat infrastrukturu. 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, což je vhodné pro zpracování dat, integraci systémů a spouštění úloh 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 azure Functions 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. Také zvýrazňuje klíčové informace o smlouvě o úrovni služeb (SLA) služby Azure Functions.

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

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

Přehled architektury spolehlivosti

Při nasazování Azure Functions je důležité seznámit se s několika 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ě slouží ke správě aspektů 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 určité 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žité části architektury spolehlivosti azure Functions a měli byste je nakonfigurovat tak, aby splňovaly požadavky vaší aplikace funkcí na odolnost.

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

  • Durable Functions: Odolné funkce jsou stavové funkce, zahrnující dlouhotrvající orchestrace a stavové entity.

    Při použití Durable Functions nakonfigurujete zprostředkovatele úložiště, který ukládá stav. Potřebujete vyhodnotit charakteristiky spolehlivosti zvoleného úložiště stavu a nakonfigurovat ho tak, aby splňoval 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 Azure Functions zahrnuje integrované zpracování přechodných chyb pro mnoho triggerů a vazeb. Pokud dojde k přechodné chybě při aktivaci podporovaného spouštěče nebo při čtení či zápisu dat podporovanou vazbou, platforma může operaci automaticky opakovat. Toto vestavěné chování opakování pomáhá zajistit, aby dočasné problémy s připojením nebo výpadky služby nezabránily spuštění vaší funkce. Další informace najdete v tématu Zpracování chyb a opakování ve službě Azure Functions.

    Tato ochrana ale pokrývá pouze přechodné chyby. Trvalé chyby, jako je nesprávně nakonfigurovaný připojovací řetězec nebo odstraněný zdroj, se neopakují.

    Trvalá selhání a opakované přechodné chyby se považují za chyby a můžete nakonfigurovat protokolování tak, aby zachytilo informace o chybách spuštění funkce. Další informace najdete v tématu Konfigurace monitorování pro Azure Functions.

  • Kód vaší funkce: V těle vaší funkce zodpovídáte za zpracování přechodných chyb při volání externích služeb. Měli byste implementovat logiku opakování, časové limity a vzory jističe podle potřeby pro všechna volání externí služby provedená v kódu funkce. Navrhněte funkce tak, aby byly idempotentní všude, kde je to možné, aby opakované pokusy nezpůsobily duplicitní vedlejší účinky.

  • Klienty: Všechny klientské aplikace, které se připojují k funkcím synchronně, například pomocí 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ánu Flex Consumption, plánu Premium nebo vyhrazeného plánu (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 má nějaká zóna dostupnosti v dané oblasti problém, vaše funkce budou dál spouštět instance v zónách, které jsou v pořádku.

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

Diagram znázorňující zónově redundantní plán Služby Azure Functions se třemi instancemi rozloženými mezi tři zóny a zónově redundantním účtem úložiště

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. Úplné podrobnosti o tom, jak App Service zpracovává redundanci zón, najdete v tématu Spolehlivost ve službě Azure App Service.

Pokud nepovolíte redundanci zón, je váš plán nezonální nebo regionální, což znamená, že instance plánů můžou být umístěné v jakékoli zóně dostupnosti v rámci oblasti nebo ve stejné zóně a nejsou odolné vůči selhání zón 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 je možné 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 je možné 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

  • Operační systémy: Podporovány jsou plány pro Windows i Linux.

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

  • Účet úložiště hostitele: Musíte nakonfigurovat výchozí účet úložiště hostitele vaší aplikace funkcí tak, aby používal zónově redundantní úložiště (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žíváte samostatný účet úložiště, měli byste ho aktualizovat tak, aby byl zónově redundantní.

Úvahy

Redundance zón zaručuje pouze trvalou dobu provozu pro nasazené aplikace. Výpadek zóny dostupnosti může mít vliv na některé aspekty služby Azure Functions, i když aplikace dál 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ánu 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 jsou distribuovány alespoň do dvou zón round-robin způsobem.

    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. Všechny instance vytvořené platformou jsou spravovány platformou, jsou účtovány jako vždy připravené instance a nemění nastavení jejich vždy připravené konfigurace.

  • Instance na vyžádání se vytvářejí v důsledku zdrojových svazků událostí, protože aplikace se škáluje nad rámec počtu instancí, které jsou vždy připravené. Instance na vyžádání se distribuují mezi zóny dostupnosti na základě maximálního úsilí. Rychlejší škálování je upřednostňováno před rovnoměrným rozdělením mezi 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 se rovnoměrně rozdělí pouze v případě, že je kapacita násobkem počtu zón.
  • Pro hodnotu kapacity větší než Počet zón * Počet instancí jsou extra instance rozloženy mezi zbývající zóny.

Když služba Functions přiděluje instance plánu zónově redundantní úrovně Premium, používá vyrovnávání zóny s nejlepším úsilím, které nabízí základní škálovací sady virtuálních počítačů Azure. Plán Premium se považuje za vyvážený , když každá zóna má buď stejný počet virtuálních počítačů ve všech ostatních zónách používaných plánem Premium, plus-nebo-minus jeden virtuální počítač.

Náklady

S povolením redundance zón nejsou spojené žádné další náklady. Ceny pro zónově redundantní plán jsou stejné jako plán s jednou zónou.

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

Pokud ale povolíte zóny dostupnosti v plánu s méně než dvěma instancemi, 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 Azure Functions.

Konfigurujte podporu zón dostupnosti

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

  • Povolení redundance zón u existujícího plánu: V případě plánů Premium můžete během vytváření plánu povolit pouze redundanci zón. Existující plán Premium nejde převést na zónově redundantní. Místo toho musíte aplikaci migrovat 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í budou nadále fungovat, i když zóny v dané oblasti trpí výpadkem.

Během výpadku zóny služba Azure Functions detekuje ztracené instance a automaticky se pokusí vyhledat nebo vytvořit náhradní instance v zónách, které jsou v pořádku. Tento proces se provádí na základě nejlepšího úsilí a není zaručený. Pokud vaše úloha musí mít 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é. Tento přístup umožňuje řešení tolerovat určitou ztrátu kapacity a nadále fungovat bez snížení výkonu. Další informace najdete v tématu Správa kapacity pomocí nadměrného zřizování.

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ón ve službě Azure 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: Azure Functions je bezstavová výpočetní služba, takže mezi zónami není potřeba replikovat žádná zákaznická 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ě Durable Functions 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í, hostitelský účet úložiště používá ZRS (zónově redundantní úložiště) a dojde k výpadku zóny dostupnosti.

  • Detekce a odpověď: Platforma Azure Functions zodpovídá za detekci selhání v zóně dostupnosti. Nemusíte dělat nic, abyste zahájili převzetí zóny.
  • 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á, všechny probíhající požadavky, které jsou připojené k instanci v vadné zóně dostupnosti, se ukončí a je potřeba je 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 Azure Functions je bezstavová služba.

    Pokud váš účet hostitelského úložiště používá ZRS, Azure Storage zajišťuje, aby nedošlo ke ztrátě dat ze selhání zóny.

    V případě Durable Functions zkontrolujte poskytovatele úložiště a zjistěte, jestli je možné ztráty dat během 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: Azure Functions zjistí ztracené instance z této zóny a pokusí se najít nové náhradní instance. Jakmile Služba Azure 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 tak, aby zohlednily ztrátu zóny dostupnosti tím, že kapacitu nadměrně přidělíte.

  • 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í, Azure Functions automaticky obnoví instance v zóně dostupnosti, odebere všechny 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 Azure Functions spravuje směrování síťového provozu, zajištění dostupnosti při selhání a obnovení zón pro zónově redundantní prostředky. Nemusíte nic inicializovat. Vzhledem k tomu, že je tato funkce plně spravovaná, nemusíte ověřovat procesy selhání zóny dostupnosti.

Odolnost proti selháním v celé oblasti

Azure Functions je služba s jednou oblastí. Pokud oblast přestane být dostupná, váš prostředek Azure Functions je také nedostupný.

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

Abyste se vyhnuli ztrátě spuštění během výpadků, můžete nasadit stejné funkce redundantně do aplikací pro funkce v několika regionech.

Zodpovídáte za:

  • Nasazení funkčních aplikací do několika regionů
  • Správa distribuce provozu mezi oblastmi
  • Implementace mechanismů převzetí při selhání
  • Zajištění konzistence dat napříč oblastmi (pokud je k dispozici)
  • Monitorování a správa nasazení mezi oblastmi

Když spustíte stejný kód funkce ve více oblastech, můžete zvážit dva běžně používané vzory: aktivní-aktivní a aktivní-pasivní. Následující části obsahují stručný úvod k těmto vzorům, ale neposkytují podrobné pokyny ani kroky konfigurace.

Model aktivní-aktivní pro funkce triggeru HTTP

S modelem aktivní-aktivní funkce v obou regionech aktivně běží a zpracovávají události, a to buď v duplikátu, anebo střídavě. cs-CZ: Pro důležité funkce aktivované protokolem HTTP byste měli použít vzor typu aktivní-aktivní v kombinaci se službou Azure Front Door, která může směrovat a vyrovnávat zátěž HTTP požadavků mezi funkcemi spuštěný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 vynechá z rotace a přesměruje provoz jenom na zbývající funkce, které jsou v pořádku.

Diagram znázorňující ukázku aktivní-aktivní architektury se směrováním služby Azure Front Door mezi aplikacemi Azure Functions v různých oblastech, z nichž každá má 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 funkce aktivované službou Service Bus a Event Hubs), použijte model aktivní-pasivní. Díky modelu aktivní-pasivní funkce běží aktivně v oblasti, která přijímá události, zatímco stejné funkce v druhé oblasti zůstávají nečinné. Model aktivní-pasivní poskytuje způsob, jak zajistit, aby každou zprávu zpracovala pouze jediná funkce, což je důležité pro zachování konzistence dat. Současně poskytuje mechanismus pro přechod na sekundární oblast v případě katastrofy, jako je například výpadek oblasti.

Při selhání funkční aplikace je třeba zohlednit její převzetí v souvislosti s chováním při selhání jiných služeb, například:

Představte si ukázkovou topologii pomocí triggeru služby Azure 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:

  • Služba Azure Event Hubs nasazená do primární i sekundární oblasti.
  • Geografické zotavení po havárii umožňuje spárovat primární a sekundární centra událostí. Tím se také vytvoří alias, který můžete použít pro připojení k oboru názvů Event Hubs a přepnout z primárního na sekundární beze změny informací o připojení.
  • Aplikace funkcí nasazené do primární i sekundární oblasti (převzetí služeb při selhání) s aplikací v sekundární oblasti jsou v podstatě nečinné, protože se tam neodesílají zprávy.
  • Aplikace funkcí se aktivuje v přímém (nonalias) připojovacím řetězci pro příslušný obor názvů služby Event Hubs.
  • Vydavatelé do jmenného prostoru služby Event Hubs by měli publikovat do aliasového připojovacího řetězce.

Diagram znázorňující příklad architektury aktivní-pasivní s geografickou obnovou po havárii Event Hubs, které pokrývají více regionů, a samostatnými funkčními aplikacemi a databázemi v každém regionu.

Před přepnutím vydavatelé odesílají prostřednictvím trasy sdíleného aliasu do primárního centra událostí. Primární aplikační funkce naslouchá výhradně primárnímu událostnímu centru. Sekundární funkce aplikace je pasivní a nečinná.

Jakmile dojde k přepnutí při selhání, vydavatelé odesílající na sdílený alias jsou směrováni do sekundárního centra událostí. Sekundární funkční aplikace se nyní stává aktivní a automaticky se spouští. Efektivní přepnutí do sekundární oblasti při selhání lze zcela řídit prostřednictvím centra událostí, přičemž funkce se stanou aktivními pouze tehdy, když je příslušné centrum událostí aktivní.

Odolné funkce

Informace o zotavení po havárii ve více oblastech pro Durable Functions najdete v tématu Zotavení po havárii a geografická distribuce ve službě Azure Durable Functions.

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

Azure Functions provádí pravidelné upgrady služeb a další úlohy údržby.

  • Přechodná odolnost proti chybám: Během údržby služby můžou být instance, které spouští vaši aplikaci funkcí, restartovány nebo dochází k dočasným přerušením. Zajistěte, aby všechny klientské aplikace, které pracují s vaší aplikací funkcí, byly 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í 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.

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 potřebujete ověřit účinek upgradů na úlohu, povolte ruční upgrady. Tento přístup umožňuje provádět ověřování a testování neprodukční instance předtím, než je použijete 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, měli byste být připraveni vrátit aktualizaci zpět. Měli byste také řídit, jak se aktualizace nasadí, aby se minimalizovalo přerušení způsobené restartováním aplikace.

Plány Flex Consumption podporují strategie aktualizace webů, které poskytují několik způsobů nasazení aktualizací aplikací, včetně kumulativních aktualizací pro nasazení s nulovými výpadky.

Azure Functions sloty nasazení umožňují nasazení funkčních aplikací 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ůsobí přechodnou chybu.

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 poskytuje jedinečné smlouvy SLA dostupnosti pro plán Consumption a pro jiné typy plánů.

Související obsah

  • Last updated on