Model Jistič

Zpracovává chyby, z nichž může zotavení při připojování ke vzdálené službě nebo prostředku trvat různě dlouho. 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, jako jsou pomalé síťová připojení, vypršení časového limitu nebo převyšující nebo dočasně nedostupné prostředky. Tyto chyby se obvykle po kratší době opraví samy a robustní cloudová aplikace by měla být připravena je zvládnout pomocí strategie, jako je model Opakování.

Můžou však nastat i situace, kdy jsou chyby způsobeny nepředvídatelnými událostmi a jejich oprava může trvat déle. Tyto chyby můžou být různě závažné, od částečného výpadku připojení až po úplné selhání služby. V těchto situacích může být pro aplikaci zbytečné opakovat operaci, která pravděpodobně nebude úspěšná, a místo toho by aplikace měla rychle přijmout, že operace selhala, a odpovídajícím způsobem tuto chybu zpracovat.

Kromě toho pokud je služba velmi zaneprázdněná, selhání v jedné části systému může vést k dalším selháním. Například operace, která vyvolá službu, může být nakonfigurována tak, aby implementovala časový limit, a odpovědět se zprávou o selhání, pokud služba během tohoto období nereaguje. Tato strategie ale může způsobit zablokování mnoha souběžných požadavků na stejnou operaci, dokud nevyprší časový limit. Tyto blokované žádosti můžou blokovat důležité systémové prostředky, jako paměť, vlákna, připojení k databázím atd. Tyto prostředky by se tedy mohly vyčerpat, což způsobí selhání jiných nesouvisejících částí systému, které potřebují používat stejné prostředky. V těchto situacích by bylo vhodnější, kdyby operace selhala okamžitě a pokusila se vyvolat službu pouze tehdy, když bude pravděpodobné, že uspěje. Nastavení kratšího časového limitu může pomoct tento problém vyřešit, ale časový limit by neměl být tak krátký, že operace většinu času selže, a to i v případě, že žádost o službu nakonec proběhne úspěšně.

Řešení

Model Jistič může bránit aplikaci v opakovaném pokusu o spuštění operace, která pravděpodobně selže. Umožní aplikaci pokračovat bez čekání na opravu chyby a bez plýtvání cykly procesoru při zjišťování, že se jedná o přetrvávající chybu. Model Jistič taky umožňuje zjistit, jestli byla chyba opravena. Pokud se problém jeví jako vyřešený, může aplikace zkusit vyvolat operaci.

Účel modelu Jistič se liší od modelu Opakování. Model Opakování umožňuje aplikaci opakovat operaci s předpokladem, že bude úspěšná. Model Jistič zabraňuje aplikaci provést operaci, 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 opakovaných pokusů by však měla brát ohled na výjimky vrácené jističem a pokud jistič signalizuje, že chyba není přechodná, neměla by provádět opakované pokusy.

Jistič funguje jako proxy pro operace, které můžou selhat. Proxy server by měl monitorovat počet nedávných selhání, ke kterým došlo, a pomocí těchto informací se rozhodnout, jestli má operace pokračovat, nebo okamžitě vrátit výjimku.

Proxy je možné implementovat jako stavový stroj s těmito stavy, které odpovídají funkci elektrického jističe:

• Uzavřený: Žádost z aplikace se směruje na operaci. Proxy zaznamenává počet nedávných chyb a pokud je volání operace neúspěšné, tento počet navýší. Pokud počet chyb za určité časové období překročí zadanou hodnotu, proxy přejde do stavu Otevřený. V tomto okamžiku proxy spustí časovač časového limitu a když tento časovač vyprší, proxy server se umístí do polootevření stavu.

  Účelem časovače časového limitu je dát systému čas k vyřešení problému, který způsobil selhání před povolením aplikace provést operaci znovu.

• Otevřený: Žádost z aplikace selže okamžitě a do aplikace se vrátí výjimka.

• Částečně otevřený: Od aplikace může projít a vyvolat operaci omezený počet žádostí. Pokud jsou tyto žádosti úspěšné, předpokládá se, že chyba způsobující selhání byla odstraněna a jistič přejde do stavu Uzavřený (čítač selhání se vynuluje). Pokud některý požadavek selže, jistič předpokládá, že chyba je stále k dispozici, takže se vrátí do stavu Open a restartuje časovač časového limitu, aby systém získal další časové období pro zotavení od selhání.

  Stav Částečně otevřený je užitečný v tom, že brání zahlcení obnovující se služby novými žádostmi. Během obnovování může služba zpracovat určité omezené množství žádostí, ale větší množství žádostí může způsobit, že jí znovu vyprší časový limit nebo selže.

