Chcete se dozvědět o Service Fabric?

  • Článek
  • 17 min ke čtení

Azure Service Fabric je platforma distribuovaných systémů usnadňující balení, nasazování a spravování škálovatelných a spolehlivých mikroslužeb. Service Fabric má ale velkou oblast povrchu, ale máme spoustu informací. Tento článek obsahuje stručný přehled Service Fabric a popisuje základní koncepty, programovací modely, životní cyklus aplikací, testování, clustery a monitorování stavu. Přečtěte si Přehled a co jsou mikroslužby? Úvod do Service Fabric, jak se dá použít k vytváření mikroslužeb. Tento článek neobsahuje úplný seznam obsahu, ale obsahuje odkaz na přehled a zahájení práce pro každou oblast Service Fabric.

Základní koncepty

Service Fabric terminologie, aplikační modela podporované programovací modely poskytují více konceptů a popisů, ale tady jsou základy.

Doba návrhu: typ služby, balíček služby a manifest, typ aplikace, balíček aplikace a manifest

Typ služby je název/verze přiřazená k balíčkům kódu služby, datovým balíčkům a konfiguračním balíčkům. Tato definice je definována v souboru ServiceManifest.xml. Typ služby se skládá ze spustitelného kódu a konfiguračního nastavení služby, které jsou načteny za běhu, a statických dat, která služba spotřebovává.

Balíček služby je adresář disku, který obsahuje ServiceManifest.xml soubor typu služby, který odkazuje na kód, statická data a konfigurační balíčky pro typ služby. Balíček služby může například odkazovat na kód, statická data a konfigurační balíčky, které tvoří databázovou službu.

Typ aplikace je název/verze přiřazená kolekci typů služeb. Tato definice je definována v souboru ApplicationManifest.xml.

Service Fabric typů aplikací a typů služeb

Balíček aplikace je adresář disku, který obsahuje soubor ApplicationManifest.xml typu aplikace, který odkazuje na balíčky služeb pro každý typ služby, který tvoří typ aplikace. Například balíček aplikace pro typ e-mailové aplikace může obsahovat odkazy na balíček služby front, front-end Service a balíček databázové služby.

Soubory v adresáři balíčku aplikace se zkopírují do úložiště imagí Service Fabricho clusteru. Pak můžete vytvořit pojmenovanou aplikaci z tohoto typu aplikace, která pak bude spuštěna v rámci clusteru. Po vytvoření pojmenované aplikace můžete vytvořit pojmenovanou službu z některého z typů služeb typu aplikace.

Čas spuštění: clustery a uzly, pojmenované aplikace, pojmenované služby, oddíly a repliky

Cluster Service Fabric je sada virtuálních nebo fyzických počítačů připojených k síti, do kterých se vaše mikroslužby nasazují a spravují. Clustery je možné škálovat na tisíce počítačů.

Počítač nebo virtuální počítač, který je součástí clusteru, se nazývá uzel. Každému uzlu je přiřazen název uzlu (řetězec). Uzly mají určité charakteristiky, například vlastnosti umístění. Každý počítač nebo virtuální počítač má automaticky spuštěnou službu systému Windows, FabricHost.exe která při spuštění spustí spuštění a pak spustí dva spustitelné soubory: Fabric.exe a FabricGateway.exe . Tyto dva spustitelné soubory tvoří uzel. Pro scénáře vývoje nebo testování můžete hostovat více uzlů na jednom počítači nebo VIRTUÁLNÍm počítači spuštěním několika instancí Fabric.exe a FabricGateway.exe .

