Sdílet prostřednictvím

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

  • Článek

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

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

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. Konečná konzistence a architektury řízené událostmi vám pomůžou minimalizovat efekty ripple. 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 zpochybněním. 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 účinky ripple, nakonec dokonce způsobit odepření služby (DoS).

Pracujte s časovými 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 model Jistič. V tomto přístupu proces klienta sleduje počet neúspěšných požadavků. Pokud chybovost překročí nakonfigurovaný limit, dojde k okamžitému selhání "jističe", aby další pokusy okamžitě selhaly. (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 náhradní služby. 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 k splnění tohoto požadavku použít zásadu izolace Bulkhead Polly. Tento přístup je v podstatě omezení paralelizace s SemaphoreSlim implementací. Umožňuje také "frontu" mimo přepážku. Nadbytečné zatížení můžete proaktivně označit 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ž jistič, protože jistič čeká na 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í.

Další materiály

PředchozíDalší