Doporučení pro sebeopravení a sebezáchovu

  • Článek

Platí pro toto doporučení kontrolního seznamu spolehlivosti azure Well-Architected Framework:

RE:07 Posílení odolnosti a obnovitelnosti úloh implementací sebezáchovy a samoopravných opatření Zabudujte do řešení funkce pomocí vzorců spolehlivosti založených na infrastruktuře a softwarových vzorů návrhu pro zpracování selhání komponent a přechodných chyb. Zabudujte do systému funkce, které detekují selhání součástí řešení a automaticky zahájí nápravnou akci, zatímco úloha bude dál fungovat s plnou nebo omezenou funkčností.

Související příručky:Úlohy na | pozadíPřechodné chyby

Tato příručka popisuje doporučení pro vytváření funkcí samoopravení a sebezáchovy v architektuře aplikace za účelem optimalizace spolehlivosti.

Možnosti sebezáchovy přidávají vaší úloze odolnost. Snižují pravděpodobnost úplného výpadku a umožňují, aby vaše úloha fungovala ve sníženém stavu, zatímco se součásti, které selhaly, obnovují. Funkce samoopravení pomáhají vyhnout se výpadkům tím, že zabudují detekci selhání a automatické opravné akce, které reagují na různé typy selhání.

Tato příručka popisuje vzory návrhu, které se zaměřují na sebezáchovu a sebeopravení. Začleníte je do úloh, abyste posílili jejich odolnost a obnovitelnost. Pokud neimplementujete vzory, jsou vaše aplikace ohroženy selháním, když se vyskytnou nevyhnutelné problémy.

Definice

Období Definice
Samoopravování Schopnost úloh automaticky řešit problémy obnovením ovlivněných komponent a v případě potřeby převzetím služeb při selhání do redundantní infrastruktury
Sebezáchova Schopnost úlohy být odolná proti potenciálním problémům.

Klíčové strategie návrhu

Pokyny k sebezáchovy

Pokud chcete navrhnout úlohu pro sebezáchovu, postupujte podle vzorů návrhu infrastruktury a architektury aplikací a optimalizujte odolnost úloh. Pokud chcete minimalizovat pravděpodobnost úplného výpadku aplikace, zvyšte odolnost řešení tím, že odstraníte jednotlivé body selhání a minimalizujete poloměr výbuchu selhání. Přístupy k návrhu v tomto článku poskytují několik možností, jak posílit odolnost úloh a splnit definované cíle spolehlivosti úloh.

Pokyny a vzory návrhu infrastruktury

Na úrovni infrastruktury by redundantní návrh architektury měl podporovat důležité toky s prostředky nasazenými napříč zónami dostupnosti nebo oblastmi. Pokud je to možné, implementujte automatické škálování . Automatické škálování pomáhá chránit vaše úlohy před neočekávanými nárůsty aktivity a dále posiluje vaši infrastrukturu.

Pokud chcete minimalizovat poloměr výbuchu v případě, že dojde k problémům, použijte vzor razítka nasazení nebo přepážku. Tyto vzory pomáhají udržet vaše úlohy dostupné, pokud není k dispozici jednotlivá komponenta. V kombinaci se strategií automatického škálování použijte následující vzory návrhu aplikací.

  • Model razítka nasazení: Zřiďte, spravujte a monitorujte různé skupiny prostředků pro hostování a provoz více úloh nebo tenantů. Každá jednotlivá kopie se nazývá razítko nebo někdy jednotka služby, jednotka škálování nebo buňka.

  • Přepážka: Rozdělte instance služby do různých skupin, označovaných jako fondy, na základě požadavků na zatížení a dostupnost příjemce. Tento návrh pomáhá izolovat selhání a umožňuje zachovat funkčnost služby pro některé uživatele, a to i během selhání.

Pokyny a vzory návrhu aplikací

