Vzor Jističe

Vzor Jistič pomáhá zvládat chyby, které mohou trvat různou dobu, než se odstraní, když se aplikace připojí ke vzdálené službě nebo prostředku. Jistič dočasně blokuje přístup k vadné službě po zjištění selhání. Tato akce zabraňuje opakovaným neúspěšných pokusům, aby se systém mohl efektivně obnovit. Tento model může zlepšit stabilitu a odolnost aplikace.

Kontext a problém

V distribuovaném prostředí můžou volání vzdálených prostředků a služeb selhat kvůli přechodným chybám. Mezi přechodné chyby patří přetížené nebo dočasně nedostupné prostředky, pomalé síťové připojení nebo vypršení časového limitu. Tyto chyby se obvykle opravují po krátké době. Pokud chcete tyto chyby spravovat, měli byste navrhnout cloudovou aplikaci tak, aby používala strategii, jako je vzor opakování.

Neočekávané události můžou způsobit chyby, které oprava trvá déle. Tyto chyby můžou být v rozsahu závažnosti od částečné ztráty připojení k úplnému selhání služby. V těchto situacích by aplikace neměla neustále opakovat operaci, která by pravděpodobně nebyla úspěšná. Místo toho by aplikace měla rychle rozpoznat neúspěšnou operaci a odpovídajícím způsobem zpracovat selhání.

Pokud je služba zaneprázdněná, selhání v jedné části systému může vést k kaskádovým selháním. Můžete například nakonfigurovat operaci, která vyvolá službu, aby implementovaly časový limit. Pokud služba během tohoto období neodpoví, operace odpoví zprávou o selhání.

Tato strategie ale může blokovat souběžné požadavky na stejnou operaci, dokud nevyprší časový limit. Tyto blokované požadavky můžou obsahovat důležité systémové prostředky, jako jsou paměť, vlákna a připojení k databázi. Tento problém může vyčerpat prostředky, což může způsobit selhání jiných nesouvisejících částí systému, které potřebují použít stejné prostředky.

V těchto situacích by operace měla selhat okamžitě a pokusit se službu vyvolat pouze v případě, že bude pravděpodobně úspěšná. Pokud chcete tento problém vyřešit, nastavte kratší časový limit. Ujistěte se ale, že časový limit je dostatečně dlouhý, aby operace většinu času uspěla.

Řešení

Model Obsluhy Neočekávaných Chyb (Circuit Breaker) pomáhá zabránit aplikaci v opakovaných pokusech o spuštění operace, která s vysokou pravděpodobností selže. Tento vzorec umožňuje aplikaci pokračovat v běhu, aniž by čekala na odstranění chyby nebo plýtvala cykly procesoru při zjišťování, zda je chyba trvalá. Vzor Jističe také umožňuje aplikaci zjistit, kdy je chyba vyřešena. Pokud je chyba vyřešena, aplikace se může pokusit operaci vyvolat znovu.

Poznámka:

Model Jistič slouží k jinému účelu než model Opakování. Model opakování umožňuje aplikaci opakovat operaci s očekáváním, že nakonec proběhne úspěšně. Model Jistič brání aplikaci v provádění operace, která pravděpodobně selže. Aplikace může tyto dva modely zkombinovat a pomocí modelu Opakování vyvolat operaci prostřednictvím jističe. Logika opakování by ale měla být citlivá na všechny výjimky, které jistič vrátí, a zastavit pokusy o opakování, pokud jistič indikuje, že chyba není přechodná.

Jistič funguje jako proxy pro operace, které můžou selhat. Proxy server by měl monitorovat počet nedávných selhání a použít tyto informace k rozhodnutí, jestli má operace pokračovat, nebo vrátit výjimku okamžitě.

Proxy server můžete implementovat jako stavový počítač, který obsahuje následující stavy. Tyto stavy napodobují funkčnost elektrického jističe:

• Uzavřeno: Požadavek z aplikace je směrován do operačního procesu. Proxy server udržuje počet nedávných selhání. Pokud volání operace není úspěšné, proxy zvýší tento počet. Pokud počet nedávných selhání překročí zadanou prahovou hodnotu v daném časovém období, proxy server se umístí do stavu Otevřít a spustí časovač časového limitu. Po vypršení platnosti časovače se proxy server umístí do stavu polootevřený.

  Poznámka:

  Během časového limitu se systém pokusí vyřešit problém, který způsobil selhání předtím, než aplikaci umožní pokus o operaci znovu.

