Sdílet prostřednictvím

Doporučení pro samoopravení a sebezáchování

  • Článek

Platí pro toto doporučení kontrolního seznamu pro spolehlivost architektury Azure Well-Architected Framework:

RE:07 Posílení odolnosti a obnovitelnosti úloh implementací samozáchů a samoopravených opatření. S využitím vzorů spolehlivosti založených na infrastruktuře a vzorů návrhu na základě softwaru můžete do řešení problémů se selháními komponent a přechodnými chybami začlenit možnosti. Zabudujte do systému funkce pro detekci selhání komponent řešení a automaticky iniciujte nápravnou akci, zatímco úloha bude fungovat v plné nebo omezené funkčnosti.

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

Tato příručka popisuje doporučení pro vytváření možností samoopravení a samozáchování v architektuře aplikace za účelem optimalizace spolehlivosti.

Možnosti samoobslužného zachování přidávají do vaší úlohy odolnost. Snižují pravděpodobnost úplného výpadku a umožňují vaší úloze pracovat v degradovaném stavu, zatímco se obnoví součásti, které selhaly. Možnosti samoopravení pomáhají vyhnout se výpadkům vytvořením detekce selhání a automatických nápravných akcí, které reagují na různé typy selhání.

Tato příručka popisuje vzory návrhu, které se zaměřují na sebezáchování a samoopravení. Začleníte je do své úlohy, aby se zvýšila jeho odolnost a obnovitelnost. Pokud neimplementujete vzory, vaše aplikace jsou ohroženy selháním, když nastanou nevyhnutelné problémy.

Definice

Pojem definice
Samoopravování Schopnost úlohy automaticky vyř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 vaší úlohy být odolná proti potenciálním problémům.

Klíčové strategie návrhu

Návrh pro samozásobování

Pokud chcete navrhnout úlohu pro zachování sebezáchovy, postupujte podle vzorů návrhu architektury infrastruktury a aplikací a optimalizujte odolnost úloh. Pokud chcete minimalizovat šanci na úplný výpadek aplikace, zvyšte odolnost řešení tím, že eliminujete 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 vaší úlohy.

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 posílit vaši infrastrukturu.

Pomocí vzoru razítka nasazení nebo vzoru Bulkhead minimalizujte poloměr výbuchu při vzniku problémů. Tyto vzory pomáhají udržet úlohu dostupnou, pokud není dostupná 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řizování, správa a monitorování různých skupin prostředků pro hostování a provoz více úloh nebo tenantů Každá jednotlivá kopie se nazývá kolek nebo někdy jednotka služby, jednotka škálování nebo buňka.

  • Model Bulkhead: 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 udržovat funkčnost služeb pro některé uživatele 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ě svázané služby nebo mikroslužby, které vzájemně komunikují prostřednictvím dobře definovaných standardů, abyste snížili riziko rozsáhlých problémů, když dojde k selhání jedné součásti. 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, aby návrh aplikací byl konzistentní a zjednodušený, což usnadňuje řešení potíží při selhání úloh. 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 nedoručení dopisů. Následující vzory návrhu vám pomůžou uspořádat úlohu 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.

  • Model asynchronní odpovědi na požadavek: Oddělení back-endového zpracování od front-endového hostitele, pokud zpracování back-endu musí být asynchronní, 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 zlepš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 má operace pokračovat, 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 deklarací 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 při ochraně sběrnice zpráv a zachování 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í. Časové limity připojení k databázi jsou obvykle nastavené 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ěří 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ě fronty: Oddělte úlohy od služby ve vašem řešení pomocí fronty mezi nimi, aby se mohly spouštět asynchronně. Frontu použijte jako vyrovnávací paměť mezi úlohou a službou, kterou vyvolá, aby pomohla hladkým přerušovaným velkým zatížením, které může způsobit selhání služby nebo vypršení časového limitu úlohy. Tento model může pomoct minimalizovat dopad špiček na poptávku po dostupnosti a odezvě úlohy a služby.

  • Model omezování: Řídí spotřebu prostředků používaných instancí aplikace, individuálního tenanta nebo celé služby. Tento model umožňuje systému i nadále fungovat a splňovat smlouvy o úrovni služeb (SLA), a to i v případě, že zvýšení poptávky představuje extrémní zatížení prostředků.

  • Model zpracování přechodných chyb a model 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í, přeruš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 přechodným zpracováním 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í. Pokud úloha na pozadí nevyžaduje uživatelský vstup nebo zpětnou vazbu a nemá vliv na odezvu uživatelského rozhraní, implementujte úlohu jako úlohu na pozadí.

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

  • Úlohy náročné na procesor, jako je 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, například spouštění více operací úložiště nebo indexování velkých souborů
  • Dávkové úlohy, jako je například pravidelné aktualizace dat nebo zpracování úkolů v určitém čase.
  • Dlouhotrvající pracovní postupy, 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í.