Čítač selhání použitý ve stavu Uzavřený, který můžete vidět na obrázku, je časový. Vynuluje se automaticky v pravidelných intervalech. Tento návrh pomáhá zabránit jističe v vstupu otevřít stavu, pokud dojde k občasným selháním. Hodnota počtu selhání, která přepne jistič do stavu Otevřený, se dosáhne, pouze pokud dojde k určitému počtu selhání během daného časového intervalu. Čítač použitý ve stavu Částečně otevřený zaznamenává počet úspěšných pokusů o vyvolání operace. Jistič se vrátí do stavu Uzavřený po určitém počtu po sobě jdoucích úspěšných vyvolání operace. Pokud některé vyvolání selže, jistič hned přejde do stavu Otevřený. Čítač úspěšných pokusů se vynuluje, jakmile jistič přejde do stavu Částečně otevřený.

Způsob obnovení systému se řeší externě, například obnovením nebo restartováním komponenty, která selhala, nebo obnovením 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 pomoci udržovat dobu odezvy systému tím, že rychle odmítne žádost o operaci, která pravděpodobně selže, a nečeká na vypršení časového limitu operace nebo odpověď, která nikdy nepřijde. Pokud jistič vyvolá událost pokaždé, když změní stav, je možné pomocí těchto informací sledovat stav části systému chráněné jističem nebo upozornit správce v případě, že jistič přejde do stavu Otevřený.

Model je přizpůsobitelný a je možné ho upravit podle typu možného selhání. U jističe můžete například použít časovač delšího časového limitu. Jistič můžete nejdříve umístit do otevřít stavu a pak v případě, že se chyba nevyřešila, zvyšte časový limit na několik minut atd. V některých případech může být užitečné, aby stav Otevřený místo vrácení chyby a vyvolání výjimky vrátil výchozí hodnotu, která má smysl pro aplikaci.

Problémy a důležité informace

Když se budete rozhodovat, jak tento model implementovat, měli byste vzít v úvahu následující skutečnosti:

zpracování výjimek: Aplikace, která vyvolá operaci prostřednictvím jističe, musí být připravena na zpracování výjimek vyvolaných v případě nedostupnosti operace. Způsob zpracování výjimek bude záviset na aplikaci. Aplikace může například dočasně snížit svoji funkčnost, vyvolat alternativní operaci s cílem provést stejnou úlohu nebo získat stejná data, nebo nahlásit výjimku uživateli a požádat jej, aby operaci zkusil později znovu.

typy výjimek: Požadavek může selhat z mnoha důvodů, z nichž některé můžou znamenat vážnější typ selhání než jiné. Požadavek může například selhat, protože došlo k chybě vzdálené služby a obnovení bude trvat několik minut nebo kvůli vypršení časového limitu kvůli dočasnému přetížení služby. Jistič pravděpodobně bude moct prozkoumat typy výjimek, ke kterým došlo, a upravit svoji strategii podle jejich povahy. Může například vyžadovat větší počet výjimek vypršení časového limitu pro cestu jističe do stavu Otevřít v porovnání s počtem selhání kvůli tomu, že služba je zcela nedostupná.

monitorování: Jistič by měl poskytovat jasné pozorovatelnosti v neúspěšných i úspěšných požadavcích a umožnit provozním týmům 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í. Pokud například jistič zůstane ve stavu Otevřený delší dobu, může vyvolávat výjimky i v případě, že příčina selhání už byla odstraněna. Podobně může jistič kolísat a snižovat dobu odezvy aplikací, pokud se přepíná ze stavu Otevřený do stavu Částečně otevřený příliš rychle.

Neúspěšné operace testování: Ve stavu Otevřít místo použití časovače k určení, kdy se má přepnout na polootevření stavu, může jistič místo toho pravidelně testovat příkazem ping vzdálenou službu nebo prostředek a zjistit, jestli bude znovu dostupná. Toto pingnutí může mít podobu pokusu o vyvolání operace, která předtím selhala, nebo může využívat speciální operaci poskytnutou vzdálenou službou specificky pro testování stavu služby, jak popisuje článek o modelu Monitorování stavu pomocí koncových bodů.

Ruční přepsání: V systému, kde je doba obnovení neúspěšné operace extrémně proměnlivá, je užitečné poskytnout možnost ručního resetování, která správci umožňuje 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 operace chráněná jističem dočasně nedostupná.

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