• Otevřeno: Požadavek z aplikace selže okamžitě a aplikace obdrží výjimku.

• Polootevření: Omezený počet požadavků z aplikace může projít a vyvolat operaci. Pokud jsou tyto požadavky úspěšné, jistič předpokládá, že chyba, která způsobila selhání, je opravena a jistič se přepne do stavu Uzavřeno. Čítač selhání se resetuje. Pokud některý požadavek selže, jistič předpokládá, že chyba stále existuje, takže se vrátí do stavu Otevřít. Restartuje časovač časového limitu, aby se systém mohl zotavit ze selhání.

  Poznámka:

  Polootevřený stav pomáhá zabránit náhlému zahlcení žádostmi služby, která se zotavuje. Když se služba obnoví, může být schopná podporovat omezený objem požadavků, dokud nebude obnovení dokončeno. Během probíhajícího obnovení však může příval práce způsobit překročení časového limitu služby nebo její opětovné selhání.

Následující diagram znázorňuje operace čítače pro každý stav.

Diagram znázorňuje tři části označené jako zavřené, polootevřené a otevřené. Uzavřený stav zahrnuje akci pro resetování čítače selhání. Pokud operace proběhne úspěšně, vrátí výsledek, jinak se počítadlo neúspěchů zvýší a vrátí chybu. Polootevřený stav obsahuje akci pro resetování čítače úspěchů. Pokud operace proběhne úspěšně, čítač úspěchu přírůstku vrátí výsledek, jinak vrátí chybu. Otevřený stav zahrnuje akce pro spuštění časovače času vypršení a signalizaci selhání. Šipka z uzavřeného do otevřeného stavu značí, že je dosažena prahová hodnota selhání. Šipka od otevřeného do polootevřeného stavu označuje, že vypršel časový limit. Šipka z napůl otevřeného do uzavřeného stavu naznačuje dosažení prahu počtu úspěchů. Ukazatel přechodu z polootevřeného do otevřeného stavu naznačuje, že operace selhala.

Čítač selhání pro stav Uzavřeno je časově řízený. Automaticky se resetuje v pravidelných intervalech. Tento návrh pomáhá zabránit jističi ve vstupu do Otevřeného stavu v případě občasných selhání. Prahová hodnota selhání aktivuje stav Open pouze v případě, že během zadaného intervalu dojde k zadanému počtu selhání.

Čítač úspěchu pro polootevřený stav zaznamenává počet úspěšných pokusů o vyvolání operace. Jistič se vrátí do stavu Uzavřená po zadaném počtu úspěšných volání po sobě jdoucích operací. Pokud jakékoli vyvolání selže, jistič okamžitě přejde do stavu Otevřený a čítač úspěchů se resetuje při příštím přechodu do stavu Polootevřený.

Poznámka:

Obnovení systému je založené na externích operacích, jako je obnovení nebo restartování součásti, která selhala nebo oprava síťového připojení.

Model Jistič poskytuje stabilitu, zatímco se systém obnovuje po chybě, a minimalizuje dopad na výkon. Může pomoct udržovat dobu odezvy systému. Tento model rychle odmítne požadavek na operaci, která pravděpodobně selže, místo aby čekal na vypršení časového limitu operace nebo nikdy nezareagoval. Pokud jistič vyvolá událost pokaždé, když změní stav, můžou tyto informace pomoct monitorovat stav chráněné systémové komponenty nebo upozornit správce, když jistič přepne do stavu Otevřít.

Tento vzor můžete upravit a přizpůsobit různým typům selhání. Například můžete na jistič použít časovač se zvyšujícím se časovým limitem. Můžete umístit jistič do stavu otevřít na několik sekund nejprve. Pokud se chyba nevyřeší, zvyšte časový limit na několik minut a odpovídajícím způsobem upravte. V některých případech může místo vrácení chyby a vyvolání výjimky vrátit stav Open výchozí hodnotu, která je pro aplikaci smysluplná.

Poznámka:

Tradičně jističe závisely na předem nakonfigurovaných prahových hodnotách, jako je počet selhání a doba trvání časového limitu. Výsledkem tohoto přístupu je deterministické, ale někdy neoptimální chování.

Adaptivní techniky, které používají AI a strojové učení, můžou dynamicky upravovat prahové hodnoty na základě vzorů provozu v reálném čase, anomálií a historických poruch. Tento přístup zlepšuje odolnost a efektivitu.

Problémy a důležité informace

Při implementaci tohoto modelu zvažte následující faktory:

• Zpracování výjimek: Aplikace, která vyvolá operaci prostřednictvím jističe, musí být schopná zpracovat výjimky, pokud je operace nedostupná. Správa výjimek je založená na aplikaci. Aplikace může například dočasně snížit jeho funkčnost, vyvolat alternativní operaci, která se pokusí provést stejnou úlohu nebo získat stejná data, nebo nahlásit výjimku uživateli a požádat ho, aby to zkusil později.

• Typy výjimek: Důvody selhání požadavku se mohou lišit v závažnosti. Požadavek může například selhat, protože vzdálená služba se chybově ukončí a vyžaduje několik minut k obnovení nebo kvůli tomu, že přetížená služba způsobí vypršení časového limitu. Jistič může být schopen prozkoumat typy výjimek, ke kterým dochází, a upravit jeho strategii na základě povahy těchto výjimek. Může například vyžadovat větší počet výjimek časového limitu pro přepnutí jističe do stavu Open ve srovnání s počtem selhání způsobených nedostupnou službou.

• Monitorování: jistič by měl poskytovat jasnou pozorovatelnost jak neúspěšných, tak úspěšných požadavků, aby provozní týmy mohly posoudit stav systému. Distribuované trasování slouží k komplexní viditelnosti napříč službami.

• Obnovitelnost: Jistič byste měli nakonfigurovat tak, aby odpovídal pravděpodobnému vzoru obnovení operace, kterou chrání. Například pokud jistič zůstane ve stavu Otevřít po dlouhou dobu, může vyvolat výjimky i v případě, že je důvod selhání vyřešen. Podobně jistič může kolísat a snižovat dobu odezvy aplikací, pokud přepne ze stavu Open do stavu Half-Open příliš rychle.

• Neúspěšné provozní testování: Ve stavu Otevřeno může jistič místo použití časovače k určení, kdy se má přepnout do Polootevřeného stavu, pravidelně odesílat ping vzdálené službě nebo prostředku, aby zjistil, zda je k dispozici. Tento příkaz ping se může pokusit vyvolat dříve neúspěšnou operaci nebo použít speciální operaci kontroly stavu, kterou vzdálená služba poskytuje. Další informace najdete ve vzorci monitorování koncových bodů pro sledování zdraví .

• Ruční ovládání: Pokud je doba obnovení neúspěšné operace extrémně proměnlivá, měli byste poskytnout možnost ručního resetování, která umožní správci zavřít jistič a resetovat čítač selhání. Správce může podobně vynutit jistič do stavu Otevřít a restartovat časovač časového limitu, pokud je chráněná operace dočasně nedostupná.

• Souběžnost: Velký počet souběžných instancí aplikace má přístup ke stejnému jističe. Implementace by neměla blokovat souběžné žádosti nebo přidávat nadměrnou režii ke každému volání operace.

• Rozlišení prostředků: Buďte opatrní při použití jednoho jističe pro jeden typ prostředku, pokud může existovat více základních nezávislých poskytovatelů. Například v úložišti dat, které obsahuje více horizontálních oddílů, může být jeden horizontální oddíl plně přístupný, zatímco u jiného dochází k dočasnému problému. Pokud jsou reakce na chyby v těchto scénářích sloučené, může se aplikace pokusit přistupovat k některým shardům, i když je selhání pravděpodobné. Přístup k jiným shardům může být zablokován, přestože může být úspěšný.

• akcelerované vypínání obvodu: Někdy může odpověď na selhání obsahovat dostatek informací, aby jistič mohl okamžitě vypnout a zůstat vypnutý po minimální dobu. Například chybová odpověď ze sdíleného prostředku, který je přetížený, může naznačovat, že by se aplikace měla pokusit znovu za několik minut místo okamžitého opakování.

