Sdílet prostřednictvím

Odolnost a vysoká dostupnost v mikroslužbách

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

eBook o architektuře mikroslužeb .NET pro kontejnerizované aplikace .NET, miniatura na obálce.

Řešení neočekávaných selhání je jedním z nejtěžších problémů při řešení, zejména v distribuovaném systému. Většina kódu, který vývojáři píší, zahrnuje zpracování výjimek, a to je také místo, kde se nejvíce času tráví při testování. Problém je složitější než psaní kódu pro zpracování selhání. Co se stane, když počítač, na kterém je spuštěná mikroslužba, selže? Nejen že potřebujete zjistit selhání mikroslužby (problém sám o sobě), ale potřebujete také něco k restartování mikroslužby.

Mikroslužba musí být odolná vůči selháním a aby byla schopná restartovat často na jiném počítači kvůli dostupnosti. Tato odolnost také závisí na stavu, který byl uložen jménem mikroslužby, odkud může mikroslužba tento stav obnovit, a zda se mikroslužba může úspěšně znovu spustit. Jinými slovy, musí existovat odolnost výpočetních funkcí (proces se může kdykoli restartovat) i odolnost ve stavu nebo datech (žádná ztráta dat a data zůstávají konzistentní).

Problémy s odolností se zhoršují v jiných scénářích, například v případě selhání během upgradu aplikace. Mikroslužba, která pracuje se systémem nasazení, musí určit, jestli se může pokračovat v přechodu k novější verzi, nebo se místo toho vrátit k předchozí verzi, aby zachoval konzistentní stav. Dotazy, jako je to, jestli je k dispozici dostatek počítačů, aby bylo možné pokračovat dál a jak obnovit předchozí verze mikroslužby, je potřeba zvážit. Tento přístup vyžaduje, aby mikroslužba vysílala informace o stavu, aby tato rozhodnutí mohly provádět celková aplikace a orchestrátor.

Kromě toho odolnost souvisí s tím, jak se musí cloudové systémy chovat. Jak už bylo zmíněno, cloudový systém musí přijmout selhání a musí se z nich automaticky zotavit. Například v případě selhání sítě nebo kontejneru musí mít klientské aplikace nebo klientské služby strategii pro opakování odesílání zpráv nebo opakování požadavků, protože v mnoha případech jsou selhání v cloudu částečná. Část Implementace odolných aplikací v tomto průvodci se zabývá způsobem zpracování částečného selhání. Popisuje techniky, jako jsou opakování s exponenciálním prodlevovým mechanismem nebo vzorem Circuit Breaker v .NET frameworku, pomocí knihoven, jako je Polly, které nabízí širokou škálu strategií pro řešení tohoto problému.

Správa stavu a diagnostika v mikroslužbách

Může to vypadat jako běžné a často se přehlíží, ale mikroslužba musí hlásit svůj stav a diagnostiku. V opačném případě je z hlediska operací malý přehled. Korelace diagnostických událostí v rámci sady nezávislých služeb a vyrovnávání rozdílů v časových nastaveních, aby bylo možné určit pořadí událostí, je obtížné. Stejně jako s mikroslužbou komunikujete s odsouhlasenými protokoly a formáty dat, je potřeba standardizovat, jak protokolovat události stavu a diagnostiky, které nakonec skončí v úložišti událostí pro dotazování a prohlížení. V přístupu k mikroslužbám je klíčové, aby různé týmy souhlasily s jedním formátem protokolování. Musí existovat konzistentní přístup k zobrazení diagnostických událostí v aplikaci.

Zdravotní prohlídky

Stav se liší od diagnostiky. Zdraví spočívá v tom, že mikroslužba hlásí svůj aktuální stav, aby bylo možné provést příslušné kroky. Dobrým příkladem je práce s mechanismy upgradu a nasazení pro zachování dostupnosti. I když služba v současné době nemusí být v pořádku kvůli selhání procesu nebo restartování počítače, může být služba stále funkční. Poslední věc, kterou potřebujete, je, že by se to zhoršilo provedením upgradu. Nejlepším přístupem je nejprve provést šetření nebo umožnit, aby se mikroslužba obnovila. Události zdraví z mikroslužby nám pomáhají činit informovaná rozhodnutí a v podstatě pomáhají vytvářet samoopravné služby.

