Vzory odolnosti aplikací

Návod

Tento obsah je výňatek z elektronické knihy Architektura cloud-native .NET aplikací pro Azure, která je k dispozici na .NET Docs nebo jako bezplatné PDF ke stažení, které si můžete přečíst offline.

Stáhnout PDF

První linie obrany je odolnost aplikací.

I když byste mohli investovat značnou dobu psaní vlastní architektury odolnosti, takové produkty již existují. Polly je komplexní knihovna .NET pro zpracování přechodných chyb a podporu resilienčních mechanismů, která umožňuje vývojářům vyjádřit resilienční politiky plynulým a bezpečným způsobem pro práci s vlákny. Polly cílí na aplikace vytvořené pomocí rozhraní .NET Framework nebo .NET 7. Následující tabulka popisuje funkce odolnosti, označované jako policies, které jsou k dispozici v knihovně Polly. Dají se použít jednotlivě nebo seskupit.

Politika	Zkušenost
Zkusit znovu	Konfiguruje operace opakování u určených operací.
Jistič	Blokuje požadované operace pro předdefinované období, když chyby překročí nakonfigurovanou prahovou hodnotu.
Přerušení zápasu	Nastaví omezení doby trvání, po kterou může volající čekat na odpověď.
Přepážka	Omezuje akce na fond zdrojů s pevnou velikostí, aby se zabránilo neúspěšným voláním v zahlcování prostředku.
Mezipaměť	Ukládá odpovědi automaticky.
Náhradní téma	Definuje strukturované chování při selhání.

Všimněte si, jak na předchozím obrázku platí zásady odolnosti pro žádosti o zprávy bez ohledu na to, jestli pocházejí z externího klienta nebo back-endové služby. Cílem je kompenzovat žádost o službu, která může být momentálně nedostupná. Tato krátkodobá přerušení se obvykle projevuje stavovými kódy HTTP zobrazenými v následující tabulce.

Stavový kód HTTP	Příčina
404	Nenalezeno
408	Časový limit požadavku vypršel
429	Příliš mnoho požadavků (pravděpodobně jste byli omezeni)
502	Chybná brána
503	Nedostupná služba
504	Časový limit brány

Otázka: Zkusíte znovu stavový kód HTTP 403 – Zakázáno? Ne. Systém tady funguje správně, ale informuje volajícího, že nemá oprávnění k provedení požadované operace. Je důležité opakovat pouze ty operace, které byly narušeny selháním.

Jak je doporučeno v kapitole 1, vývojáři Microsoftu, kteří vytváří aplikace nativní pro cloud, by měli cílit na platformu .NET. Verze 2.1 zavedla knihovnu HTTPClientFactory pro vytváření instancí klienta HTTP pro interakci s prostředky založenými na adrese URL. Nahrazující původní třídu HTTPClient, tovární třída podporuje mnoho vylepšených funkcí, z nichž jedna je úzká integrace s knihovnou pro zvýšení odolnosti Polly. Díky tomu můžete snadno definovat zásady odolnosti ve třídě Startup aplikace pro zpracování částečných selhání a problémů s připojením.

V dalším kroku se podíváme na vzory opakování a jističe.

Model Opakování

V distribuovaném cloudovém nativním prostředí může volání služeb a cloudových prostředků selhat kvůli přechodným (krátkodobým) selháním, která se obvykle po krátké době opravují. Implementace strategie opakování pomáhá nativní cloudové službě tyto scénáře zmírnit.

Model opakování umožňuje službě opakovat neúspěšnou operaci požadavku a (konfigurovatelný) počet opakování s exponenciálním zvýšením doby čekání. Obrázek 6-2 ukazuje opakovaný pokus v akci.

Obrázek 6–2 Vzor opakování v akci

Na předchozím obrázku byl pro operaci požadavku implementován model opakování. Je nakonfigurovaná tak, aby umožňovala až čtyři opakování před selháním s intervalem opakování (doba čekání) počínaje dvěma sekundami, což se exponenciálně zdvojnásobí pro každý další pokus.

