Strategie pro zpracování částečného selhání

Návod

Tento obsah je výňatek z eBooku, architektury mikroslužeb .NET pro kontejnerizované aplikace .NET, které jsou k dispozici na .NET Docs nebo jako zdarma ke stažení PDF, které lze číst offline.

Stáhnout PDF

Pokud chcete řešit částečné selhání, použijte jednu z zde popsaných strategií.

Používejte asynchronní komunikaci (například komunikaci založenou na zprávách) mezi interními mikroslužbami. Důrazně doporučujeme nevytvořovat dlouhé řetězy synchronních volání HTTP napříč interními mikroslužbami, protože nesprávný návrh se nakonec stane hlavní příčinou špatných výpadků. Naopak s výjimkou front-endové komunikace mezi klientskými aplikacemi a první úrovní mikroslužeb nebo jemně odstupňovaných bran rozhraní API se doporučuje používat pouze asynchronní komunikaci (založenou na zprávách) po počátečním cyklu požadavků a odpovědí v rámci interních mikroslužeb. Konzistence v průběhu času a architektury řízené událostmi pomohou minimalizovat dopady. Tyto přístupy vynucují vyšší úroveň autonomii mikroslužeb, a proto brání problému, který zde uvádíme.

Použijte opakování s exponenciálním odstupem. Tato technika pomáhá vyhnout se krátkým a přerušovaným selháním provedením opakovaných pokusů o volání určitou dobu, v případě, že služba nebyla k dispozici pouze po krátkou dobu. K tomu může dojít kvůli přerušovaným problémům se sítí nebo přesunu mikroslužby nebo kontejneru do jiného uzlu v clusteru. Pokud však tyto opakování nejsou správně navrženy s jističi, může zhoršit řetězové účinky, a nakonec může dokonce způsobit odepření služby (DoS).

Obejděte časové limity sítě. Klienti by obecně měli být navrženi tak, aby neblokovali neomezeně dlouho a aby při čekání na odpověď vždy používali časové limity. Používání časových limitů zajišťuje, že prostředky nebudou nikdy vázány na neomezenou dobu.

Použijte vzor funkcionality Jistič. V tomto přístupu proces klienta sleduje počet neúspěšných požadavků. Pokud chybovost překročí nakonfigurovaný limit, dojde k aktivování jističe, což způsobí okamžité selhání dalších pokusů. (Pokud dochází k selhání velkého počtu požadavků, znamená to, že služba není k dispozici a že odesílání požadavků je zbytečné.) Po uplynutí časového limitu by se měl klient zkusit znovu a pokud jsou nové požadavky úspěšné, ukončete jistič.

Poskytovat záložní možnosti. V tomto přístupu proces klienta provádí záložní logiku, když požadavek selže, například vrácení dat uložených v mezipaměti nebo výchozí hodnota. Jedná se o přístup vhodný pro dotazy a je složitější pro aktualizace nebo příkazy.

Omezte počet požadavků zařazených do fronty. Klienti by také měli nastavit horní mez počtu nevyřízených požadavků, které klientská mikroslužba může odeslat do konkrétní služby. Pokud bylo dosaženo limitu, je pravděpodobně zbytečné provádět další žádosti a tyto pokusy by měly okamžitě selhat. Z hlediska implementace lze pro splnění tohoto požadavku použít zásadu Polly Bulkhead Isolation. Tento přístup je v podstatě brzdou paralelizace ve formě SemaphoreSlim implementace. Umožňuje také řadu mimo přepážku. Nadbytečné zatížení můžete proaktivně odstranit ještě před spuštěním (například protože kapacita je považována za plnou). Díky tomu je reakce na určité scénáře selhání rychlejší než by byla reakce jističe, který čeká na výskyt selhání. Objekt BulkheadPolicy v Polly zpřístupňuje, jak plná je bulkhead a queue, a nabízí události v přetečení, takže je možné použít také k řízení automatizovaného horizontálního škálování.

Dodatečné zdroje

• Vzory odolnosti
  https://learn.microsoft.com/azure/architecture/framework/resiliency/reliability-patterns

• Přidání odolnosti a optimalizace výkonu
  https://learn.microsoft.com/previous-versions/msp-n-p/jj591574(v=pandp.10)

• Přepážka. Úložiště GitHub Implementace pomocí zásad Polly.
  https://github.com/App-vNext/Polly/wiki/Bulkhead

• Návrh odolných aplikací pro Azure
  https://learn.microsoft.com/azure/architecture/framework/resiliency/app-design

• Zpracování přechodných chyb
  https://learn.microsoft.com/azure/architecture/best-practices/transient-faults

předchozíDalší