V části Implementace kontrol stavu v části služby ASP.NET Core v této příručce vysvětlíme, jak ve vašich mikroslužbách použít novou knihovnu ASP.NET HealthChecks, aby mohly hlásit stav monitorovací službě, aby provedly příslušné akce.

Máte také možnost použít vynikající opensourcovou knihovnu s názvem AspNetCore.Diagnostics.HealthChecks, která je dostupná na GitHubu a jako balíček NuGet. Tato knihovna také provádí zdravotní kontroly s úpravou; zpracovává dva typy kontrol:

  • Liveness: Kontroluje, jestli je mikroslužba naživu, tzn. jestli je schopná přijímat žádosti a reagovat.
  • Připravenost: Kontroluje, zda jsou závislosti mikroslužby (databáze, služby front atd.) připravené, aby mikroslužba mohla plnit své úkoly.

Použití diagnostických a protokolových streamů událostí

Protokoly poskytují informace, včetně výjimek, upozornění a jednoduchých informačních zpráv, o tom, jak je aplikace nebo služba provozována. Obvykle je každý protokol v textovém formátu, jeden řádek na událost, i když výjimky často zobrazují trasování zásobníku na více řádků.

V monolitických serverových aplikacích můžete zapisovat protokoly do souboru na disku (soubor protokolu) a pak je analyzovat pomocí libovolného nástroje. Vzhledem k tomu, že spouštění aplikací je omezené na pevný server nebo virtuální počítač, není obecně příliš složité analyzovat tok událostí. V distribuované aplikaci, kde se v clusteru orchestrátoru spouští více služeb v mnoha uzlech, je však schopnost korelovat distribuované události výzvou.

Aplikace založená na mikroslužbách by se neměla pokoušet ukládat výstupní datový proud událostí nebo souborů protokolů sama o sobě a ani se pokoušet spravovat směrování událostí do centrálního místa. Měl by být transparentní, což znamená, že každý proces by měl pouze zapisovat svůj stream událostí do standardního výstupu, který bude shromážděn infrastrukturou spouštěcího prostředí, ve které běží. Příkladem těchto směrovačů streamů událostí je Microsoft.Diagnostic.EventFlow, který shromažďuje datové proudy událostí z více zdrojů a publikuje je do výstupních systémů. Můžou zahrnovat jednoduchý standardní výstup pro vývojové prostředí nebo cloudové systémy, jako je Azure Monitor a Azure Diagnostics. Existují také dobré platformy a nástroje pro analýzu protokolů třetích stran, které můžou vyhledávat, upozorňovat, hlásit a monitorovat protokoly, a to i v reálném čase, jako je Splunk nebo Middleware.

Orchestrátory spravující informace o zdravotním stavu a diagnostice

Když vytváříte aplikaci založenou na mikroslužbách, musíte se vypořádat se složitostí. Samozřejmě, jedna mikroslužba je jednoduchá pro řešení, ale desítky nebo stovky typů a tisíce instancí mikroslužeb je složitý problém. Není to jen o vytváření architektury mikroslužeb – potřebujete také vysokou dostupnost, adresovatelnost, odolnost, stav a diagnostiku, pokud máte v úmyslu mít stabilní a soudržný systém.

Diagram clusterů poskytujících platformu podpory pro mikroslužby

Obrázek 4–22 Platforma mikroslužeb je zásadní pro správu stavu aplikace.

Složité problémy zobrazené na obrázku 4–22 se obtížně řeší sami. Vývojové týmy by se měly zaměřit na řešení obchodních problémů a vytváření vlastních aplikací s využitím přístupů založených na mikroslužbách. Neměly by se soustředit na řešení složitých problémů infrastruktury; pokud ano, náklady na libovolnou aplikaci založenou na mikroslužbách by byly obrovské. Proto existují platformy orientované na mikroslužby, které se označují jako orchestrátory nebo clustery mikroslužeb, které se snaží efektivně řešit těžké problémy při sestavování a spouštění služby a používání prostředků infrastruktury. Tento přístup snižuje složitost vytváření aplikací, které používají přístup k mikroslužbám.

Různé orchestrátory můžou vypadat podobně, ale diagnostika a kontroly stavu, které každý z nich nabízí, se liší ve funkcích a stavu vyspělosti, někdy v závislosti na platformě operačního systému, jak je vysvětleno v další části.

Dodatečné zdroje

předchozíDalší

  • Last updated on