• První vyvolání selže a vrátí stavový kód HTTP 500. Aplikace počká na dvě sekundy a opakuje volání.
• Druhé vyvolání také selže a vrátí stavový kód HTTP 500. Aplikace teď zdvojnásobí interval zpětného ukončení na čtyři sekundy a opakuje volání.
• Nakonec třetí volání proběhne úspěšně.
• V tomto scénáři by se operace pokusila až o čtyři pokusy, přičemž by se před každým z nich zdvojnásobila doba čekání mezi pokusy, než dojde k selhání volání.
• Pokud by se 4. opakovaný pokus nezdařil, vyvolala by se záložní zásada k jemnému vyřešení problému.

Je důležité prodloužit čekací dobu před opakovaným pokusem o volání, aby se služba mohla sama opravit. Osvědčeným postupem je implementovat exponenciálně se zvyšující zpoždění (zdvojnásobit interval zpoždění při každém opakování), aby byl zajištěn dostatečný čas na opravu.

Model jističe

I když vzor opakování může pomoct zachránit požadavek v částečném selhání, existují situace, kdy selhání mohou být způsobena neočekávanými událostmi, které budou vyžadovat delší dobu na vyřešení. 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 je zbytečné, když aplikace neustále opakuje operaci, která pravděpodobně nebude úspěšná.

Co je ještě horší, neustálé opakování operací na nereagující službě vás může přivést do situace odepření služby, kdy nepřetržitými voláními zahlcujete svou službu a čímž vyčerpáte prostředky jako paměť, vlákna a připojení k databázi. To způsobí selhání v nesouvisejících částech systému, které používají stejné prostředky.

V těchto situacích by bylo vhodnější, aby operace okamžitě selhala a pokusila se službu vyvolat pouze v případě, že by mohla být úspěšná.

Model Jistič může zabránit aplikaci v tom, aby se opakovaně pokoušela spustit operaci, která pravděpodobně selže. Po předem definovaném počtu neúspěšných volání blokuje veškerý provoz do služby. Pravidelně umožní zkušební hovor zjistit, zda byla chyba odstraněna. Obrázek 6–3 znázorňuje vzor Circuit Breaker při použití.

Obrázek 6–3 Model jističe v akci

Na předchozím obrázku byl do původního vzoru pro opakování přidán vzor obvodového jističe. Všimněte si, že po 100 neúspěšných požadavcích se jističe otevřou a už nepovolují volání do služby. Hodnota CheckCircuit nastavená na 30 sekund určuje, jak často knihovna umožňuje jednomu požadavku pokračovat do služby. Pokud volání proběhne úspěšně, okruh se zavře a služba bude opět dostupná pro síťový provoz.

Mějte na paměti, že záměr vzoru jistič se liší od vzoru opakování. Model Opakování umožňuje aplikaci opakovat operaci v očekávaném očekávání, že bude úspěšná. Designový vzor Circuit Breaker brání aplikaci v provádění operace, která pravděpodobně selže. Aplikace obvykle tyto dva vzory zkombinuje pomocí vzoru Opakování k vyvolání operace prostřednictvím jističe.

Testování odolnosti

Testování odolnosti nelze vždy provést stejným způsobem, jakým testujete funkce aplikace (spuštěním testů jednotek, integračních testů atd.). Místo toho musíte otestovat, jak komplexní úloha funguje za podmínek selhání, ke kterým dochází jen přerušovaně. Příklad: Způsobení selhání havarováním procesů, vypršení platnosti certifikátů, způsobení nedostupnosti závislých služeb atd. Frameworky jako chaos-monkey lze použít pro takové testování chaosu.

Odolnost aplikací je nutností pro zpracování problematických požadovaných operací. Ale je to jen polovina příběhu. Dále probereme funkce odolnosti dostupné v cloudu Azure.

předchozíDalší