Sdílet prostřednictvím

Strategie architektury pro samoopravení a sebezáchování

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

RE:07 Posílení odolnosti vašich úloh implementací samozásobních a samoopravených opatření. Používejte integrované funkce a dobře zavedené cloudové vzory, které vaší úloze pomůžou zůstat funkční během incidentů a zotavit se z incidentů.

Tato příručka popisuje doporučení pro vytváření možností samoobslužného zachování a samoopravení v architektuře aplikací 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í, aby vaše úloha fungovala normálně nebo v degradované situaci, když dojde k selháním. 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 selhání.

Definice

Term Definition
Samoopravení 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.

Návrh pro redundanci

Jednou z nejúčinnějších strategií ochrany úloh před poruchami je zabudování redundance do všech jejích komponent a zabránění kritickým prvkům způsobujícím selhání. Schopnost selhat komponenty nebo celou úlohu na redundantní prostředky poskytuje efektivní způsob, jak zvládnout většinu chyb ve vašem systému.

Zabudujte redundanci na různých úrovních, zvažte redundantní komponenty infrastruktury, jako jsou výpočetní prostředky, síť a úložiště, a zvažte nasazení několika instancí vašeho řešení. V závislosti na vašich obchodních požadavcích můžete vytvořit redundanci v rámci jedné oblasti nebo napříč oblastmi. Můžete se také rozhodnout, jestli potřebujete návrh aktivní-aktivní nebo aktivní-pasivní, aby splňoval vaše požadavky na obnovení. Další informace najdete v tématu Strategie architektury pro navrhování pro redundanci a strategie architektury pro použití zón dostupnosti a oblastí.

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, že návrh aplikací je konzistentní a zjednodušený, což zvyšuje spolehlivost úloh a usnadňuje řešení potíží 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.

Používejte osvědčené vzory, které vám pomůžou s vývojem standardů návrhu a zjednodušením aspektů architektury. Vzory návrhu, které pomáhají podporovat spolehlivost, najdete v článku Vzory spolehlivosti .

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 automatický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 k návrhu aplikací

Kromě použití vzorů návrhu , které podporují spolehlivost, zahrnují i další strategie, které vám můžou pomoct s vývojem mechanismů samoopravení:

  • 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.

  • Implementace automatizovaných akcí samoopravení: Při zjištění předem určených změn stavu použijte automatizované akce aktivované řešením monitorování.

    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.

    Používejte samoopravené vzory a funkce specifické pro danou technologii. Například místo toho, aby byla poškozená zpráva ve frontě opakovaně zpracovávána a mohla tak blokovat budoucí zpracování zpráv, navrhněte řešení, jako je použití fronty nedoručených zpráv. Automatizujete přesouvání problematických zpráv do fronty, ale zpracování položek je obvykle ruční vyhodnocení, po kterém následuje krok nápravy specifický pro konkrétní scénář.

Implementace režimu řádného snížení výkonu

Navzdory vlastnímu zachování a samoopravení mechanismů můžete stále narazit na situace, kdy jedna nebo více komponent nefunguje v rozsahu, kdy se po určitou dobu stanou nedostupnými. V ideálním případě může vaše úloha udržovat dostatek funkcí pro firmy, aby pokračovala ve sníženém stavu. Pokud chcete zajistit, aby to bylo možné, navrhujte a implementujte režim elegantního snížení výkonu. Jedná se o jedinečný pracovní postup, který je povolen v reakci na neúspěšné součásti. Mezi aspekty návrhu a implementace patří:

  • Detekce selhání a automatizované inicializace: Systémy monitorování a upozorňování by měly detekovat degradované a neúspěšné komponenty, takže tyto signály použijte k vytvoření pracovního postupu, který určuje, kdy je potřeba přepnout do režimu řádného snížení výkonu. Pracovní postup by pak měl automaticky přesměrovat volání do a z ovlivněných komponent na alternativní komponenty nebo jiné podobné akce.
  • Implementace degradovaného uživatelského prostředí: Zahrňte do režimu odkladu mechanismus oznámení pro uživatele, aby měli jistotu, že vědí, jaké funkce zůstávají a co se změnilo. Obvykle se to odráží ve zprávách svázaných s různými funkcemi úlohy, například automaticky otevírané okno při přidávání položek do košíku.
  • Vytvářejte alternativní cesty pro dokončení základních funkcí vaší úlohy: Zamyslete se nad kritickými toky vaší úlohy a určete, jak tyto toky udržovat, když jsou základní komponenty nedostupné. Pokud je například databáze mimo provoz, může aplikace přepnout do režimu jen pro čtení pomocí dat uložených v mezipaměti. Pokud je platební brána mimo provoz, může použití dat uložených v mezipaměti uživatelům umožnit uložit košík a nákup dokončit později.

Implementace mechanismů pro zpracování přechodných chyb

Přechodné chyby, jako jsou vypršení časového limitu sítě, jsou běžným problémem cloudových úloh, takže jejich zpracování může minimalizovat výpadky a řešení potíží při provozu úloh v produkčním prostředí. Vzhledem k tomu, že většina operací, které selžou kvůli přechodné chybě, bude úspěšná, pokud je před opakováním operace povolena dostatečná doba, je použití mechanismu opakování nejběžnějším přístupem pro zpracování přechodných chyb. Při navrhování strategie opakování zvažte následující:

Úplný přehled doporučení a aspektů najdete v průvodci návrhem přechodných chyb .

Implementace úloh 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ů

Podrobné pokyny k úplnému posouzení doporučení a aspektů najdete v průvodci návrhem úloh na pozadí .

Usnadnění na platformě Azure

Většina služeb Azure a klientských sad SDK zahrnuje mechanismus opakování. 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.

Example

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

  • Last updated on