Pojmenovaná aplikace je kolekce pojmenovaných služeb, které provádějí určitou funkci nebo funkce. Služba provádí úplnou a samostatnou funkci (může spustit a spustit nezávisle na jiných službách) a skládá se z kódu, konfigurace a dat. Po zkopírování balíčku aplikace do úložiště imagí vytvoříte instanci aplikace v rámci clusteru tak, že zadáte typ aplikace v balíčku aplikace (pomocí jejího názvu nebo verze). Každé instanci typu aplikace je přiřazen název identifikátoru URI, který vypadá jako Fabric:/MyNamedApp. V rámci clusteru můžete vytvořit více pojmenovaných aplikací z jednoho typu aplikace. Můžete také vytvořit pojmenované aplikace z různých typů aplikací. Každá pojmenovaná aplikace je spravovaná a má nezávisle.

Po vytvoření pojmenované aplikace můžete v clusteru vytvořit instanci jednoho z jejích typů služeb (pojmenovaná služba), a to zadáním typu služby (pomocí jejího názvu nebo verze). Každá instance typu služby má přiřazený název identifikátoru URI v oboru názvů IDENTIFIKÁTORu URI pojmenované aplikace. Například pokud vytvoříte "MyDatabase" pojmenovanou službu v rámci "MyNamedApp" pojmenované aplikace, identifikátor URI vypadá jako: Fabric:/MyNamedApp/MyDatabase. V rámci pojmenované aplikace můžete vytvořit jednu nebo více pojmenovaných služeb. Každá pojmenovaná služba může mít vlastní schéma oddílů a počty instancí nebo replik.

Existují dva typy služeb: bezstavové a stavové. Bezstavové služby neukládají ve službě stav. Bezstavové služby neobsahují trvalé úložiště vůbec nebo ukládají trvalý stav do externí služby úložiště, jako je Azure Storage, Azure SQL Database nebo Azure Cosmos DB. Stavová služba ukládá stav v rámci služby a používá spolehlivé kolekce nebo Reliable Actors programovacích modelů pro správu stavu.

Při vytváření pojmenované služby určíte schéma oddílu. Služby s velkým množstvím stavu rozdělí data napříč oddíly. Každý oddíl zodpovídá za část kompletního stavu služby, která je rozdělená mezi uzly clusteru.

Následující diagram znázorňuje vztah mezi aplikacemi a instancemi služby, oddíly a replikami.

Oddíly a repliky v rámci služby

Dělení, škálování a dostupnost

Dělení není pro Service Fabric jedinečné. Dobře známá forma dělení je data partitions nebo horizontálního dělení. Stavové služby s velkým objemem stavu rozdělí data napříč oddíly. Každý oddíl zodpovídá za část kompletního stavu služby.

Repliky jednotlivých oddílů jsou rozloženy v uzlech clusteru, což umožňuje škálovatstav pojmenované služby. Vzhledem k rostoucímu množství dat, zvětšování oddílů a Service Fabric přerovnává oddíly mezi uzly, aby bylo možné efektivně využívat hardwarové prostředky. Pokud do clusteru přidáte nové uzly, Service Fabric bude znovu vyrovnávat repliky oddílů v rámci většího počtu uzlů. Celkový výkon aplikace vylepšuje a kolizí pro přístup k snížení velikosti paměti. Pokud se uzly v clusteru nepoužívají efektivně, můžete snížit počet uzlů v clusteru. Service Fabric znovu vyrovnává repliky oddílů napříč sníženým počtem uzlů, aby bylo možné lépe využívat hardware na každém uzlu.

V rámci oddílu mají instance bez příslušnosti instance, zatímco stavová služba má repliky. Obvykle pouze bezstavové služby s názvem mají vždy jeden oddíl, protože nemají žádný interní stav, i když existují výjimky. Instance oddílu poskytují dostupnost. Pokud dojde k chybě jedné instance, ostatní instance budou fungovat normálně a pak Service Fabric vytvoří novou instanci. Stavové pojmenované služby udržují stav v rámci replik a každý oddíl má vlastní sadu replik. Operace čtení a zápisu se provádějí v jedné replice (označované jako primární). Změny stavu z operací zápisu se replikují do více dalších replik (označované jako aktivní sekundární). Pokud by se replika nezdařila, Service Fabric vytvoří novou repliku z existujících replik.

Bezstavové a stavové mikroslužby pro Service Fabric

Service Fabric umožňuje sestavovat aplikace, které se skládají z mikroslužeb nebo kontejnerů. Bezstavové mikroslužby (například brány protokolů a webové proxy) si mimo požadavek a odpověď ze služby neudržují měnitelný stav. Role pracovních procesů služby Azure Cloud Services jsou příkladem stavové služby. Stavové mikroslužby (například uživatelské účty, databáze, zařízení, nákupní košíky a fronty) si udržují měnitelný a autoritativní stav i mimo požadavek a odpověď. Dnešní aplikace v internetovém měřítku se skládají z kombinace bezstavových a stavových mikroslužeb.

Klíčovým rozlišením Service Fabric je jeho silný fokus při vytváření stavových služeb, a to buď pomocí vestavěných programovacích modelů , nebo s využitím kontejnerových stavových služeb. Scénáře aplikací popisují scénáře, ve kterých se používají stavové služby.

Proč mají stavové mikroslužby spolu s bezstavovým mikroslužbami? Existují dva hlavní důvody:

  • Můžete vytvořit vysoce propustnost, nízkou latenci, neOLTPé služby online zpracování transakcí (), a to tak, že zachováte kód a data blízko na stejném počítači. Některé příklady jsou interaktivní prodejní místa, hledání, Internet věcí (IoT) systémy, obchodní systémy, zpracování kreditních karet a systémy pro detekci podvodů a správa osobních záznamů.
  • Můžete zjednodušit návrh aplikace. Stavové mikroslužby odstraňují nutnost dalších front a mezipamětí, které jsou tradičně nutné pro řešení požadavků na dostupnost a latenci čistě bezstavových aplikací. Stavové služby jsou přirozeně vysokou dostupností a s nízkou latencí, což snižuje počet přesouvaných částí, které se mají ve vaší aplikaci spravovat jako celek.

Podporované programovací modely

Service Fabric nabízí několik způsobů, jak psát a spravovat vaše služby. Služby mohou používat rozhraní Service Fabric API k plnému využití funkcí platformy a architektur aplikací. Služby také mohou být všechny zkompilované spustitelné programy napsané v jakémkoli jazyce a jsou hostovány v clusteru Service Fabric. Další informace najdete v tématu podporované programovací modely.

Kontejnery

Ve výchozím nastavení Service Fabric nasadí a aktivuje služby jako procesy. Service Fabric mohou také nasazovat služby v kontejnerech. Důležité je, že můžete kombinovat služby v procesech a službách v kontejnerech ve stejné aplikaci. Service Fabric podporuje nasazení kontejnerů Linux a kontejnerů Windows v systému Windows Server 2016. V kontejnerech můžete nasadit existující aplikace, bezstavové služby nebo stavové služby.

Reliable Services

Reliable Services je zjednodušená architektura pro psaní služeb, které se integrují s Service Fabricou platformou a využívají kompletní sadu funkcí platformy. Reliable Services můžou být Bezstavová (podobně jako u většiny platforem služeb, jako jsou webové servery nebo role pracovního procesu ve službě Azure Cloud Services), kde je stav uložený v externím řešení, jako je Azure DB nebo Azure Table Storage. Reliable Services může být také stavová, kde je stav uložen přímo ve službě samotné pomocí spolehlivých kolekcí. Stav je vysoce dostupný prostřednictvím replikace a distribuuje se prostřednictvím dělení, a to vše spravované automaticky pomocí Service Fabric.

Reliable Actors

Technologie Reliable Actors , která je postavená na Reliable Services, je rozhraní aplikace, které implementuje vzor virtuálního objektu actor na základě vzoru návrhu objektu actor. Rozhraní Reliable actor používá nezávislé jednotky COMPUTE a State s jedním vláknovým spouštěním nazvaným Actors. Rozhraní Reliable Actors poskytuje vestavěnou komunikaci pro objekty actor a trvalá nastavení trvalých stavů a škálování na více systémů.

ASP.NET Core

Service Fabric se integruje s ASP.NET Core jako první třída programovací model pro vytváření webových aplikací a aplikací API. ASP.NET Core lze použít dvěma různými způsoby v Service Fabric:

  • Hostuje se jako spustitelný soubor hosta. Používá se hlavně ke spouštění existujících aplikací ASP.NET Core v Service Fabric bez jakýchkoli změn kódu.
  • Spouštějte v rámci spolehlivé služby. To umožňuje lepší integraci s Service Fabric runtime a umožňuje stavové služby ASP.NET Core.

Spustitelné soubory typu Host

Spustitelný soubor hosta je existující libovolný spustitelný soubor (napsaný v jakémkoli jazyce) hostovaný na Service Fabricm clusteru spolu s dalšími službami. Spustitelné soubory hosta se neintegrují přímo s Service Fabric rozhraní API. Stále však využívají funkce, které nabízí platforma, jako je například vlastní stav, generování sestav a zjistitelnost služeb voláním rozhraní REST API. Mají také úplnou podporu životního cyklu aplikací.

Životní cyklus aplikace

Stejně jako u jiných platforem aplikace na Service Fabric obvykle prochází následujícími fázemi: návrh, vývoj, testování, nasazení, upgrade, údržba a odebrání. Service Fabric poskytuje prvotřídní podporu pro plný životní cyklus aplikací cloudových aplikací, od vývoje prostřednictvím nasazení, každodenní správy a údržby až po případné vyřazení z provozu. Model služby umožňuje, aby se v životním cyklu aplikace nezávisle účastnilo několik různých rolí. Service Fabric životní cyklus aplikace poskytuje přehled rozhraní API a způsob jejich používání různými rolemi v průběhu fáze životního cyklu aplikace Service Fabric.

Celý životní cyklus aplikace se dá spravovat pomocí rutin PowerShellu, příkazů CLI, rozhraní API jazyka C#, rozhraní API Javaa rozhraní REST API. Kanály průběžné integrace a průběžného nasazování můžete také nastavit pomocí nástrojů, jako je Azure Pipelines nebo Jenkinse.

Testování aplikací a služeb

Aby bylo možné vytvářet vysoce škálovatelné služby, je důležité ověřit, že vaše aplikace a služby můžou naodolat chybám reálného světa. Služba analýzy chyb je navržena pro testování služeb, které jsou postaveny na Service Fabric. Pomocí služby analýzy chybmůžete navolávat smysluplné chyby a spouštět kompletní testovací scénáře pro vaše aplikace. Tyto chyby a scénáře cvičení a ověřují množství stavů a přechodů, ke kterým dojde v průběhu své životnosti, a to vše v kontrolovaném, bezpečném a konzistentním způsobem.

Akce cílí na službu pro testování pomocí jednotlivých chyb. Vývojář služby může tyto prvky použít jako stavební bloky pro psaní složitých scénářů. Příklady simulovaných chyb:

  • Restartujte uzel, aby se simuloval libovolný počet situací, kdy se počítač nebo virtuální počítač restartuje.
  • Přesuňte repliku stavové služby pro simulaci vyrovnávání zatížení, převzetí služeb při selhání nebo upgradu aplikace.
  • Vyvolat ztrátu kvora pro stavovou službu a vytvořit situaci, kdy operace zápisu nemohou pokračovat, protože pro příjem nových dat nejsou k dispozici dostatek záložních a sekundárních replik.
  • Vyvolat ztrátu dat u stavové služby, která vytvoří situaci, kdy je stav veškerého stavu v paměti zcela vymazán.

Scénáře jsou komplexní operace složené z jedné nebo více akcí. Služba analýzy chyb nabízí dva předdefinované scénáře:

  • Scénář chaos– simuluje nepřetržité, prokládané chyby (jak v rámci celého clusteru, tak i nekonečno) po delší dobu.
  • Scénář převzetí služeb při selhání– verze scénáře testu chaos, která cílí na konkrétní oddíl služby a zároveň ponechává jiné služby, které neovlivní.

Clustery

Cluster Service Fabric je sada virtuálních nebo fyzických počítačů připojených k síti, do kterých se vaše mikroslužby nasazují a spravují. Clustery je možné škálovat na tisíce počítačů. Počítač nebo virtuální počítač, který je součástí clusteru, se označuje jako uzel clusteru. Každému uzlu je přiřazen název uzlu (řetězec). Uzly mají určité charakteristiky, například vlastnosti umístění. Každý počítač nebo virtuální počítač má automaticky spuštěnou službu, FabricHost.exe která při spuštění spustí spuštění, a potom spustí dva spustitelné soubory: Fabric.exe a FabricGateway.exe. Tyto dva spustitelné soubory tvoří uzel. V případě testovacích scénářů můžete hostovat více uzlů na jednom počítači nebo VIRTUÁLNÍm počítači spuštěním více instancí Fabric.exe a FabricGateway.exe .

Clustery Service Fabric lze vytvořit na virtuálních nebo fyzických počítačích se systémem Windows Server nebo Linux. Můžete nasazovat a spouštět aplikace Service Fabric v jakémkoli prostředí, kde máte připojenou sadu počítačů se systémem Windows Server nebo Linux, které jsou propojeny: místně, v Microsoft Azure nebo na jakémkoli poskytovateli cloudu.

Clustery v Azure

Spuštění Service Fabric clusterů v Azure zajišťuje integraci s dalšími funkcemi a službami Azure, což usnadňuje a spolehlivuje provoz a správu clusteru. Cluster je prostředek Azure Resource Manager, takže můžete modelovat clustery stejně jako jakékoli jiné prostředky v Azure. Správce prostředků taky umožňuje snadnou správu všech prostředků používaných clusterem jako jedné jednotky. Clustery v Azure jsou integrované s protokoly diagnostiky a Azure Monitor Azure. Typy uzlů clusteru jsou sady škálování virtuálních počítačů, takže funkce automatického škálování je integrovaná.

Cluster v Azure můžete vytvořit prostřednictvím Azure Portal, ze šablonynebo ze sady Visual Studio.

Service Fabric v systému Linux vám umožňuje sestavovat, nasazovat a spravovat vysoce dostupné a vysoce škálovatelné aplikace na platformě Linux stejným způsobem jako ve Windows. Rozhraní Service Fabric (Reliable Services a Reliable Actors) jsou kromě C# (.NET Core) k dispozici v jazyce Java v systému Linux. Můžete také vytvořit hostované služby hosta s libovolným jazykem nebo architekturou. Podporují se taky orchestrace kontejnerů Docker. Kontejnery Docker můžou spouštět spustitelné soubory hosta nebo nativní Service Fabric služby, které používají Service Fabric architektury. Další informace najdete v článku o Service Fabric v systému Linux.

Existují některé funkce, které jsou ve Windows podporované, ale ne v systému Linux. Pokud se chcete dozvědět víc, přečtěte si rozdíly mezi Service Fabric v systémech Linux a Windows.

Samostatné clustery

Service Fabric poskytuje instalační balíček, který vám umožní vytvořit samostatné Service Fabric clustery v místním prostředí nebo v jakémkoli poskytovateli cloudu. Samostatné clustery poskytují volnost hostování clusteru kdekoli, kde chcete. Pokud jsou vaše data předmětem dodržování předpisů nebo regulativních omezení nebo chcete zachovat místní data, můžete hostovat svůj vlastní cluster a aplikace. Aplikace Service Fabric mohou běžet v několika hostitelských prostředích bez jakýchkoli změn, takže vaše znalosti sestavování aplikací přecházejí z jednoho hostitelského prostředí do jiného.

Vytvoření vašeho prvního samostatného clusteru Service Fabric

Samostatné clustery se systémem Linux zatím nejsou podporovány.

Zabezpečení clusteru

Clustery musí být zabezpečené, aby se zabránilo neautorizovaným uživatelům v připojení ke clusteru, zejména v případě, že na něm běží provozní zatížení. I když je možné vytvořit nezabezpečený cluster, umožní vám to anonymním uživatelům připojovat se k němu, pokud jsou koncové body správy zpřístupněny veřejnému Internetu. Nelze později povolit zabezpečení u nezabezpečeného clusteru: v době vytváření clusteru je povoleno zabezpečení clusteru.

Scénáře zabezpečení clusteru jsou tyto:

  • Zabezpečení mezi uzly
  • Zabezpečení klient-uzel
  • Service Fabric řízení přístupu na základě role

Další informace najdete v článku zabezpečení clusteru.

Škálování

Pokud do clusteru přidáte nové uzly, Service Fabric znovu vyrovnává repliky oddílů a instance napříč rostoucím počtem uzlů. Celkový výkon aplikace vylepšuje a kolizí pro přístup k snížení velikosti paměti. Pokud se uzly v clusteru nepoužívají efektivně, můžete snížit počet uzlů v clusteru. Service Fabric znovu vyrovnává repliky oddílů a instance napříč sníženým počtem uzlů, aby bylo možné lépe využívat hardware na jednotlivých uzlech. Clustery v Azure můžete škálovat buď ručně , nebo prostřednictvím kódu programu. Samostatné clustery je možné škálovat ručně.

Upgrady clusteru

Nové verze modulu runtime Service Fabric jsou pravidelně vydávány. Proveďte za běhu nebo prostředků infrastruktury, upgrady v clusteru, abyste vždy používali podporovanou verzi. Kromě upgradů prostředků infrastruktury můžete také aktualizovat konfiguraci clusteru, jako jsou certifikáty nebo porty aplikací.

Cluster Service Fabric je prostředek, který vlastníte, ale částečně ho spravuje Microsoft. Společnost Microsoft zodpovídá za opravy základního operačního systému a provádění upgradů prostředků infrastruktury ve vašem clusteru. Cluster můžete nastavit tak, aby přijímal automatické upgrady prostředků infrastruktury, když společnost Microsoft vydává novou verzi, nebo zvolit podporovanou verzi prostředků infrastruktury, kterou požadujete. Upgrady infrastruktury a konfigurace je možné nastavit prostřednictvím Azure Portal nebo prostřednictvím Správce prostředků. Další informace najdete v článku Upgrade Service Fabric clusteru.

Samostatný cluster je prostředek, který zcela vlastníte. Zodpovídáte za opravy základního operačního systému a zahájení upgradu prostředků infrastruktury. Pokud se váš cluster může připojit k https://www.microsoft.com/download , můžete nastavit svůj cluster tak, aby automaticky stahoval a zřídil nový balíček Service Fabric runtime. Pak byste měli zahájit upgrade. Pokud váš cluster nemá přístup https://www.microsoft.com/download , můžete nový balíček modulu runtime stáhnout ručně z počítače připojeného k Internetu a pak zahájit upgrade. Pokud chcete získat další informace, přečtěte si téma upgrade samostatného Service Fabricho clusteru.

Monitorování stavu

Service Fabric zavádí model stavu navržený tak, aby na konkrétní entity (například uzly clusteru a repliky služeb) nemohly označovat podmínky pro clustery, které nejsou v pořádku. Model stavu používá sestavy stavu (systémové součásti a sledovací zařízení). Cílem je snadno a rychle diagnostikovat a opravit. Zapisovače služeb se musí představit předem ohledně stavu a navrhovat vytváření sestav o stavu. Všechny podmínky, které mohou ovlivnit stav, by měly být hlášeny, zejména v případě, že mohou přispět k potížím s příznakem blízko ke kořenu. Informace o stavu mohou ušetřit čas a úsilí při ladění a vyšetřování, jakmile je služba v provozu a v produkčním měřítku probíhá.