Vyhněte se vytváření monolitických aplikací v návrhu aplikace. Používejte volně propojené služby nebo mikroslužby, které spolu vzájemně komunikují prostřednictvím dobře definovaných standardů, abyste snížili riziko rozsáhlých problémů při selhání jedné komponenty. Můžete například standardizovat použití služby Service Bus ke zpracování veškeré asynchronní komunikace. Standardizace komunikačních protokolů zajišťuje konzistentní a zjednodušený návrh aplikací, díky čemuž je úloha spolehlivější a snadněji řešit potíže při selhání. Pokud je to praktické, upřednostněte asynchronní komunikaci mezi komponentami před synchronní komunikací, abyste minimalizovali problémy s vypršením časového limitu, jako je například nedoručení. Následující vzory návrhu vám pomůžou uspořádat úlohy a definovat komunikaci mezi komponentami způsobem, který nejlépe vyhovuje vašim obchodním požadavkům.

  • Vzor ambasadora: Oddělte obchodní logiku od síťového kódu a logiky odolnosti. Vytvoří služby pomocných rutin, které odesílají síťové požadavky jménem aplikace nebo služby uživatele. Tento model můžete použít k implementaci mechanismů opakování nebo přerušení okruhu.

  • Asynchronní Request-Reply vzor: Pokud zpracování back-endu musí být asynchronní, oddělte back-endové zpracování od front-endového hostitele, ale front-end potřebuje jasnou odpověď.

  • Model doplňování mezipaměti: Načtěte data na vyžádání z úložiště dat do mezipaměti. Tento model může zvýšit výkon a pomáhá udržovat konzistenci mezi daty uloženými v mezipaměti a daty, která jsou v podkladovém úložišti dat.

  • Model jističe: Pomocí jističů můžete proaktivně určit, jestli chcete operaci povolit, nebo vrátit výjimku na základě počtu nedávných selhání.

  • Model kontroly deklarací identity: Rozdělte velkou zprávu na kontrolu deklarace identity a datovou část. Odešlete kontrolu deklarace identity na platformu pro zasílání zpráv a uložte datovou část do externí služby. Tento model umožňuje zpracování velkých zpráv a současně chrání sběrnici zpráv a zabraňuje zahlcení nebo zpomalení klienta.

  • Model konkurenčních příjemců: Umožňuje více souběžných příjemců zpracovávat zprávy přijaté ve stejném kanálu zasílání zpráv. Systém může zpracovávat více zpráv současně, což optimalizuje propustnost, zlepšuje škálovatelnost a dostupnost a vyrovnává zatížení.

  • Konfigurace časových limitů požadavků: Nakonfigurujte časové limity požadavků pro volání služeb nebo databází. Vypršení časových limitů připojení k databázi je obvykle nastaveno na 30 sekund.

  • Model gatekeeper: Chraňte aplikace a služby pomocí vyhrazené instance hostitele ke zprostředkování požadavků mezi klienty a aplikací nebo službou. Zprostředkovatel ověřuje a sanituje požadavky a může poskytnout další vrstvu zabezpečení, která omezí prostor pro útoky na systém.

  • Model vyrovnávání zatížení na základě front: Oddělte úlohy od služby ve vašem řešení pomocí fronty mezi nimi, aby se mohly spouštět asynchronně. Použijte frontu jako vyrovnávací paměť mezi úlohou a službou, kterou vyvolá, a pomozte tak vyhladit občasné velké zatížení, které může způsobit selhání služby nebo vypršení časového limitu úkolu. Tento model může pomoct minimalizovat vliv špiček v poptávce na dostupnost a odezvu úkolu a služby.

  • Model omezování: Řídí spotřebu prostředků, které používá instance aplikace, jednotlivého tenanta nebo celé služby. Tento model umožňuje systému i nadále fungovat a plnit smlouvy o úrovni služeb (SLA), i když zvýšení poptávky představuje extrémní zatížení prostředků.

  • Model zpracování přechodných chyb a vzor opakování: Implementujte strategii pro zpracování přechodných selhání, která zajistí odolnost vašich úloh. Přechodná selhání jsou normální a očekávané výskyty v cloudových prostředích. Mezi typické příčiny přechodných chyb patří momentální ztráta síťového připojení, ukončené připojení k databázi nebo vypršení časového limitu, kdy je služba zaneprázdněná. Další informace o vývoji strategie opakování najdete v průvodci zpracováním přechodných chyb v této sérii.