Návrh pro samoopravení

Pokud chcete navrhnout úlohu pro samoopravení, implementujte detekci selhání, aby se automatické odpovědi aktivovaly a kritické toky se řádně zotavily. Povolte protokolování, abyste zajistili provozní přehledy o povaze selhání a úspěchu obnovení. Přístupy, které provedete k dosažení samoopravení kritického toku, závisí na cílech spolehlivosti definovaných pro tento tok a komponentách a závislostech toku.

Pokyny k návrhu infrastruktury

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

  • Výpočetní prostředky: Škálovací sady virtuálních počítačů Azure a většina výpočetních služeb PaaS (Platforma jako služba) 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 clustery s podporou převzetí služeb při selhání Azure SQL, 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žijte možnosti redundantního ú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 klient působí zlomyslně. Může to znamenat, že klient překročil kvótu služby. Pokud ale klient konzistentně překročí kvótu nebo se jinak chová špatně, můžete je zablokovat. Definujte proces mimo pásmo pro klienta, který vyžaduje odblokování.

  • Model jističe: Pokud po zahájení mechanismu opakování přetrvává selhání, riskujete kaskádové selhání vyplývající z rostoucího backlogu volání. Jistič, který je navržený tak, aby fungoval 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, která pravděpodobně 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 kroky provedly.

  • Degrade gracely: Někdy nemůžete problém obejít, ale můžete poskytnout 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 zobrazení doporučení k produktům 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 po krátkou dobu sníží.

  • Model volby vedoucího procesu: Pokud potřebujete koordinovat úkol, použijte volby vedoucího k výběru 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ího od začátku zvažte řešení, jako je ZooKeeper.

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

  • Kontrolní body používejte pro dlouhotrvající transakce: Kontrolní body můžou poskytovat odolnost, pokud se dlouhotrvající operace nezdaří. Když se operace restartuje, například pokud ji vyzvedne jiný virtuální počítač, může pokračovat z posledního kontrolního bodu. Zvažte implementaci mechanismu, který zaznamenává informace o stavu úlohy v pravidelných intervalech. Uložte tento stav v odolném úložišti, ke kterému má přístup libovolná instance procesu, na kterém je spuštěna úloha. Pokud je proces vypnutý, lze práci, kterou prováděla, obnovit z posledního kontrolního bodu pomocí jiné instance. Existují knihovny, které poskytují tuto funkci, jako je NServiceBus a MassTransit. Transparentně uchovávají stav, ve kterém jsou intervaly v souladu se zpracováním zpráv z front ve službě Azure Service Bus.

Automatizované akce samoopravení

Dalším přístupem k samoopravení je použití automatizovaných akcí aktivovaných řešením monitorování 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 pomocí skriptu PowerShellu sestavit automatizaci a restartovat aplikační službu. V závislosti na sadě dovedností vašeho týmu a upřednostňovaných vývojových technologií použijte webhook nebo funkci k vytváření složitějších akcí automatizace. 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á různé charakteristiky 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í služby Azure Monitor můžete použít pro oznámení, jako jsou e-maily, hlas nebo SMS, a aktivovat automatizované akce. Když budete upozorněni na selhání, aktivujte runbook Azure Automation, Azure Event Hubs, funkci Azure, aplikaci logiky nebo webhook, který provede automatizovanou akci opravy.

Důležité informace

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

Příklad

Příklady použití některých vzorů najdete ve spolehlivém vzoru webové aplikace pro .NET. Pokud chcete nasadit referenční implementaci, postupujte podle těchto kroků.

Kontrolní seznam pro spolehlivost

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

Kontrolní seznam pro spolehlivost