Wilt u meer weten over Service Fabric?

  • Artikel

Azure Service Fabric is een gedistribueerde systemen platform waarmee u gemakkelijk pakket, implementeren en beheren van schaalbare en betrouwbare microservices. Service Fabric heeft echter een groot oppervlak en er is veel te leren. Dit artikel bevat een overzicht van Service Fabric en beschrijft de belangrijkste concepten, programmeermodellen, toepassingslevenscyclus, testen, clusters en statusbewaking. Lees overzicht enWat zijn microservices? voor een inleiding en hoe Service Fabric kan worden gebruikt om microservices te maken. Dit artikel bevat geen uitgebreide inhoudslijst, maar bevat wel een koppeling naar overzichts- en aan de slag-artikelen voor elk gebied van Service Fabric.

Basisconcepten

Service Fabric-terminologie, toepassingsmodel en ondersteunde programmeermodellen bieden meer concepten en beschrijvingen, maar dit zijn de basisbeginselen.

Ontwerptijd: servicetype, servicepakket en manifest, toepassingstype, toepassingspakket en manifest

Een servicetype is de naam/versie die is toegewezen aan de codepakketten, gegevenspakketten en configuratiepakketten van een service. Dit wordt gedefinieerd in een ServiceManifest.xml-bestand. Het servicetype bestaat uit uitvoerbare code en serviceconfiguratie-instellingen, die tijdens runtime worden geladen, en statische gegevens die door de service worden gebruikt.

Een servicepakket is een schijfmap met het ServiceManifest.xml-bestand van het servicetype, dat verwijst naar de code, statische gegevens en configuratiepakketten voor het servicetype. Een servicepakket kan bijvoorbeeld verwijzen naar de code, statische gegevens en configuratiepakketten waaruit een databaseservice bestaat.

Een toepassingstype is de naam/versie die is toegewezen aan een verzameling servicetypen. Dit wordt gedefinieerd in een ApplicationManifest.xml-bestand.

Service Fabric-toepassingstypen en servicetypen

Het toepassingspakket is een schijfmap die het ApplicationManifest.xml-bestand van het toepassingstype bevat, dat verwijst naar de servicepakketten voor elk servicetype waaruit het toepassingstype bestaat. Een toepassingspakket voor een e-mailtoepassingstype kan bijvoorbeeld verwijzingen bevatten naar een wachtrijservicepakket, een front-endservicepakket en een databaseservicepakket.

De bestanden in de map van het toepassingspakket worden gekopieerd naar het installatiekopieënarchief van het Service Fabric-cluster. U kunt vervolgens een benoemde toepassing maken op basis van dit toepassingstype, die vervolgens in het cluster wordt uitgevoerd. Nadat u een benoemde toepassing hebt gemaakt, kunt u een benoemde service maken op basis van een van de servicetypen van het toepassingstype.

Runtime: clusters en knooppunten, benoemde toepassingen, benoemde services, partities en replica's

Een Service Fabric-cluster is een met het netwerk verbonden reeks virtuele of fysieke machines waarop uw microservices worden geïmplementeerd en beheerd. Clusters kunnen naar duizenden machines worden geschaald.

Een machine of VM die onderdeel uitmaakt van een cluster, heet een knooppunt. Aan elk knooppunt wordt een knooppuntnaam toegewezen (een tekenreeks). Knooppunten hebben kenmerken zoals plaatsingseigenschappen. Elke machine of VM heeft een Windows-service voor automatisch starten, FabricHost.exe, die wordt uitgevoerd bij het opstarten en vervolgens twee uitvoerbare bestanden start: Fabric.exe en FabricGateway.exe. Deze twee uitvoerbare bestanden vormen het knooppunt. Voor ontwikkelings- of testscenario's kunt u meerdere knooppunten hosten op één machine of VM door meerdere exemplaren van Fabric.exe en FabricGateway.exeuit te voeren.

Een benoemde toepassing is een verzameling benoemde services die een bepaalde functie of functies uitvoeren. Een service voert een volledige en zelfstandige functie uit (deze kan onafhankelijk van andere services worden gestart en uitgevoerd) en bestaat uit code, configuratie en gegevens. Nadat een toepassingspakket is gekopieerd naar het installatiekopieënarchief, maakt u een exemplaar van de toepassing in het cluster door het toepassingstype van het toepassingspakket op te geven (met behulp van de naam/versie). Aan elk exemplaar van het toepassingstype wordt een URI-naam toegewezen die eruitziet als fabric:/MyNamedApp. Binnen een cluster kunt u meerdere benoemde toepassingen maken op basis van één toepassingstype. U kunt ook benoemde toepassingen maken op basis van verschillende toepassingstypen. Elke benoemde toepassing wordt onafhankelijk beheerd en versiebeheerd.

Nadat u een benoemde toepassing hebt gemaakt, kunt u een exemplaar van een van de bijbehorende servicetypen (een benoemde service) in het cluster maken door het servicetype op te geven (met behulp van de naam/versie). Aan elk servicetype-exemplaar wordt een URI-naam toegewezen binnen het bereik van de URI van de benoemde toepassing. Als u bijvoorbeeld een 'MyDatabase'-service maakt in een toepassing met de naam 'MyNamedApp', ziet de URI er als volgt uit: fabric:/MyNamedApp/MyDatabase. Binnen een benoemde toepassing kunt u een of meer benoemde services maken. Elke benoemde service kan een eigen partitieschema en aantal exemplaren/replica's hebben.

Er zijn twee soorten services: staatloos en stateful. Stateless services slaan de status niet op binnen de service. Stateless services hebben helemaal geen permanente opslag of slaan permanente status op in een externe opslagservice, zoals Azure Storage, Azure SQL Database of Azure Cosmos DB. Een stateful service slaat de status in de service op en gebruikt betrouwbare verzamelingen of Reliable Actors-programmeermodellen om de status te beheren.

Wanneer u een benoemde service maakt, geeft u een partitieschema op. Services met grote hoeveelheden status splitsen de gegevens over partities. Elke partitie is verantwoordelijk voor een deel van de volledige status van de service, verspreid over de knooppunten van het cluster.

In het volgende diagram ziet u de relatie tussen toepassingen en service-exemplaren, partities en replica's.

Partities en replica's binnen een service

Partitioneren, schalen en beschikbaarheid

Partitioneren is niet uniek voor Service Fabric. Een bekende vorm van partitioneren is gegevenspartitionering of sharding. Stateful services met grote hoeveelheden status splitsen de gegevens over partities. Elke partitie is verantwoordelijk voor een deel van de volledige status van de service.

De replica's van elke partitie zijn verspreid over de knooppunten van het cluster, waardoor de status van de benoemde service kan worden geschaald. Naarmate de gegevensbehoeften toenemen, worden partities groter en worden de partities van Service Fabric opnieuw verdeeld over knooppunten om efficiënt gebruik te maken van hardwareresources. Als u nieuwe knooppunten aan het cluster toevoegt, zal Service Fabric de partitiereplica's opnieuw verdelen over het toegenomen aantal knooppunten. De algehele prestaties van toepassingen verbeteren en conflicten voor toegang tot geheugen nemen af. Als de knooppunten in het cluster niet efficiënt worden gebruikt, kunt u het aantal knooppunten in het cluster verminderen. Service Fabric herverdeling van de partitiereplica's over het verminderde aantal knooppunten om beter gebruik te maken van de hardware op elk knooppunt.

Binnen een partitie hebben stateless benoemde services exemplaren, terwijl stateful benoemde services replica's hebben. Normaal gesproken hebben staatloze benoemde services slechts één partitie omdat ze geen interne status hebben, hoewel er uitzonderingen zijn. De partitie-exemplaren bieden beschikbaarheid. Als één exemplaar uitvalt, blijven andere exemplaren normaal werken en maakt Service Fabric vervolgens een nieuw exemplaar. Stateful benoemde services behouden hun status binnen replica's en elke partitie heeft een eigen replicaset. Lees- en schrijfbewerkingen worden uitgevoerd op één replica (de primaire replica genoemd). Wijzigingen in de status van schrijfbewerkingen worden gerepliceerd naar meerdere andere replica's (actieve secundaire databases genoemd). Als een replica mislukt, bouwt Service Fabric een nieuwe replica op basis van de bestaande replica's.

Staatloze en stateful microservices voor Service Fabric

Met Service Fabric kunt u toepassingen bouwen die uit microservices of containers bestaan. Staatloze microservices (zoals protocolgateways en webproxy's) handhaven buiten een aanvraag en de reactie erop van de service geen veranderlijke status. Azure Cloud Services-werkrollen zijn een voorbeeld van een staatloze service. Stateful microservices (zoals gebruikersaccounts, databases, apparaten, winkelwagentjes en wachtrijen) handhaven een veranderlijke, gezaghebbende status, buiten de aanvraag en de reactie erop. De huidige toepassingen op internetschaal bestaan uit een combinatie van staatloze en stateful microservices.

Een belangrijk verschil met Service Fabric is de sterke focus op het bouwen van stateful services, hetzij met de ingebouwde programmeermodellen of met stateful services in containers. De toepassingsscenario's beschrijven de scenario's waarin stateful services worden gebruikt.

Waarom hebben stateful microservices samen met staatloze microservices? De twee belangrijkste redenen zijn:

  • U kunt OLTP-services (Online Transaction Processing) met hoge doorvoer en lage latentie bouwen door code en gegevens dicht bij elkaar te houden op dezelfde computer. Enkele voorbeelden zijn interactieve winkels, zoekacties, IoT-systemen (Internet of Things), handelssystemen, creditcardverwerkings- en fraudedetectiesystemen en beheer van persoonlijke records.
  • U kunt het ontwerp van toepassingen vereenvoudigen. Stateful microservices verwijderen de noodzaak van extra wachtrijen en caches, die traditioneel vereist zijn om te voldoen aan de beschikbaarheids- en latentievereisten van een puur staatloze toepassing. Stateful services zijn van nature hoge beschikbaarheid en lage latentie, waardoor het aantal bewegende onderdelen dat in uw toepassing als geheel moet worden beheerd, wordt verminderd.

Ondersteunde programmeermodellen

Service Fabric biedt meerdere manieren om uw services te schrijven en te beheren. Services kunnen gebruikmaken van de Service Fabric-API's om optimaal te profiteren van de functies en toepassingsframeworks van het platform. Services kunnen ook elk gecompileerd uitvoerbaar programma zijn dat is geschreven in elke taal en wordt gehost op een Service Fabric-cluster. Zie Ondersteunde programmeermodellen voor meer informatie.

Containers

Service Fabric implementeert en activeert services standaard als processen. Service Fabric kan ook services in containers implementeren. Belangrijk is dat u services in processen en services in containers in dezelfde toepassing kunt combineren. Service Fabric ondersteunt de implementatie van Linux- en Windows-containers op Windows Server 2016. U kunt bestaande toepassingen, stateless services of stateful services in containers implementeren.

Reliable Services

Reliable Services is een lichtgewicht framework voor het schrijven van services die zijn geïntegreerd met het Service Fabric-platform en profiteren van de volledige set platformfuncties. Reliable Services kunnen staatloos zijn (vergelijkbaar met de meeste serviceplatforms, zoals webservers of werkrollen in Azure Cloud Services), waarbij de status wordt bewaard in een externe oplossing, zoals Azure DB of Azure Table Storage. Reliable Services kan ook stateful zijn, waarbij de status rechtstreeks in de service zelf wordt opgeslagen met behulp van Betrouwbare verzamelingen. De status wordt maximaal beschikbaar gemaakt via replicatie en gedistribueerd via partitionering, allemaal automatisch beheerd door Service Fabric.

Reliable Actors

Het Reliable Actor-framework is gebouwd op Reliable Services en is een toepassingsframework waarmee het patroon Virtual Actor wordt geïmplementeerd op basis van het ontwerppatroon van de actor. Het Reliable Actor-framework maakt gebruik van onafhankelijke reken- en statuseenheden met uitvoering met één thread, actoren genoemd. Het Reliable Actor-framework biedt ingebouwde communicatie voor actoren en vooraf ingestelde statuspersistentie- en scale-outconfiguraties.

ASP.NET Core

Service Fabric kan worden geïntegreerd met ASP.NET Core als een eersteklas programmeermodel voor het bouwen van web- en API-toepassingen. ASP.NET Core kunnen op twee verschillende manieren worden gebruikt in Service Fabric:

  • Gehost als uitvoerbare gast. Dit wordt voornamelijk gebruikt voor het uitvoeren van bestaande ASP.NET Core-toepassingen op Service Fabric zonder codewijzigingen.
  • Voer uit in een Reliable Service. Dit maakt een betere integratie met de Service Fabric-runtime mogelijk en staat stateful ASP.NET Core services toe.

Uitvoerbare gastbestanden

Een uitvoerbare gast is een bestaand, willekeurig uitvoerbaar bestand (geschreven in elke taal) dat naast andere services wordt gehost op een Service Fabric-cluster. Uitvoerbare gastbestanden kunnen niet rechtstreeks worden geïntegreerd met Service Fabric-API's. Ze profiteren echter nog steeds van functies die het platform biedt, zoals aangepaste status- en belastingsrapportage en servicedetectie door REST API's aan te roepen. Ze hebben ook volledige ondersteuning voor de levenscyclus van toepassingen.

Toepassingslevenscyclus

Net als bij andere platforms doorloopt een toepassing in Service Fabric meestal de volgende fasen: ontwerp, ontwikkeling, testen, implementatie, upgrade, onderhoud en verwijdering. Service Fabric biedt eersteklas ondersteuning voor de volledige levenscyclus van cloudtoepassingen, van ontwikkeling tot implementatie, dagelijks beheer en onderhoud tot uiteindelijke buitengebruikstelling. Met het servicemodel kunnen verschillende rollen onafhankelijk van elkaar deelnemen aan de levenscyclus van de toepassing. Service Fabric-toepassingslevenscyclus biedt een overzicht van de API's en hoe deze worden gebruikt door de verschillende rollen gedurende de fasen van de levenscyclus van de Service Fabric-toepassing.

De volledige levenscyclus van de app kan worden beheerd met behulp van PowerShell-cmdlets, CLI-opdrachten, C#-API's, Java-API's en REST API's. U kunt ook pijplijnen voor continue integratie/continue implementatie instellen met behulp van hulpprogramma's zoals Azure Pipelines of Jenkins.

Bekijk deze koppeling voor een trainingsvideo waarin wordt beschreven hoe u de levenscyclus van uw toepassing beheert:

Testtoepassingen en -services

Als u services op cloudschaal wilt maken, is het essentieel om te controleren of uw toepassingen en services bestand zijn tegen fouten in de echte wereld. De Foutanalyseservice is ontworpen voor het testen van services die zijn gebouwd op Service Fabric. Met de Foutanalyseservice kunt u zinvolle fouten veroorzaken en volledige testscenario's uitvoeren voor uw toepassingen. Deze fouten en scenario's oefenen en valideren de talrijke statussen en overgangen die een service gedurende de levensduur zal ervaren, allemaal op een gecontroleerde, veilige en consistente manier.

Acties zijn gericht op een service voor het testen met behulp van afzonderlijke fouten. Een serviceontwikkelaar kan deze gebruiken als bouwstenen voor het schrijven van complexe scenario's. Voorbeelden van gesimuleerde fouten zijn:

  • Start een knooppunt opnieuw op om een willekeurig aantal situaties te simuleren waarin een machine of VM opnieuw wordt opgestart.
  • Verplaats een replica van uw stateful service om taakverdeling, failover of toepassingsupgrade te simuleren.
  • Roep quorumverlies op een stateful service aan om een situatie te creëren waarin schrijfbewerkingen niet kunnen worden voortgezet omdat er onvoldoende 'back-up'- of 'secundaire' replica's zijn om nieuwe gegevens te accepteren.
  • Roep gegevensverlies aan op een stateful service om een situatie te creëren waarin alle statussen in het geheugen volledig worden gewist.

Scenario's zijn complexe bewerkingen die bestaan uit een of meer acties. De foutanalyseservice biedt twee ingebouwde volledige scenario's:

  • Chaosscenario: simuleert continue, interleaved fouten (zowel sierlijk als ondankbaar) in het hele cluster gedurende langere perioden.
  • Failoverscenario: een versie van het chaostestscenario dat is gericht op een specifieke servicepartitie terwijl andere services niet worden beïnvloed.

Clusters

Een Service Fabric-cluster is een met het netwerk verbonden reeks virtuele of fysieke machines waarop uw microservices worden geïmplementeerd en beheerd. Clusters kunnen naar duizenden machines worden geschaald. Een machine of VM die deel uitmaakt van een cluster, wordt een clusterknooppunt genoemd. Aan elk knooppunt wordt een knooppuntnaam toegewezen (een tekenreeks). Knooppunten hebben kenmerken zoals plaatsingseigenschappen. Elke machine of VM heeft een service voor automatisch starten, FabricHost.exe, die wordt uitgevoerd bij het opstarten en vervolgens twee uitvoerbare bestanden start: Fabric.exe en FabricGateway.exe. Deze twee uitvoerbare bestanden vormen het knooppunt. Voor testscenario's kunt u meerdere knooppunten hosten op één machine of VM door meerdere exemplaren van Fabric.exe en FabricGateway.exeuit te voeren.

Service Fabric-clusters kunnen worden gemaakt op virtuele of fysieke machines met Windows Server of Linux. U kunt Service Fabric-toepassingen implementeren en uitvoeren in elke omgeving waarin u een set Windows Server- of Linux-computers hebt die onderling zijn verbonden: on-premises, op Microsoft Azure of op een cloudprovider.

Bekijk deze koppeling voor een trainingsvideo waarin de Service Fabric-architectuur, de belangrijkste concepten en vele andere Service Fabric-functies worden beschreven

Clusters op Azure

Het uitvoeren van Service Fabric-clusters in Azure biedt integratie met andere Azure-functies en -services, waardoor bewerkingen en beheer van het cluster eenvoudiger en betrouwbaarder worden. Een cluster is een Azure Resource Manager resource, zodat u clusters kunt modelleren zoals andere resources in Azure. Resource Manager biedt ook eenvoudig beheer van alle resources die door het cluster als één eenheid worden gebruikt. Clusters in Azure zijn geïntegreerd met Diagnostische gegevens van Azure en Azure Monitor-logboeken. Clusterknooppunttypen zijn virtuele-machineschaalsets, dus de functionaliteit voor automatisch schalen is ingebouwd.

U kunt een cluster in Azure maken via de Azure Portal, vanuit een sjabloon of vanuit Visual Studio.

Met Service Fabric in Linux kunt u maximaal beschikbare, zeer schaalbare toepassingen bouwen, implementeren en beheren in Linux, net zoals in Windows. De Service Fabric-frameworks (Reliable Services en Reliable Actors) zijn beschikbaar in Java op Linux, naast C# (.NET Core). U kunt ook uitvoerbare gastservices bouwen met elke taal of elk framework. Het organiseren van Docker-containers wordt ook ondersteund. Docker-containers kunnen uitvoerbare gastbestanden of systeemeigen Service Fabric-services uitvoeren, die gebruikmaken van de Service Fabric-frameworks. Lees Service Fabric in Linux voor meer informatie.

Er zijn enkele functies die worden ondersteund in Windows, maar niet in Linux. Lees Verschillen tussen Service Fabric in Linux en Windows voor meer informatie.

Zelfstandige clusters

Service Fabric biedt een installatiepakket voor u om zelfstandige Service Fabric-clusters on-premises of op een cloudprovider te maken. Zelfstandige clusters bieden u de vrijheid om een cluster te hosten waar u maar wilt. Als uw gegevens onderhevig zijn aan nalevings- of regelgevingsbeperkingen, of als u uw gegevens lokaal wilt houden, kunt u uw eigen cluster en toepassingen hosten. Service Fabric-toepassingen kunnen zonder wijzigingen in meerdere hostingomgevingen worden uitgevoerd, zodat uw kennis van het bouwen van toepassingen wordt overgedragen van de ene hostingomgeving naar de andere.

Uw eerste zelfstandige Service Fabric-cluster maken

Zelfstandige Linux-clusters worden nog niet ondersteund.

Clusterbeveiliging

Clusters moeten worden beveiligd om te voorkomen dat onbevoegde gebruikers verbinding maken met uw cluster, met name wanneer er productieworkloads op worden uitgevoerd. Hoewel het mogelijk is om een niet-beveiligd cluster te maken, kunnen anonieme gebruikers hiermee verbinding maken als beheereindpunten worden blootgesteld aan het openbare internet. Het is niet mogelijk om later beveiliging in te schakelen op een niet-beveiligd cluster: clusterbeveiliging wordt ingeschakeld tijdens het maken van het cluster.

De clusterbeveiligingsscenario's zijn:

  • Beveiliging van knooppunt naar knooppunt
  • Client-naar-knooppuntbeveiliging
  • Op rollen gebaseerd toegangsbeheer van Service Fabric

Lees Een cluster beveiligen voor meer informatie.

Schalen

Als u nieuwe knooppunten aan het cluster toevoegt, worden de partitiereplica's en exemplaren opnieuw verdeeld over het toegenomen aantal knooppunten. De algehele prestaties van toepassingen verbeteren en conflicten voor toegang tot geheugen nemen af. Als de knooppunten in het cluster niet efficiënt worden gebruikt, kunt u het aantal knooppunten in het cluster verminderen. Service Fabric herverdeling van de partitiereplica's en exemplaren over het verminderde aantal knooppunten om beter gebruik te maken van de hardware op elk knooppunt. U kunt clusters in Azure handmatig of programmatisch schalen. Zelfstandige clusters kunnen handmatig worden geschaald.

Clusterupgrades

Er worden regelmatig nieuwe versies van de Service Fabric-runtime uitgebracht. Voer runtime- of fabric-upgrades uit op uw cluster, zodat u altijd een ondersteunde versie uitvoert. Naast infrastructuurupgrades kunt u ook clusterconfiguratie bijwerken, zoals certificaten of toepassingspoorten.

Een Service Fabric-cluster is een resource die u bezit, maar die gedeeltelijk wordt beheerd door Microsoft. Microsoft is verantwoordelijk voor het patchen van het onderliggende besturingssysteem en het uitvoeren van infrastructuurupgrades op uw cluster. U kunt instellen dat uw cluster automatische infrastructuurupgrades ontvangt wanneer Microsoft een nieuwe versie uitbrengt, of ervoor kiezen om een ondersteunde infrastructuurversie te selecteren die u wilt. Upgrades voor infrastructuur en configuratie kunnen worden ingesteld via de Azure Portal of via Resource Manager. Lees Een Service Fabric-cluster upgraden voor meer informatie.

Een zelfstandig cluster is een resource die u volledig bezit. U bent verantwoordelijk voor het patchen van het onderliggende besturingssysteem en het initiëren van infrastructuurupgrades. Als uw cluster verbinding kan maken met https://www.microsoft.com/download, kunt u instellen dat het nieuwe Service Fabric-runtimepakket automatisch wordt gedownload en ingericht. Vervolgens start u de upgrade. Als uw cluster geen toegang heeft tot https://www.microsoft.com/download, kunt u het nieuwe runtimepakket handmatig downloaden van een computer met internetverbinding en vervolgens de upgrade starten. Lees Een zelfstandig Service Fabric-cluster upgraden voor meer informatie.

Statuscontrole

Service Fabric introduceert een statusmodel dat is ontworpen om beschadigde cluster- en toepassingsvoorwaarden te markeren op specifieke entiteiten (zoals clusterknooppunten en servicereplica's). Het statusmodel maakt gebruik van gezondheidsverslaggevers (systeemonderdelen en watchdogs). Het doel is een eenvoudige en snelle diagnose en reparatie. Serviceschrijvers moeten vooraf nadenken over de status en het ontwerpen van statusrapportage. Elke voorwaarde die van invloed kan zijn op de status, moet worden gerapporteerd, met name als deze problemen dicht bij de hoofdmap kan markeren. De statusinformatie kan tijd en moeite besparen bij foutopsporing en onderzoek zodra de service op schaal in productie is.

De Service Fabric-verslaggevers bewaken geïdentificeerde voorwaarden van belang. Ze rapporteren over deze voorwaarden op basis van hun lokale weergave. Het statusarchief verzamelt statusgegevens die door alle verslaggevers worden verzonden om te bepalen of entiteiten wereldwijd in orde zijn. Het model is bedoeld om uitgebreid, flexibel en gebruiksvriendelijk te zijn. De kwaliteit van de statusrapporten bepaalt de nauwkeurigheid van de statusweergave van het cluster. Fout-positieven die ten onrechte problemen met een slechte status aangeven, kunnen een negatieve invloed hebben op upgrades of andere services die gebruikmaken van statusgegevens. Voorbeelden van dergelijke services zijn reparatieservices en waarschuwingsmechanismen. Daarom moet er worden nagedacht over rapporten waarin de voorwaarden van belang op de best mogelijke manier worden vastgelegd.

Rapportage kan worden gedaan vanuit:

  • De bewaakte Service Fabric-servicereplica of -instantie.
  • Interne waakhonden die zijn geïmplementeerd als een Service Fabric-service (bijvoorbeeld een stateless Service Fabric-service die voorwaarden bewaakt en rapporten uitgeeft). De watchdogs kunnen worden geïmplementeerd op alle knooppunten of kunnen worden gekoppeld aan de bewaakte service.
  • Interne watchdogs die worden uitgevoerd op de Service Fabric-knooppunten, maar niet worden geïmplementeerd als Service Fabric-services.
  • Externe watchdogs die de resource van buiten het Service Fabric-cluster testen (bijvoorbeeld bewakingsservice zoals Gomez).

Standaard rapporteren Service Fabric-onderdelen de status van alle entiteiten in het cluster. Systeemstatusrapporten bieden inzicht in cluster- en toepassingsfunctionaliteit en markeren problemen via de status. Voor toepassingen en services controleren systeemstatusrapporten of entiteiten zijn geïmplementeerd en correct werken vanuit het perspectief van de Service Fabric-runtime. De rapporten bieden geen statuscontrole van de bedrijfslogica van de service en detecteren geen processen die niet meer reageren. Als u statusinformatie wilt toevoegen die specifiek is voor de logica van uw service, implementeert u aangepaste statusrapportage in uw services.

Service Fabric biedt meerdere manieren om statusrapporten weer te geven die zijn samengevoegd in het statusarchief:

Bekijk deze pagina voor een trainingsvideo waarin het Service Fabric-statusmodel en hoe dit wordt gebruikt wordt beschreven:

Controle en diagnose

Bewaking en diagnose zijn essentieel voor het ontwikkelen, testen en implementeren van toepassingen en services in elke omgeving. Service Fabric-oplossingen werken het beste wanneer u bewaking en diagnostische gegevens plant en implementeert om ervoor te zorgen dat toepassingen en services werken zoals verwacht in een lokale ontwikkelomgeving of in productie.

De belangrijkste doelen van bewaking en diagnose zijn:

  • Problemen met hardware en infrastructuur detecteren en diagnosticeren
  • Problemen met software en apps detecteren, downtime van de service verminderen
  • Inzicht in resourceverbruik en helpen bij het nemen van beslissingen over bewerkingen
  • Prestaties van toepassingen, services en infrastructuur optimaliseren
  • Zakelijke inzichten genereren en verbeterpunten identificeren

De algehele werkstroom voor bewaking en diagnose bestaat uit drie stappen:

  1. Gebeurtenisgeneratie: dit omvat gebeurtenissen (logboeken, traceringen, aangepaste gebeurtenissen) op infrastructuur (cluster), platform en toepassings-/serviceniveau
  2. Gebeurtenisaggregatie: gegenereerde gebeurtenissen moeten worden verzameld en geaggregeerd voordat ze kunnen worden weergegeven
  3. Analyse: gebeurtenissen moeten worden gevisualiseerd en toegankelijk zijn in een bepaalde indeling om analyse mogelijk te maken en zo nodig weer te geven

Er zijn meerdere producten beschikbaar die betrekking hebben op deze drie gebieden, en u bent vrij om verschillende technologieën voor elk te kiezen. Lees Bewaking en diagnostische gegevens voor Azure Service Fabric voor meer informatie.

Volgende stappen