Service Fabric sestavy monitorují identifikované podmínky zájmu. Vykazují tyto podmínky na základě jejich místního zobrazení. Health Store agreguje data o stavu odesílaná všemi sestavami, aby zjistila, jestli jsou entity globálně v pořádku. Model má být bohatě, flexibilní a snadno použitelný. Kvalita sestav stavu určuje přesnost zobrazení stavu clusteru. Falešné kladné hodnoty, které nesprávně ukazují problémy ve špatném stavu, můžou mít negativní dopad na upgrady nebo jiné služby, které používají data o stavu. Příklady takových služeb jsou opravné služby a mechanismy upozorňování. Proto je nutné, aby bylo možné poskytovat sestavy, které zachytí podmínky zájmu co nejlepším možným způsobem.

Vytváření sestav se dá provést z těchto:

  • Sledovaná replika služby Service Fabric nebo instance.
  • Interní sledovací zařízení nasazená jako služba Service Fabric (například Service Fabric Bezstavová služba, která monitoruje stavy a hlášení problémů). Sledovací zařízení je možné nasadit na všech uzlech nebo je můžete spřažené do monitorované služby.
  • Interní sledovací zařízení, která běží na Service Fabricch uzlech, ale nejsou implementovaná jako Service Fabric služby.
  • Externí sledovací zařízení, která procházejí prostředkem mimo Service Fabric cluster (například monitorovací služba jako Gomez).

Mimo box Service Fabric komponenty hlásí stav u všech entit v clusteru. Sestavy o stavu systému poskytují přehled o funkcích clusteru a aplikací a označují problémy prostřednictvím stavu. Pro aplikace a služby se v sestavách stavu systému ověřují, jestli jsou entity implementované a že se chovají správně z perspektivy Service Fabric runtime. Sestavy neposkytují žádné monitorování stavu obchodní logiky služby nebo zjišťují procesy, které přestaly odpovídat. K přidání informací o stavu, které jsou specifické pro vaši logiku služby, implementujte ve svých službách vlastní vytváření sestav o stavu .

Service Fabric poskytuje více způsobů zobrazení sestav stavu agregovaných v Health Store:

Monitorování a diagnostika

Monitorování a diagnostika jsou zásadní pro vývoj, testování a nasazení aplikací a služeb v jakémkoli prostředí. Řešení Service Fabric fungují nejlépe při plánování a implementaci monitorování a diagnostiky, které vám pomůžou zajistit, aby aplikace a služby fungovaly podle očekávání v místním vývojovém prostředí nebo v produkčním prostředí.

Mezi hlavní cíle monitorování a diagnostiky patří:

  • Zjišťování a Diagnostika problémů s hardwarem a infrastrukturou
  • Zjištění problémů softwaru a aplikací, omezení výpadků služeb
  • Pochopení využití prostředků a usnadnění rozhodování o operacích
  • Optimalizace výkonu aplikací, služeb a infrastruktury
  • Generování obchodních přehledů a určení oblastí zlepšování

Celkový pracovní postup monitorování a diagnostiky se skládá ze tří kroků:

  1. Generování událostí: sem patří události (protokoly, trasování, vlastní události) na úrovni infrastruktury (clusteru), platformy a aplikace nebo služby.
  2. Agregace událostí: vygenerované události je potřeba shromáždit a agregovat předtím, než se dají zobrazit.
  3. Analýza: události musí být vizuální a přístupné v některém formátu, aby bylo možné analyzovat a zobrazovat podle potřeby.

K dispozici je více produktů, které pokrývají tyto tři oblasti, a pro každou z nich si můžete vybrat různé technologie. Další informace najdete v článku monitorování a Diagnostika pro Azure Service Fabric.

Další kroky