Úlohy na pozadí

Úlohy na pozadí představují efektivní způsob, jak zvýšit spolehlivost systému oddělením úloh od uživatelského rozhraní. Implementujte úlohu jako úlohu na pozadí, pokud nevyžaduje vstup uživatele nebo zpětnou vazbu a nemá vliv na odezvu uživatelského rozhraní.

Mezi běžné příklady úloh na pozadí patří:

  • Úlohy náročné na procesor, například provádění složitých výpočtů nebo analýza strukturálních modelů
  • Úlohy náročné na vstupně-výstupní operace, jako je spouštění více operací úložiště nebo indexování velkých souborů.
  • Dávkové úlohy, například pravidelná aktualizace dat nebo zpracování úkolů v určitém čase.
  • Dlouhotrvající pracovní postupy, jako je například dokončení objednávky nebo zřizování služeb a systémů.

Další informace najdete v tématu Doporučení pro úlohy na pozadí.

Pokyny k samoopravení

Pokud chcete navrhnout úlohu pro samoopravení, implementujte detekci selhání, aby se aktivovaly automatické odpovědi a kritické toky se řádně obnovily. Povolením protokolování získáte provozní přehled o povaze selhání a úspěšnosti obnovení. Přístupy, které používáte k dosažení samoopravení kritického toku, závisí na cílech spolehlivosti definovaných pro tento tok a jeho komponentách a závislostech.

Pokyny k návrhu infrastruktury

Na úrovni infrastruktury by vaše kritické toky měly být podporovány návrhem redundantní architektury s povoleným automatizovaným převzetím služeb při selhání pro komponenty, které ho podporují. Automatizované převzetí služeb při selhání můžete povolit pro následující typy služeb:

  • Výpočetní prostředky: Azure Virtual Machine Scale Sets a většinu výpočetních služeb typu platforma jako služba (PaaS) je možné nakonfigurovat pro automatické převzetí služeb při selhání.

  • Databáze: Relační databáze je možné nakonfigurovat pro automatické převzetí služeb při selhání pomocí řešení, jako jsou Azure SQL clustery s podporou převzetí služeb při selhání, skupiny dostupnosti AlwaysOn nebo integrované funkce se službami PaaS. Databáze NoSQL mají podobné možnosti clusteringu a integrované funkce pro služby PaaS.

  • Úložiště: Používejte redundantní možnosti úložiště s automatickým převzetím služeb při selhání.

Pokyny a vzory návrhu aplikací

  • Blokovat špatné aktéry: Pokud omezíte klienta, neznamená to, že se klient choval zlomyslně. Může to znamenat, že klient překročil kvótu služby. Pokud ale klient konzistentně překračuje kvótu nebo se jinak chová špatně, můžete ho zablokovat. Definujte proces mimo pásmo, který má klient požádat o odblokování.

  • Model jističe: Pokud selhání přetrvává i po zahájení mechanismu opakování, riskujete kaskádová selhání vyplývající z rostoucího backlogu volání. Jistič, který je navržený pro práci s mechanismem opakování, omezuje riziko kaskádových selhání tím, že brání aplikaci v opakovaném pokusu o spuštění operace, u které je pravděpodobné, že selže.

  • Model kompenzační transakce: Pokud použijete nakonec konzistentní operaci, která se skládá z řady kroků, implementujte model Kompenzační transakce. Pokud jeden nebo více kroků selže, můžete pomocí tohoto vzoru vrátit zpět práci, kterou tyto kroky provedly.

  • Snížení výkonu: Někdy nemůžete vyřešit problém, ale můžete zajistit omezenou funkčnost. Vezměme si aplikaci, která zobrazuje katalog knih. Pokud aplikace nedokáže načíst miniatury obálek, může zobrazovat zástupné obrázky. Pro aplikaci můžou být nekritické celé subsystémy. Například u webu elektronického obchodování je zobrazování doporučení produktů pravděpodobně méně důležité než zpracování objednávek. Řádné snížení výkonu může také zahrnovat automatické operace převzetí služeb při selhání. Když databáze automaticky převezme služby při selhání repliky kvůli problému s primární instancí, výkon se na krátkou dobu sníží.

  • Model volby vedoucího: Pokud potřebujete koordinovat úkol, vyberte pomocí volby vedoucího koordinátora koordinátora, aby jeden koordinátor nebyl jediným bodem selhání. Pokud koordinátor selže, vybere se nový. Místo implementace algoritmu volby vedoucích od nuly zvažte řešení, jako je ZooKeeper.

  • Vzory testů: Zahrňte testování vzorů, které implementujete jako součást standardních testovacích postupů.

  • Použití kontrolních bodů pro dlouhotrvající transakce: Kontrolní body můžou zajistit odolnost v případě, že dlouhotrvající operace selže. Když se operace restartuje, například pokud ji vyzvedne jiný virtuální počítač, může pokračovat od posledního kontrolního bodu. Zvažte implementaci mechanismu, který zaznamenává informace o stavu úkolu v pravidelných intervalech. Uložte tento stav do odolného úložiště, ke kterému může přistupovat libovolná instance procesu, který úlohu spouští. Pokud je proces vypnutý, lze práci, kterou prováděl, pokračovat od posledního kontrolního bodu pomocí jiné instance. Existují knihovny, které tuto funkci poskytují, například NServiceBus a MassTransit. Transparentně zachovají stav, kdy intervaly odpovídají zpracování zpráv z front v Azure Service Bus.

Automatizované akce samoopravení

Dalším přístupem k samoopravení je použití automatizovaných akcí, které vaše řešení monitorování aktivuje při zjištění předem určených změn stavu. Pokud například monitorování zjistí, že webová aplikace nereaguje na požadavky, můžete vytvořit automatizaci pomocí skriptu PowerShellu a restartovat službu App Service. V závislosti na sadě dovedností vašeho týmu a upřednostňovaných vývojových technologiích použijte webhook nebo funkci k vytváření složitějších automatizačních akcí. Příklad použití funkce k reakci na omezování databáze najdete v referenční architektuře cloudové automatizace založené na událostech. Použití automatizovaných akcí vám může pomoct rychle se zotavit a minimalizovat nutnost lidského zásahu.

Usnadnění Azure

Mechanismus opakování obsahuje většina služeb Azure a klientských sad SDK. Liší se ale, protože každá služba má jiné vlastnosti a požadavky, takže každý mechanismus opakování je vyladěný na konkrétní službu. Další informace najdete v tématu Doporučení pro zpracování přechodných chyb.

Skupiny akcí Azure Monitoru slouží k oznámením, jako je e-mail, hlas nebo SMS, a k aktivaci automatizovaných akcí. Když budete upozorněni na selhání, aktivujte Azure Automation runbook, Azure Event Hubs, funkci Azure, aplikaci logiky nebo webhook, který provede automatickou akci opravy.

Požadavky

Seznamte se s aspekty jednotlivých vzorů. Před implementací se ujistěte, že je model vhodný pro vaše úlohy a obchodní požadavky.

Příklad

Příklady použití některých vzorů najdete v tématu Vzor spolehlivé webové aplikace pro .NET. Postupujte podle těchto kroků a nasaďte referenční implementaci.

Kontrolní seznam spolehlivosti

Projděte si kompletní sadu doporučení.

Kontrolní seznam spolehlivosti