• nasazení ve více oblastech: Můžete navrhnout jistič pro nasazení v jedné oblasti nebo ve více oblastech. Pokud chcete navrhovat nasazení ve více oblastech, použijte globální vyrovnávače zatížení nebo vlastní strategie přerušení okruhu podle konkrétních oblastí, které pomáhají zajistit řízené převzetí služeb při selhání, optimalizaci latence a dodržování právních předpisů.

• Jističe pro síťovou službu: Můžete implementovat jističe v aplikační vrstvě nebo jako průřezovou, abstraktní funkci. Například služební sítě často podporují řízení přetížení jako sidecar nebo jako samostatnou funkci bez úprav samotného aplikačního kódu.

  Poznámka:

  Služba může vrátit protokol HTTP 429 (příliš mnoho požadavků), pokud se jedná o omezování klienta nebo HTTP 503 (služba není k dispozici), pokud služba není dostupná. Odpověď může obsahovat další informace, například očekávanou dobu trvání zpoždění.

• Opakování neúspěšných požadavků: Ve stavu Otevřený může jistič místo rychlého selhání zaznamenávat podrobnosti o jednotlivých požadavcích do deníku a zajistit, aby se tyto žádosti přehrály znovu, když bude vzdálený prostředek nebo služba k dispozici.

• Nesprávné časové prodlevy u externích služeb: Jistič nemusí plně chránit aplikace před selháními v externích službách s dlouhými prodlevami. Pokud je časový limit příliš dlouhý, může být vlákno, na kterém běží jistič, zablokované po delší dobu, než jistič indikuje, že operace selhala. Během této doby se mnoho dalších instancí aplikace může také pokusit vyvolat službu prostřednictvím jističe a svázat mnoho vláken předtím, než všechny selžou.

• Přizpůsobivost na výpočetní rozmanitost: Jističe by měly odpovídat různým výpočetním prostředím, od bezserverových až po kontejnerizované úlohy, kde studené starty a škálovatelnost ovlivňují řešení selhání. Adaptivní přístupy můžou dynamicky upravovat strategie na základě typu výpočetních prostředků, což pomáhá zajistit odolnost napříč heterogenními architekturami.

Kdy použít tento vzor

Tento model použijte v těchto případech:

• Chcete zabránit kaskádovým selháním zastavením nadměrných volání vzdálených služeb nebo žádostí o přístup ke sdílenému prostředku, pokud tyto operace pravděpodobně selžou.

• Chcete inteligentně směrovat provoz na základě signálů selhání v reálném čase, aby se zlepšila odolnost víceregionů.

• Chcete chránit před pomalými závislostmi, abyste mohli zachovat cíle na úrovni služby a vyhnout se snížení výkonu služeb s vysokou latencí.

• Chcete spravovat přerušované problémy s připojením a omezit selhání požadavků v distribuovaných prostředích.

Tento vzor nemusí být vhodný v těchto případech:

• Potřebujete spravovat přístup k místním privátním prostředkům v aplikaci, jako jsou datové struktury v paměti. V tomto prostředí jistič přidává vašemu systému dodatečné zatížení.

• Musíte ji použít jako náhradu za zpracování výjimek v obchodní logice vašich aplikací.

• Dobře známé algoritmy opakování jsou dostatečné a vaše závislosti jsou navržené tak, aby zpracovávaly mechanismy opakování. V tomto scénáři může jistič ve vaší aplikaci přidat zbytečné složitosti systému.

• Čekání na resetování jističe může představovat nepřijatelné zpoždění.

• Máte architekturu řízenou zprávami nebo řízenou událostmi, protože často směrují neúspěšné zprávy do fronty nedoručených zpráv pro ruční nebo odložené zpracování. Integrované mechanismy izolace selhání a opakování jsou často dostatečné.

• Obnovení po selhání se spravuje na úrovni infrastruktury nebo platformy, jako jsou kontroly stavu v globálních nástrojích pro vyrovnávání zatížení nebo sítích služeb.

Návrh úloh

Vyhodnoťte, jak používat model Jistič v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Následující tabulka obsahuje pokyny, jak tento model podporuje cíle jednotlivých pilířů.

