Sdílet prostřednictvím

Odolnost a vysoká dostupnost v mikroslužbách

  • Č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.

Ř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 více zapojen 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é přichází do stavu uloženého jménem mikroslužby, odkud může mikroslužba obnovit tento stav a jestli se mikroslužba může úspěšně restartovat. 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 odolnosti jsou složené 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 zpochybováním nebo vzorem Jistič v .NET, pomocí knihoven, jako je Polly, které nabízí širokou škálu zásad pro zpracování tohoto tématu.

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í napříč sadou nezávislých služeb a práce s nerovnoměrnými distribucemi hodin počítačů, které mají smysl pro pořadí událostí, je nároč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.

Kontroly stavu

Stav se liší od diagnostiky. Stav mikroslužby hlásí aktuální stav, aby bylo potřeba provést příslušné akce. 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, aby to bylo horší provedením upgradu. Nejlepším přístupem je nejprve provést šetření nebo umožnit, aby se mikroslužba obnovila. Události stavu z mikroslužby nám pomáhají činit informovaná rozhodnutí a v podstatě pomáhají vytvářet samoobslužné opravy.

V části Implementace kontrol stavu v části služby ASP.NET Core v této příručce vysvětlujeme, jak ve vašich mikroslužbách použít novou knihovnu ASP.NET HealthChecks, aby mohli 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 GitHubua jako balíček NuGet. Tato knihovna také provádí kontroly stavu s kroucením, 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, jestli jsou závislosti mikroslužby (databáze, služby front atd.) připravené, aby mikroslužba dělala to, co má dělat.

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

Protokoly poskytují informace o tom, jak je aplikace nebo služba spuštěná, včetně výjimek, upozornění a jednoduchých informačních zpráv. Každý protokol je obvykle v textovém formátu s jedním řádkem na událost, i když výjimky také často zobrazují trasování zásobníku napříč více řádky.

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é vhodné 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.

Orchestrátory spravující informace o 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 of clusters supplying a support platform for microservices.

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.

Další materiály

PředchozíDalší