Takže chcete získat informace o Service Fabric?

  • Článek

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 plochu a je toho hodně, co se naučit. Tento článek obsahuje souhrn Service Fabric a popisuje základní koncepty, programovací modely, životní cyklus aplikací, testování, clustery a monitorování stavu. Úvod a informace o tom, jak se Service Fabric dá použít k vytváření mikroslužeb, najdete v tématu Přehled a Co jsou mikroslužby . Tento článek neobsahuje úplný seznam obsahu, ale odkazy na články s přehledem a články Začínáme pro každou oblast Service Fabric.

Základní koncepty

Terminologie Service Fabric, aplikační model a podporované programovací modely poskytují více konceptů a popisů, ale tady jsou základní informace.

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

Typ služby je název nebo verze přiřazená balíčkům kódu, datovým balíčkům a konfiguračním balíčkům služby. To je definováno v souboru ServiceManifest.xml. Typ služby se skládá ze spustitelného kódu a nastavení konfigurace služby, která se načítají za běhu, a ze statických dat, která služba využívá.

Balíček služby je adresář disku obsahující 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. To je definováno v souboru ApplicationManifest.xml.

Typy aplikací Service Fabric a typy 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 frontové služby, balíček front-endové služby a balíček databázové služby.

Soubory v adresáři balíčku aplikace se zkopírují do úložiště imagí clusteru Service Fabric. Potom můžete vytvořit pojmenovanou aplikaci z tohoto typu aplikace, která se pak spustí v rámci clusteru. Po vytvoření pojmenované aplikace můžete vytvořit pojmenovanou službu z jednoho z typů služby daného typu aplikace.

Doba běhu: clustery a uzly, pojmenované aplikace, pojmenované služby, oddíly a repliky

Cluster Service Fabric je síťově propojená sada virtuálních nebo fyzických počítačů, ve kterých se nasazují a spravují mikroslužby. 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á službu FabricHost.exesystému Windows , která se spustí při spuštění a pak spustí dva spustitelné soubory: Fabric.exe a FabricGateway.exe. Uzel tvoří tyto dva spustitelné soubory. Pro scénáře vývoje nebo testování můžete na jednom počítači nebo virtuálním počítači hostovat více uzlů 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 se spouštět a spouštět 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 zadáním typu aplikace balíčku aplikace (pomocí jeho názvu nebo verze). Každá instance typu aplikace má přiřazený název identifikátoru URI, který vypadá takto : fabric:/MyNamedApp. V rámci clusteru můžete vytvořit více pojmenovaných aplikací z jednoho typu aplikace. Můžete také vytvářet pojmenované aplikace z různých typů aplikací. Každá pojmenovaná aplikace se spravuje a spravuje nezávisle na verzích.

Po vytvoření pojmenované aplikace můžete v clusteru vytvořit instanci jednoho z jejích typů služby (pojmenované služby) 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 s oborem pod identifikátorem URI pojmenované aplikace. Pokud například v aplikaci s názvem MyNamedApp vytvoříte službu MyDatabase, bude identifikátor URI vypadat takto: fabric:/MyNamedApp/MyDatabase. V pojmenované aplikaci 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í stav v rámci služby. Bezstavové služby nemají žádné trvalé úložiště nebo uchovávají trvalý stav v externí službě ú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 ke správě stavu používá programovací modely Reliable Collections nebo Reliable Actors.

Při vytváření pojmenované služby zadáte schéma oddílů. Služby s velkými objemy stavu rozdělují data mezi oddíly. Každý oddíl zodpovídá za část kompletního stavu služby, která je rozložená 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í jedinečné pro Service Fabric. Dobře známou formou dělení je dělení dat neboli shardování. Stavové služby s velkým množstvím stavu rozdělují data mezi oddíly. Každý oddíl zodpovídá za část kompletního stavu služby.

Repliky jednotlivých oddílů jsou rozložené mezi uzly clusteru, což umožňuje škálování stavu pojmenované služby. S tím, jak data potřebují růst, zvětšují se oddíly a Service Fabric znovu vyrovná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 obnoví rovnováhu replik oddílů mezi zvýšeným počtem uzlů. Celkový výkon aplikace se zlepší a kolize v přístupu k paměti se sníží. 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ů v rámci sníženého počtu uzlů, aby se lépe využil hardware na každém uzlu.

V rámci oddílu mají bezstavové pojmenované služby instance, zatímco stavové pojmenované služby mají repliky. Bezstavové pojmenované služby obvykle mají vždy jen jeden oddíl, protože nemají žádný interní stav, i když existují výjimky. Instance oddílů zajišťují dostupnost. Pokud jedna instance selže, ostatní instance budou dál normálně fungovat a Service Fabric pak vytvoří novou instanci. Stavové pojmenované služby udržují svůj stav v rámci replik a každý oddíl má vlastní sadu replik. Operace čtení a zápisu se provádějí na jedné replice (označované jako primární). Změny stavu operací zápisu se replikují do několika dalších replik (označovaných jako sekundární aktivní). Pokud dojde k selhání repliky, Service Fabric sestaví 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.

Hlavním rozdílem ve službě Service Fabric je její silné zaměření na vytváření stavových služeb, a to buď pomocí integrovaných programovacích modelů , nebo kontejnerizovaných stavových služeb. Scénáře aplikací popisují scénáře, ve kterých se používají stavové služby.

Proč máte stavové mikroslužby spolu s bezstavovými? Jsou to dva hlavní důvody:

  • Služby OLTP (High Throughput Online Transaction Processing) odolné proti chybám (OLTP) s vysokou propustností a nízkou latencí můžete vytvářet tak, že budete udržovat kód a data blízko na stejném počítači. Mezi příklady patří interaktivní výkladní skříně, vyhledávání, systémy internetu věcí (IoT), systémy obchodování, systémy zpracování platebních karet a systémy pro odhalování podvodů a správa osobních záznamů.
  • Návrh aplikace můžete zjednodušit. Stavové mikroslužby odstraňují potřebu dalších front a mezipamětí, které se tradičně vyžadují k řešení požadavků čistě bezstavové aplikace na dostupnost a latenci. Stavové služby jsou přirozeně vysoce dostupné a mají nízkou latenci, což snižuje počet přesunovaných částí, které je potřeba spravovat ve vaší aplikaci jako celku.

Podporované programovací modely

Service Fabric nabízí několik způsobů, jak psát a spravovat služby. Služby můžou využívat rozhraní API Service Fabric k plnému využití funkcí a aplikačních architektur platformy. Službami může být také jakýkoli zkompilovaný spustitelný program napsaný v libovolném jazyce a hostovaný v clusteru Service Fabric. Další informace najdete v tématu Podporované programovací modely.

Kontejnery

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

Reliable Services

Reliable Services je odlehčená architektura pro vytváření služeb, které se integrují s platformou Service Fabric a využívají celou sadu funkcí platformy. Spolehlivé služby můžou být bezstavové (podobně jako u většiny platforem služeb, jako jsou webové servery nebo role pracovních procesů v Azure Cloud Services), kde je stav trvalý v externím řešení, jako je Azure DB nebo Azure Table Storage. Spolehlivé služby mohou být také stavové, kdy se stav udržuje přímo v samotné službě pomocí spolehlivých kolekcí. Stav je vysoce dostupný prostřednictvím replikace a distribuovaný prostřednictvím dělení, který automaticky spravuje Service Fabric.

Reliable Actors

Architektura Reliable Actor je postavená na Reliable Services a představuje aplikační architekturu, která implementuje model virtuálního objektu actor na základě vzoru návrhu objektu actor. Architektura Reliable Actor používá nezávislé výpočetní a stavové jednotky s jednovláknovým spouštěním označovaným jako aktéři. Architektura Reliable Actor poskytuje integrovanou komunikaci pro aktéry a předem nastavené konfigurace trvalosti stavu a škálování na více instancí.

ASP.NET Core

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

  • Hostovaný jako spustitelný soubor hosta. Primárně se používá ke spouštění existujících aplikací ASP.NET Core v Service Fabric beze změn kódu.
  • Spusťte ve službě Reliable Service. To umožňuje lepší integraci s modulem runtime Service Fabric a umožňuje stavové ASP.NET Core služby.

Spustitelné soubory typu Host

Spustitelný soubor hosta je existující libovolný spustitelný soubor (napsaný v libovolném jazyce) hostovaný v clusteru Service Fabric společně s dalšími službami. Spustitelné soubory hosta se neintegrují přímo s rozhraními SERVICE Fabric API. Stále ale těží z funkcí, které platforma nabízí, jako je vlastní generování sestav o stavu a zatížení a zjistitelnost služeb voláním rozhraní REST API. Mají také plnou podporu životního cyklu aplikace.

Životní cyklus aplikace

Stejně jako u jiných platforem prochází aplikace v Service Fabric obvykle 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 cloudových aplikací, od vývoje přes nasazení, každodenní správu a údržbu až po případné vyřazení z provozu. Model služby umožňuje nezávislé účasti několika různých rolí na životním cyklu aplikace. Životní cyklus aplikace Service Fabric poskytuje přehled rozhraní API a jejich používání různými rolemi v průběhu fází životního cyklu aplikace Service Fabric.

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

Na tomto odkazu najdete školicí video, které popisuje, jak spravovat životní cyklus aplikace:

Testování aplikací a služeb

K vytvoření skutečně cloudových služeb je důležité ověřit, že vaše aplikace a služby dokážou odolat selháním z reálného světa. Služba Analýza chyb je určená pro testování služeb, které jsou založené na Service Fabric. Se službou Fault Analysis Service můžete vyvolat smysluplné chyby a spouštět pro své aplikace kompletní testovací scénáře. Tyto chyby a scénáře procvičují a ověřují řadu stavů a přechodů, které služba bude mít po celou dobu své životnosti, a to vše řízeným, bezpečným a konzistentním způsobem.

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

  • Restartováním uzlu můžete simulovat libovolný počet situací, kdy se počítač nebo virtuální počítač restartuje.
  • Přesuňte repliku stavové služby a simulujte vyrovnávání zatížení, převzetí služeb při selhání nebo upgrade aplikace.
  • Vyvolání ztráty kvora ve stavové službě za účelem vytvoření situace, kdy operace zápisu nemohou pokračovat, protože není k dispozici dostatek "záložních" nebo "sekundárních" replik pro příjem nových dat.
  • Vyvolání ztráty dat ve stavové službě za účelem vytvoření situace, kdy se veškerý stav v paměti zcela vymaže.

Scénáře jsou složité operace, které se skládají z jedné nebo více akcí. Služba Analýza chyb poskytuje dva předdefinované kompletní scénáře:

  • Scénář chaosu – simuluje průběžné prokládané chyby (řádné i nevděčné) v celém clusteru v delších časových obdobích.
  • Scénář převzetí služeb při selhání – verze scénáře testu chaosu, která cílí na konkrétní oddíl služby a zároveň ponechá ostatní služby beze změny.

Clustery

Cluster Service Fabric je síťově propojená sada virtuálních nebo fyzických počítačů, ve kterých se nasazují a spravují vaše mikroslužby. 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 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á službu automatického spuštění , FabricHost.exekterá se spustí při spuštění a pak spustí dva spustitelné soubory: Fabric.exe a FabricGateway.exe. Uzel tvoří tyto dva spustitelné soubory. 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 několika instancí Fabric.exe a FabricGateway.exe.

Clustery Service Fabric je možné vytvářet na virtuálních nebo fyzických počítačích s Windows Serverem nebo Linuxem. Aplikace Service Fabric můžete nasadit a spouštět v libovolném prostředí, ve kterém máte sadu počítačů s Windows Serverem nebo Linuxem, které jsou vzájemně propojené: místně, v Microsoft Azure nebo u libovolného poskytovatele cloudu.

Na tomto odkazu najdete školicí video, které popisuje architekturu Service Fabric, její základní koncepty a řadu dalších funkcí Service Fabric.

Clustery v Azure

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

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