Pilíř	Jak tento model podporuje cíle pilíře
Spolehlivostní rozhodnutí o návrhu pomáhají vaší pracovní zátěži stát se odolná proti poruchám a zajistit, aby se po selhání obnovila do plně funkčního stavu.	Tento model pomáhá zabránit přetížení chybné závislosti. Tento vzorec použijte ke spuštění postupného snížení výkonu zatížení. Spojte jističe s automatickým obnovením pro zajištění samoochrany a samouzdravování. - RE:03 Analýza režimu selhání - přechodných chyb - RE:07 Sebezáchování
efektivita výkonu pomáhá vašim úlohám efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu.	Tento model zabraňuje přístupu s opětovným pokusem při chybě, což může vést k nadměrnému využití prostředků během obnovení závislostí a může přetížit kapacitu závislosti, která se pokouší o obnovení. - PE:07 Kód a infrastruktura - PE:11 Odpovědi na aktuální problémy

Pokud tento model představuje kompromisy v rámci pilíře, zvažte je proti cílům ostatních pilířů.

Příklad

Tento příklad implementuje model Jistič, který pomáhá zabránit přetečení kvóty pomocí úrovně Free životnosti služby Azure Cosmos DB. Tato úroveň je primárně určená pro nekritická data a funguje v rámci plánu kapacity, který přiděluje konkrétní kvótu jednotek prostředků za sekundu. Během sezónních akcí může poptávka překročit poskytnutou kapacitu, což může vést k odpovědím 429.

Když dojde ke špičkám poptávky, upozornění služby Azure Monitor s dynamickými prahovými hodnotami detekují a proaktivně informují provozní týmy a týmy správy, že databáze vyžaduje větší kapacitu. Současně dojde k vypnutí jističe, který je vyladěný pomocí historických vzorců chyb, aby se zabránilo kaskádovým selháním. V tomto stavu aplikace elegantně degraduje vrácením výchozích odpovědí nebo odpovědí uložených v mezipaměti. Aplikace informuje uživatele o dočasné nedostupnosti určitých dat při zachování celkové stability systému.

Tato strategie zvyšuje odolnost, která je v souladu s obchodním odůvodněním. Řídí nárůst kapacity, aby týmy úloh mohly spravovat zvýšení nákladů záměrně a udržovat kvalitu služeb bez neočekávaného zvýšení provozních nákladů. Po potvrzení poptávky nebo zvýšení kapacity se jistič resetuje a aplikace se vrátí do plné funkčnosti, která odpovídá technickým i rozpočtovým cílům.

Diagram má tři primární části. První část obsahuje dvě ikony webového prohlížeče. První ikona zobrazuje plně funkční uživatelské rozhraní a druhá ikona zobrazuje degradované uživatelské prostředí s upozorněním na obrazovce, které značí problém uživatelům. Druhá sekce je uzavřena do obdélníku s přerušovanou čarou, který je rozdělen do dvou skupin. Hlavní skupina zahrnuje prostředky úloh, Službu App Service a Azure Cosmos DB. Šipky z obou ikon webového prohlížeče odkazují na instanci služby App Service, které představují příchozí požadavky z klienta. Kromě toho šipky z instance služby App Service odkazují na Službu Azure Cosmos DB, které označují interakce dat mezi aplikačními službami a databází. Další šipková smyčka z instance služby App Service se vrátí k sobě a symbolizuje mechanismus vypršení časového limitu jističe. Tato smyčka značí, že když se zjistí odpověď 429 Příliš mnoho požadavků, systém se vrátí k poskytování odpovědí uložených v mezipaměti, čímž zhoršuje uživatelský zážitek, dokud se situace nevyřeší. Dolní skupina této části se zaměřuje na pozorovatelnost a upozorňování. Azure Monitor shromažďuje data z prostředků Azure v horní skupině. Azure Monitor se také připojí k ikoně pravidla upozornění. Třetí část ukazuje pracovní postup škálovatelnosti, který se aktivuje při vyvolání výstrahy. Šipka připojí ikonu upozornění ke schvalovatelům, což značí, že se jim oznámení odešle ke kontrole. Další šipka vede ze schvalovatelů k vývojové konzole, která označuje proces schvalování pro škálování databáze. Další šipka se nakonec rozšíří z vývojové konzoly do služby Azure Cosmos DB, která znázorňuje akci škálování databáze v reakci na podmínku přetížení.

