Zpracování částečného selhání

Tip

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

V distribuovaných systémech, jako jsou aplikace založené na mikroslužbách, existuje stále přítomné riziko částečného selhání. Například jedna mikroslužba nebo kontejner může selhat nebo nemusí být dostupná pro krátkou dobu, jinak může dojít k chybovému ukončení jednoho virtuálního počítače nebo serveru. Vzhledem k tomu, že klienti a služby jsou samostatné procesy, nemusí služba včas reagovat na žádost klienta. Služba může být přetížená a reaguje velmi pomalu na požadavky nebo může být kvůli problémům se sítí jednoduše nedostupná po krátkou dobu.

Představte si například stránku s podrobnostmi objednávky z ukázkové aplikace eShopOnContainers. Pokud mikroslužba řazení nereaguje, když se uživatel pokusí odeslat objednávku, chybná implementace klientského procesu (webová aplikace MVC) – například pokud by kód klienta používal synchronní rpcs bez časového limitu – by blokovala vlákna bez časového limitu na neomezenou dobu čekání na odpověď. Kromě vytváření špatných uživatelských zkušeností každý nereagující čekání spotřebovává nebo blokuje vlákno a vlákna jsou velmi cenné ve vysoce škálovatelných aplikacích. Pokud existuje mnoho blokovaných vláken, může nakonec dojít k výpadku vláken modulu runtime aplikace. V takovém případě se aplikace může stát globálně nereagující místo jen částečně nereagující, jak je znázorněno na obrázku 8-1.

Obrázek 8-1 Částečná selhání kvůli závislostem, které mají vliv na dostupnost vlákna služby

Ve velké aplikaci založené na mikroslužbách je možné všechna částečná selhání zvětšit, zejména pokud je většina interakce interních mikroslužeb založená na synchronních voláních HTTP (což se považuje za anti-pattern). Zamyslete se nad systémem, který přijímá miliony příchozích hovorů za den. Pokud má váš systém špatný návrh založený na dlouhých řetězech synchronních volání HTTP, může tato příchozí volání vést k mnoha milionům odchozích volání (předpokládejme, že poměr 1:4) k desítkám interních mikroslužeb jako synchronních závislostí. Tato situace je znázorněna na obrázku 8-2, zejména závislost č. 3, která spouští řetěz, volá závislost č. 4, která pak volá #5.

Obrázek 8–2 Dopad nesprávného návrhu s dlouhými řetězy požadavků HTTP

Přerušované selhání je zaručeno v distribuovaném a cloudovém systému, i když má každá samotná závislost vynikající dostupnost. Je to fakt, že je potřeba zvážit.

Pokud nenavrhujete a implementujete techniky pro zajištění odolnosti proti chybám, je možné amplovat i malé výpadky. Například 50 závislostí s 99,99 % dostupnosti by každý měsíc vedlo k několika hodinám výpadku z tohoto efektu. Pokud závislost mikroslužby selže při zpracování velkého objemu požadavků, může toto selhání rychle nasytit všechna dostupná vlákna požadavků v každé službě a zhroutí celou aplikaci.

Obrázek 8-3 Částečné selhání amplifikované mikroslužbami s dlouhými řetězy synchronních volání HTTP

Pokud chcete tento problém minimalizovat, v části Asynchronní integrace mikroslužeb vynucuje autonomii mikroslužeb, tato příručka vás vyzývá k použití asynchronní komunikace mezi interními mikroslužbami.

Kromě toho je nezbytné navrhnout mikroslužby a klientské aplikace tak, aby zvládly částečné selhání – to znamená k vytváření odolných mikroslužeb a klientských aplikací.

PředchozíDalší