Diferenciace prostředků: Při použití jednoho jističe pro jeden typ prostředku buďte opatrní, pokud může existovat více základních nezávislých poskytovatelů. Například v úložišti dat, které obsahuje víc horizontálních oddílů, může být jeden horizontální oddíl plně dostupný a jiný může mít dočasný problém. Pokud se odpovědi na chybu v těchto scénářích sloučí, aplikace se může pokusit o přístup do některých horizontálních oddílů i přes vysokou pravděpodobnost selhání, zatímco přístup do jiných horizontálních oddílů může být blokovaný, přestože by byl pravděpodobně úspěšný.

zrychleného přerušení okruhu: Někdy může odpověď na selhání obsahovat dostatek informací, aby jistič mohl okamžitě vyjet a zůstat na cestě po minimální dobu. Například odpověď na chybu ze sdíleného prostředku, který je přetížený, může signalizovat, že okamžité opakování se nedoporučuje, a že aplikace by pokus měla opakovat za několik minut.

nasazení ve více oblastech: Jistič může být navržena pro nasazení s jednou nebo více oblastmi. Druhou možnost je možné implementovat pomocí globálních nástrojů pro vyrovnávání zatížení nebo vlastních strategií způsobujících přerušení okruhu s podporou oblastí, které zajišťují řízené převzetí služeb při selhání, optimalizaci latence a dodržování právních předpisů.

Jističe sítě služby: Jističe lze implementovat v aplikační vrstvě nebo jako průřezovou abstraktní funkci. Například sítě služeb často podporují přerušení obvodu jako sajdkáru nebo jako samostatnou funkci beze změny kódu aplikace.

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

Nevhodné časové limity u externích služeb: Jistič nemusí být schopná plně chránit aplikace před operacemi, které selžou v externích službách nakonfigurovaných s delším časovým limitem. Pokud je časový limit příliš dlouhý, může být vlákno, na kterém běží jistič, zablokovaný delší dobu, než jistič indikuje, že operace selhala. Mezitím se mnoho dalších instancí aplikace taky může pokoušet vyvolat službu prostřednictvím jističe a zablokovat větší množství vláken, než všechna selžou.

Přizpůsobitelnost výpočetních: Jističe by měly počítat s různými výpočetními prostředími, od bezserverových až po kontejnerizované úlohy, kde faktory, jako jsou spuštění chladu a zpracování selhání škálovatelnosti. Adaptivní přístupy můžou dynamicky přizpůsobovat strategie na základě typu výpočetních prostředků a zajistit odolnost v heterogenních architekturách.

Kdy se má tento model použít

Použijte tento model:

• Chcete-li 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 s vysokou pravděpodobností selžou.
• Pokud chcete zvýšit odolnost více oblastí inteligentním směrováním provozu na základě signálů selhání v reálném čase.
• Pokud chcete chránit před pomalými závislostmi, pomáháte udržet krok s cíli na úrovni služeb (SLO) a vyhnout se snížení výkonu kvůli vysoce latenci služeb.
• Řešení občasných problémů s připojením a snížení počtu selhání požadavků v distribuovaných prostředích

Tento model se nedoporučuje:

• Ke zpracování přístupu k místním soukromým prostředkům v aplikaci, jako je například struktura dat v paměti. V tomto prostředí by použití jističe navýšilo režii v systému.
• Jako náhrada za zpracování výjimek v obchodní logice vašich aplikací.
• Pokud jsou dostatečné dobře známé algoritmy opakování a vaše závislosti jsou navržené tak, aby řešily mechanismy opakování. Implementace jističe v aplikaci v tomto případě může znamenat zbytečné složitosti systému.
• Při čekání na resetování jističe může docházet k nepřijatelným zpožděním.
• Pokud 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 (DLQ) pro ruční nebo odložené zpracování. Integrované mechanismy izolace selhání a opakování obvykle implementované v těchto návrzích jsou často dostatečné.
• Pokud se obnovení po selhání spravuje na úrovni infrastruktury nebo platformy, například s kontrolami stavu v globálních nástrojích pro vyrovnávání zatížení nebo sítích služeb, nemusí být jističe nutné.

Návrh úloh

Architekt by měl vyhodnotit způsob použití modelu Jistič v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Příklad:

Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.

Související prostředky

Při implementaci tohoto modelu můžou být relevantní také následující modely:

• Model spolehlivé webové aplikace ukazuje, jak u webových aplikací konvergovaných v cloudu použít model jističe.

• Model opakování. Popisuje, jak může aplikace řešit předpokládaná dočasná selhání při pokusu o připojení k prostředku služby nebo síťovému prostředku, a to transparentním opakováním operace, která původně selhala.

• Model monitorování koncových bodů stavu Jistič může otestovat stav služby tím, že odešle žádost do koncového bodu určeného službou. Služba by měla vrátit informaci o svém stavu.