Stáhněte si soubor Visio této architektury.

Tok A: Uzavřený stav

• Systém funguje normálně a všechny požadavky se dostanou do databáze bez vrácení jakýchkoli 429 odpovědí HTTP.

• Jistič zůstane zavřený a nejsou potřeba žádné výchozí odpovědi ani odpovědi uložené v mezipaměti.

Flow B: Otevřený stav

1. Když jistič obdrží první 429 odpověď, přejde do stavu Otevřít.

2. Následné požadavky jsou okamžitě zkráceny, což vrací výchozí odpovědi nebo odpovědi uložené v mezipaměti a informuje uživatele o dočasném snížení výkonu. Aplikace je chráněna před dalším přetížením.

3. Azure Monitor přijímá protokoly a telemetrická data a vyhodnocuje je proti dynamickým prahovým hodnotám. Výstraha se aktivuje, pokud jsou splněny podmínky pravidla upozornění.

4. Skupina akcí proaktivně upozorní provozní tým na stav přetížení.

5. Po schválení týmu pracovního zatížení může provozní tým zvýšit nastavenou propustnost, aby zmírnil přetížení nebo oddálil škálování, pokud zatížení přirozeně klesne.

Flow C: Half-Open stav

1. Po uplynutí předdefinovaného časového limitu jistič přechází do polootevřeného stavu, který umožňuje omezený počet zkušebních požadavků.

2. Pokud tyto žádosti o zkušební provoz proběhnou úspěšně bez vrácení odpovědí 429, resetuje se jistič do stavu Uzavřeno a normální provoz je obnoven na Flow A. Pokud selhání přetrvávají, jistič se vrátí do stavu Otevřeno nebo Flow B.

Součásti

• Azure App Service hostuje webovou aplikaci, která slouží jako primární vstupní bod pro požadavky klientů. Kód aplikace implementuje logiku, která vynucuje zásady jističe, a pokud je okruh otevřen, poskytuje výchozí nebo uložené odpovědi z mezipaměti. Tato architektura pomáhá zabránit přetížení podřízených systémů a udržovat uživatelské prostředí během poptávky ve špičce nebo selhání.

• azure Cosmos DB je jedním z úložišť dat aplikace. Obsluhuje nekritická data prostřednictvím úrovně Free, která je ideální pro malé produkční úlohy. Mechanismus jističe pomáhá omezit provoz do databáze během období vysoké poptávky.

• azure Monitor funguje jako centralizované řešení monitorování. Agreguje všechny protokoly aktivit, aby pomohlo zajistit kompletní end-to-end sledovatelnost. Azure Monitor přijímá protokoly a telemetrická data ze služby App Service a klíčových metrik ze služby Azure Cosmos DB (jako je počet odpovědí 429) pro agregaci a analýzu.

• Upozornění služby Azure Monitor porovnávají pravidla upozornění s dynamickými prahovými hodnotami za účelem identifikace potenciálních výpadků na základě historických dat. Předdefinovaná upozornění upozorňují provozní tým, když dojde k porušení prahových hodnot.

  Někdy může tým úloh schválit zvýšení zřízené propustnosti, ale provozní tým předpokládá, že se systém může sám zotavit, protože zatížení není příliš vysoké. V těchto případech vyprší časový limit jističe přirozeně. Během této doby pokud přestanou přicházet odpovědi 429, výpočet prahové hodnoty detekuje prodloužené výpadky a vyloučí je z algoritmu učení. V důsledku toho při příštím přetížení prahová hodnota čeká na vyšší chybovost ve službě Azure Cosmos DB, která zpožďuje oznámení. Tato úprava umožňuje jističe vyřešit problém bez okamžité výstrahy, což zlepšuje nákladovou a provozní efektivitu.

Související prostředky

• Model Reliable Web App aplikuje model Jistič na webové aplikace, které konvergují v cloudu.

• Vzor opakování popisuje, jak může aplikace zpracovat očekávané dočasné selhání při pokusu o připojení ke službě nebo síťovému prostředku transparentním opakováním operace, která dříve selhala.

• Model monitorování koncových bodů stavu popisuje, jak může jistič otestovat stav služby odesláním požadavku do koncového bodu, který služba zveřejňuje. Služba by měla vrátit informace, které označují její stav.