Vzory odolnosti aplikací

Tip

Tento obsah je výňatek z eBooku, Architekting Cloud Native .NET Applications for Azure, který je k dispozici na webu Docs pro .NET nebo jako soubor PDF zdarma 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 pro odolnost .NET a zpracování přechodných chyb, která vývojářům umožňuje vyjádřit zásady odolnosti plynulým a bezpečným způsobem 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.

Zásady	Prostředí
Zkusit znovu	Konfiguruje operace opakování u určených operací.
Circuit Breaker	Blokuje požadované operace pro předdefinované období, když chyby překročí nakonfigurovanou prahovou hodnotu.
Timeout	Nastaví omezení doby trvání, po kterou může volající čekat na odpověď.
Bulkhead	Omezuje akce na fond zdrojů s pevnou velikostí, aby se zabránilo neúspěšným voláním v zamažová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	Vypršení časového limitu požadavku
429	Příliš mnoho požadavků (pravděpodobně jste omezili)
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 potřeba věnovat pozornost opakování pouze těchto operací způsobených selháními.

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. Nadsedání původní třídy HTTPClient, třída továrny podporuje mnoho vylepšených funkcí, z nichž jedna je úzká integrace s knihovnou odolnosti Polly. Díky tomu můžete snadno definovat zásady odolnosti ve třídě po spuštění aplikace, které zpracovávají částečná selhání a problémy 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 opakování 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 opakování pokusila o až čtyři opakování při zdvojnásobení doby trvání opakování před selháním volání.
• Pokud by se 4. pokus o opakování nezdařil, vyvolala by se záložní zásada pro řádné zpracování problému.

Před opakovaným pokusem o volání je důležité zvýšit dobu obnovení, aby služba mohla sama opravit čas. Osvědčeným postupem je implementovat exponenciálně zvyšující se závrat (zdvojnásobit dobu opakování) a umožnit tak odpovídající dobu opravy.

Model jističe

I když vzor opakování může pomoct se zůstatkem požadavku propletené v částečném selhání, existují situace, kdy selhání můžou být způsobená neočekávanými událostmi, které budou vyžadovat delší časové období k 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é, aby aplikace neustále opakovat operaci, která je nepravděpodobné, že by uspěla.

Aby se to zhoršilo, může vás provádění nepřetržitých operací opakování v nereagující službě přesunout do scénáře odepření služby, ve kterém službu zahlcením nepřetržitě voláte vyčerpáním prostředků, jako jsou paměť, vlákna a připojení k databázi, což 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 bránit aplikaci v opakovaném pokusu o spuštění operace, 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ímu volání určit, jestli se chyba vyřešila. Obrázek 6–3 znázorňuje v akci model Jistič.

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

Na předchozím obrázku byl do původního vzoru opakování přidán model Jistič. 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 provoz.

Mějte na paměti, že záměr modelu 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á. Model Jistič 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 proti chybám

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: Vložení selhání chybových procesů, vypršení platnosti certifikátů, nedostupnosti závislých služeb atd. Architektury jako chaos-opice 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ší