Service Fabric v Linuxu umožňuje vytvářet, nasazovat a spravovat vysoce dostupné a vysoce škálovatelné aplikace v Linuxu stejně jako ve Windows. Kromě jazyka C# (.NET Core) jsou v Javě v Linuxu k dispozici také architektury Service Fabric (Reliable Services a Reliable Actors). Můžete také vytvářet spustitelné služby hosta s libovolným jazykem nebo architekturou. Podporuje se také orchestrace kontejnerů Dockeru. Kontejnery Dockeru můžou spouštět spustitelné soubory hosta nebo nativní služby Service Fabric, které používají architektury Service Fabric. Další informace najdete v tématu Service Fabric v Linuxu.

Existují některé funkce, které jsou podporovány ve Windows, ale ne v Linuxu. Další informace najdete v článku Rozdíly mezi Service Fabric v Linuxu a Windows.

Samostatné clustery

Service Fabric poskytuje instalační balíček pro vytváření samostatných clusterů Service Fabric místně nebo u libovolného poskytovatele cloudu. Samostatné clustery umožňují hostovat cluster, kdekoli chcete. Pokud vaše data podléhají omezením dodržování předpisů nebo zákonným omezením nebo pokud chcete data zachovat místně, můžete hostovat vlastní cluster a aplikace. Aplikace Service Fabric můžou běžet v několika hostitelských prostředích beze změn, takže se vaše znalosti vytváření aplikací přenášejí z jednoho hostitelského prostředí do jiného.

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

Samostatné clustery s Linuxem se zatím nepodporují.

Zabezpečení clusteru

Clustery musí být zabezpečené, aby se zabránilo neoprávněným uživatelům v připojení ke clusteru, zejména v případě, že na něm běží produkční úlohy. I když je možné vytvořit nezabezpečený cluster, umožní to anonymním uživatelům připojit se k němu, pokud jsou koncové body správy zpřístupněny veřejnému internetu. Zabezpečení v nezabezpečeném clusteru není možné později povolit: zabezpečení clusteru je povolené při vytváření clusteru.

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

  • Zabezpečení mezi uzly
  • Zabezpečení mezi klienty a uzly
  • Service Fabric – řízení přístupu na základě role

Další informace najdete v tématu Zabezpečení clusteru.

Škálování

Pokud do clusteru přidáte nové uzly, Service Fabric znovu vyrovná repliky oddílů a instance napříč zvýšeným počtem uzlů. Celkový výkon aplikace se zlepšuje a kolize přístupu k paměti se snižuje. 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 lépe využíval hardware na jednotlivých uzlech. Clustery v Azure můžete škálovat ručně nebo programově. Samostatné clustery je možné škálovat ručně.

Upgrady clusteru

Pravidelně se vydávají nové verze modulu runtime Service Fabric. Upgradujte modul runtime nebo prostředky infrastruktury clusteru, abyste vždy měli 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. 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 dostával automatické upgrady prostředků infrastruktury, když Microsoft vydá novou verzi, nebo vybrat požadovanou podporovanou verzi prostředků infrastruktury. Upgrady prostředků infrastruktury a konfigurace je možné nastavit prostřednictvím Azure Portal nebo prostřednictvím Resource Manager. Další informace najdete v tématu Upgrade clusteru Service Fabric.

Samostatný cluster je prostředek, který zcela vlastníte. Zodpovídáte za opravy základního operačního systému a inicializování upgradů prostředků infrastruktury. Pokud se váš cluster může připojit k nástroji https://www.microsoft.com/download, můžete ho nastavit tak, aby automaticky stáhl a zřídil nový balíček modulu runtime Service Fabric. Pak byste zahájili upgrade. Pokud váš cluster nemá přístup k https://www.microsoft.com/downloadnástroji , 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. Další informace najdete v tématu Upgrade samostatného clusteru Service Fabric.

Monitorování stavu

Service Fabric zavádí model stavu navržený tak, aby označoval stav clusteru a aplikace, které nejsou v pořádku, u konkrétních entit (jako jsou uzly clusteru a repliky služeb). Model stavu používá reportéry stavu (systémové komponenty a hlídací zařízení). Cílem je snadná a rychlá diagnostika a oprava. Autoři služeb musí předem přemýšlet o stavu a o tom, jak vytvářet sestavy stavu. Všechny podmínky, které mohou mít vliv na stav, by měly být hlášeny, zejména pokud to může pomoct označit problémy blízko kořenovému adresáři. Jakmile je služba ve velkém provozu v produkčním prostředí, můžou informace o stavu ušetřit čas a úsilí při ladění a vyšetřování.

Zpravodajé Service Fabric monitorují zjištěné podmínky zájmu. Tyto podmínky hlásí na základě svého místního zobrazení. Úložiště stavů agreguje data o stavu odesílaná všemi zpravodaji a určuje, jestli jsou entity globálně v pořádku. Model má být bohatý, flexibilní a snadno použitelný. Kvalita zpráv o stavu určuje přesnost zobrazení stavu clusteru. Falešně pozitivní výsledky, které nesprávně ukazují problémy, které nejsou v pořádku, můžou negativně ovlivnit upgrady nebo jiné služby, které používají data o stavu. Příkladem takových služeb jsou opravné služby a mechanismy upozorňování. Proto je potřeba uvažovat o poskytování sestav, které co nejlépe zachycují podmínky zájmu.

Vytváření sestav lze provádět z:

  • Monitorovaná replika nebo instance služby Service Fabric.
  • Interní sledovací zařízení nasazená jako služba Service Fabric (například bezstavová služba Service Fabric, která monitoruje podmínky a vydává sestavy). Watchdogs je možné nasadit na všech uzlech nebo spřažení s monitorovanou službou.
  • Interní sledovací zařízení, která běží na uzlech Service Fabric, ale nejsou implementovaná jako služby Service Fabric.
  • Externí sledovací centra, která testuje prostředek mimo cluster Service Fabric (například monitorovací služba, jako je Gomez).

Komponenty Service Fabric hlásí stav všech entit v clusteru. Sestavy stavu systému poskytují přehled o funkcích clusteru a aplikací a označují problémy prostřednictvím stavu. U aplikací a služeb sestavy stavu systému ověřují, že jsou entity implementované a že se správně chovají z pohledu modulu runtime Service Fabric. Sestavy neposkytují žádné monitorování stavu obchodní logiky služby ani zjišťování procesů, které přestaly reagovat. Pokud chcete přidat informace o stavu specifické pro logiku vaší služby, implementujte do svých služeb vlastní sestavy stavu .

Service Fabric nabízí několik způsobů , jak zobrazit sestavy stavu agregované v úložišti stavů:

Na této stránce najdete školicí video, které popisuje model stavu Service Fabric a jeho použití:

Monitorování a diagnostika

Monitorování a diagnostika jsou důležité 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é pomáhají zajistit, aby aplikace a služby v místním vývojovém prostředí nebo v produkčním prostředí fungovaly podle očekávání.

Hlavními cíli monitorování a diagnostiky jsou:

  • Detekce a diagnostika problémů s hardwarem a infrastrukturou
  • Detekce problémů se softwarem a aplikacemi, omezení výpadků služeb
  • Vysvětlení spotřeby prostředků a pomoc s rozhodováním o provozu
  • Optimalizace výkonu aplikací, služeb a infrastruktury
  • Generování obchodních přehledů a identifikace oblastí vylepšení

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

  1. Generování událostí: To zahrnuje události (protokoly, trasování, vlastní události) na úrovni infrastruktury (clusteru), platformy a aplikací nebo služeb.
  2. Agregace událostí: Před zobrazením vygenerovaných událostí je potřeba shromáždit a agregovat.
  3. Analýza: Události je potřeba vizualizovat a zpřístupnit v určitém formátu, aby bylo možné je analyzovat a zobrazit podle potřeby.

K dispozici je několik produktů, které pokrývají tyto tři oblasti, a pro každou z nich si můžete zvolit jiné technologie. Další informace najdete v tématu Monitorování a diagnostika pro Azure Service Fabric.

Další kroky