Vzory návrhu cloudu, které podporují spolehlivost
Při návrhu architektur úloh byste měli používat oborové vzory, které řeší běžné výzvy. Vzory vám můžou pomoct s úmyslným kompromisem v rámci úloh a optimalizovat požadovaný výsledek. Můžou také pomoct zmírnit rizika vyplývající z konkrétních problémů, které můžou mít vliv na zabezpečení, výkon, náklady a provoz. Pokud se nezmírní, tato rizika nakonec způsobí problémy se spolehlivostí. Tyto vzory jsou založené na reálných zkušenostech, jsou navržené pro cloudové škálování a provozní modely a jsou ze své podstaty nezávislé na dodavatelích. Použití známých vzorů jako způsobu standardizace návrhu úloh je součástí efektivity provozu.
Mnoho vzorů návrhu přímo podporuje jeden nebo více pilířů architektury. Vzory návrhu, které podporují pilíř spolehlivosti, upřednostňují dostupnost úloh, zachování sebezáchovy, obnovení, integritu dat a zpracování a omezování poruch.
Vzory návrhu pro spolehlivost
Následující tabulka shrnuje vzory návrhu cloudu, které podporují cíle spolehlivosti.
| Vzor | Souhrn |
|---|---|
| Ambassador | Zapouzdřuje a spravuje síťovou komunikaci přesměrováním průřezových úkolů, které souvisejí se síťovou komunikací. Výsledné pomocné služby zahájí komunikaci jménem klienta. Tento zprostředkující bod poskytuje příležitost přidat vzorce spolehlivosti síťové komunikace, jako je opakování nebo ukládání do vyrovnávací paměti. |
| Backends for Frontends | Individualizuje vrstvu služby úlohy vytvořením samostatných služeb, které jsou výhradní pro konkrétní front-endové rozhraní. Kvůli tomuto oddělení nemusí selhání vrstvy služby, která podporuje jednoho klienta, ovlivnit dostupnost přístupu jiného klienta. Když zacházíte s různými klienty odlišně, můžete určit prioritu úsilí o spolehlivost na základě očekávaných vzorů přístupu klientů. |
| Bulkhead | Zavádí záměrnou a úplnou segmentaci mezi komponentami, aby se izoloval poloměr výbuchu při poruchách. Tato strategie izolace selhání se pokouší obsahovat chyby pouze na přepážce, u které dochází k problému, a zabránit tak dopadu na jiné přepážky. |
| Cache-Aside | Optimalizuje přístup k často čtenými datům zavedením mezipaměti, která se naplní na vyžádání. Mezipaměť se pak použije v následných požadavcích na stejná data. Ukládání do mezipaměti vytváří replikaci dat a omezenými způsoby se dá použít k zachování dostupnosti často používaných dat, pokud je úložiště dat původu dočasně nedostupné. Pokud navíc dojde k selhání mezipaměti, může se úloha vrátit do zdrojového úložiště dat. |
| Circuit Breaker | Zabraňuje průběžným požadavkům na nefunkční nebo nedostupnou závislost. Tím zabráníte přetížení chybující závislosti. Tento model můžete také použít k aktivaci řádného snížení zatížení. Jističe jsou často svázané s automatickým obnovením, aby poskytovaly sebezáchovy i samoopravení. |
| Kontrola deklarace identity | Odděluje data od toku zasílání zpráv a poskytuje způsob, jak samostatně načíst data související se zprávou. Sběrnice zpráv neposkytují stejnou spolehlivost a zotavení po havárii jako často ve vyhrazených úložištích dat, takže oddělení dat od zprávy může zajistit vyšší spolehlivost podkladových dat. Toto oddělení také umožňuje přístup k obnovení fronty zpráv po havárii. |
| Compensating Transaction | Poskytuje mechanismus pro zotavení z selhání vrácením účinků dříve použitých akcí. Tento model řeší poruchy v kritických cestách úloh pomocí kompenzačních akcí, které mohou zahrnovat procesy, jako je přímé vrácení změn dat, rozbíjející zámky transakcí nebo dokonce spuštění nativního systémového chování, aby se efekt zvrát. |
| Competing Consumers | Použije distribuované a souběžné zpracování k efektivnímu zpracování položek ve frontě. Tento model vytváří redundanci při zpracování front tím, že zachází se spotřebiteli jako s replikami, takže selhání instance nezabrání ostatním příjemcům ve zpracování zpráv fronty. |
| Event Sourcing | Považuje změny stavu za řadu událostí a zachycuje je v neměnném protokolu jen pro připojení. Tento model můžete použít, když je spolehlivá historie změn zásadní v komplexním obchodním procesu. Usnadňuje také obnovení stavu, pokud potřebujete obnovit úložiště stavu. |
| Federated Identity | Deleguje vztah důvěryhodnosti na zprostředkovatele identity, který je externí pro danou úlohu za účelem správy uživatelů a poskytování ověřování pro vaši aplikaci. Přesměrování správy a ověřování uživatelů přesouvá spolehlivost těchto komponent na zprostředkovatele identity, který má obvykle vysokou smlouvu SLA. Kromě toho během zotavení po havárii úlohy pravděpodobně není potřeba řešit ověřovací komponenty jako součást plánu obnovení úlohy. |
| Gateway Aggregation | Zjednodušuje interakci klienta s vašimi úlohami tím, že agreguje volání do několika back-endových služeb v jednom požadavku. Tato topologie umožňuje přesunout zpracování přechodných chyb z distribuované implementace mezi klienty na centralizovanou implementaci. |
| Gateway Offloading | Přesměruje zpracování požadavků na zařízení brány před předáním požadavku na back-endový uzel a po jeho předání do back-endového uzlu. Přesměrování této odpovědnosti na bránu snižuje složitost kódu aplikace na back-endových uzlech. V některých případech přesměrování zátěže zcela nahradí funkce spolehlivou funkcí poskytovanou platformou. |
| Gateway Routing | Směruje příchozí síťové požadavky do různých back-endových systémů na základě záměrů požadavků, obchodní logiky a dostupnosti back-endu. Směrování brány umožňuje směrovat provoz jenom do uzlů systému, které jsou v pořádku. |
| Geode | Nasadí systémy, které fungují v režimech dostupnosti aktivní-aktivní napříč několika zeměpisnými oblastmi. Tento model používá replikaci dat k podpoře ideálního připojení klienta k libovolné geografické instanci. Může pomoct úlohám odolat jednomu nebo několika oblastním výpadkům. |
| Health Endpoint Monitoring | Poskytuje způsob, jak monitorovat stav systému zveřejněním koncového bodu, který je speciálně navržený pro tento účel. Tento koncový bod můžete použít ke správě stavu úloh a k upozorňování a řídicímu panelu. Můžete ho také použít jako signál pro samoopravenou nápravu. |
| Index Table | Optimalizuje načítání dat v distribuovaných úložištích dat tím, že klientům umožňuje vyhledávat metadata tak, aby data bylo možné přímo načíst, takže není nutné provádět úplné prohledávání úložiště dat. Vzhledem k tomu, že klienti jsou prostřednictvím procesu vyhledávání nasměrování na svůj horizontální oddíl, oddíl nebo koncový bod, můžete tento model použít k usnadnění přístupu k převzetí služeb při selhání pro přístup k datům. |
| Leader Election | Vytvoří vedoucí instanci distribuované aplikace. Vedoucí koordinuje odpovědnosti, které souvisejí s dosažením cíle. Tento model spolehlivě přesměrovává práci ke zmírnění dopadu chybných funkcí uzlů. Implementuje také převzetí služeb při selhání prostřednictvím algoritmů pro konsensus, když vedoucí proces nefunguje správně. |
| Pipes and Filters | Složité zpracování dat rozdělí do řady nezávislých fází, abyste dosáhli konkrétního výsledku. Jediná odpovědnost každé fáze umožňuje zaměřit pozornost a vyhnout se rušivému zpracování dat. |
| Priority Queue | Zajišťuje zpracování a dokončení položek s vyšší prioritou před položkami s nižší prioritou. Oddělení položek na základě obchodní priority umožňuje zaměřit úsilí v oblasti spolehlivosti na nejdůležitější práci. |
| Vydavatel/odběratel | Oddělí komponenty architektury nahrazením přímé komunikace klient-služba nebo klient-služba za komunikaci prostřednictvím zprostředkujícího zprostředkovatele zpráv nebo sběrnice událostí. |
| Queue-Based Load Leveling | Řídí úroveň příchozích požadavků nebo úkolů tím, že je ukládá do vyrovnávací paměti ve frontě a procesor fronty je může zpracovávat řízeným tempem. Tento přístup může zajistit odolnost proti náhlým špičkám v poptávce tím, že oddělí příchod úkolů od jejich zpracování. Může také izolovat selhání při zpracování fronty, aby neovlivnily příjem. |
| Omezování rychlosti | Řídí rychlost požadavků klientů, aby se snížil počet chyb způsobených omezováním a nedocházelo k nevázaným scénářům opakování při chybě. Tato taktika chrání klienta tím, že uznává omezení a náklady na komunikaci se službou, když je služba navržená tak, aby se zabránilo dosažení určených limitů. Funguje tak, že řídí počet a/nebo velikost operací, které se do služby odesílají během určitého časového období. |
| Retry | Řeší selhání, která můžou být přechodná nebo přerušovaná, a to kontrolovaně opakovaným opakováním určitých operací. Zmírnění přechodných chyb v distribuovaném systému je klíčovou technikou pro zlepšení odolnosti úloh. |
| Distribuované transakce Saga | Koordinuje dlouhotrvající a potenciálně složité transakce tím, že rozdělí práci do sekvencí menších nezávislých transakcí. Každá transakce musí mít také kompenzační akce pro obrácení selhání při provádění a zachování integrity. Vzhledem k tomu, že monolitické transakce napříč více distribuovanými systémy jsou obvykle nemožné, poskytuje tento model konzistenci a spolehlivost implementací atomicity a kompenzace. |
| Scheduler Agent Supervisor | Efektivně distribuuje a redistribuuje úkoly v systému na základě faktorů, které jsou v systému pozorovatelné. Tento model používá metriky stavu k detekci selhání a přesměrování úloh na agenta, který je v pořádku, aby se zmírnily důsledky selhání. |
| Sequential Convoy | Udržuje souběžné příchozí přenosy zpráv a zároveň podporuje zpracování v definovaném pořadí. Tento model může eliminovat konflikty časování, které je obtížné vyřešit, zpracování sporných zpráv nebo jiná alternativní řešení pro adresování nesprávně seřazených zpráv, které můžou vést k selhání. |
| Sharding | Směruje zatížení do konkrétního logického cíle pro zpracování konkrétního požadavku a umožňuje optimalizaci kolokace. Vzhledem k tomu, že data nebo zpracování jsou izolované na horizontálním oddílu, zůstane chyba v jednom horizontálním oddílu izolovaná v daném horizontálním oddílu. |
| Strangler Fig | Poskytuje přístup k systematickému nahrazování komponent spuštěného systému novými komponentami, často během migrace nebo modernizace systému. Přírůstkový přístup tohoto modelu může pomoct zmírnit rizika během přechodu. |
| Omezování | Omezuje rychlost nebo propustnost příchozích požadavků na prostředek nebo komponentu. Omezení můžete navrhnout tak, aby se zabránilo vyčerpání prostředků, které by mohlo vést k selháním. Tento model můžete také použít jako řídicí mechanismus v elegantním plánu degradace. |
Další kroky
Projděte si vzory návrhu cloudu, které podporují další pilíře architektury Azure Well-Architected: