Share via

Overzicht van Service Fabric-terminologie

  • Artikel

Azure Service Fabric is een gedistribueerde systemen platform waarmee u gemakkelijk pakket, implementeren en beheren van schaalbare en betrouwbare microservices. Service Fabric is een container- en procesorchestrator waarmee u uw clusters overal kunt hosten: in Azure, in een on-premises datacenter of in een cloudprovider. U kunt elk framework gebruiken om uw services te schrijven en te kiezen waar u de toepassing wilt uitvoeren vanuit meerdere omgevingskeuzen. In dit artikel wordt de terminologie beschreven die door Service Fabric wordt gebruikt om inzicht te verkrijgen in de termen die in de documentatie worden gebruikt.

De gerelateerde trainingsvideo's die hieronder worden vermeld, beschrijven de toepassing, verpakking, implementatie, abstracties en terminologie die door Service Fabric worden gebruikt:

Infrastructuurconcepten

Cluster: Een met het netwerk verbonden set virtuele of fysieke machines waarin uw microservices worden geïmplementeerd en beheerd. Clusters kunnen naar duizenden machines worden geschaald.

Knooppunt: Een machine of VM die deel uitmaakt van een cluster, wordt een knooppunt genoemd. Aan elk knooppunt wordt een knooppuntnaam (tekenreeks) toegewezen. Knooppunten hebben kenmerken, zoals plaatsingseigenschappen. Elke machine of VM heeft een Windows-service voor automatisch starten, FabricHost.exedie 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.

Concepten voor toepassingen en services

Systeemeigen Service Fabric-toepassing: Systeemeigen Service Fabric-toepassingen worden beschreven door het systeemeigen toepassingsmodel (xml-toepassings- en servicemanifesten).

Systeemeigen Service Fabric-toepassingsconcepten

Toepassing: Een toepassing is een verzameling samenstellende services die een bepaalde functie of functies uitvoeren. De levenscyclus van elk toepassingsexemplaren kan onafhankelijk worden beheerd.

Service: Een service voert een volledige en zelfstandige functie uit en kan onafhankelijk van andere services worden gestart en uitgevoerd. Een service bestaat uit code, configuratie en gegevens. Voor elke service bestaat code uit de uitvoerbare binaire bestanden, de configuratie bestaat uit service-instellingen die tijdens runtime kunnen worden geladen en gegevens bestaan uit willekeurige statische gegevens die door de service moeten worden verbruikt.

Toepassingstype: de naam/versie die is toegewezen aan een verzameling servicetypen. Het wordt gedefinieerd in een ApplicationManifest.xml bestand en ingesloten in een toepassingspakketmap. De map wordt vervolgens gekopieerd naar het installatiekopieënarchief van het Service Fabric-cluster. Vervolgens kunt u een benoemde toepassing maken op basis van dit toepassingstype in het cluster.

Lees het artikel over het toepassingsmodel voor meer informatie.

Toepassingspakket: een schijfmap met het bestand van ApplicationManifest.xml het toepassingstype. Verwijst naar de servicepakketten voor elk servicetype waaruit het toepassingstype bestaat. De bestanden in de map van het toepassingspakket worden gekopieerd naar het installatiekopieënarchief van het Service Fabric-cluster. Een toepassingspakket voor een type e-mailtoepassing kan bijvoorbeeld verwijzingen bevatten naar een wachtrijservicepakket, een front-endservicepakket en een databaseservicepakket.

Benoemde toepassing: Nadat u een toepassingspakket naar het installatiekopiearchief hebt gekopieerd, maakt u een exemplaar van de toepassing in het cluster. U maakt een exemplaar wanneer u het toepassingstype van het toepassingspakket opgeeft met behulp van de naam of versie van het toepassingspakket. Aan elk exemplaar van het toepassingstype wordt een URI-naam (Uniform Resource Identifier) toegewezen die er als volgt uitziet: "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 geversied.

Servicetype: de naam/versie die is toegewezen aan de codepakketten, gegevenspakketten en configuratiepakketten van een service. Het servicetype wordt gedefinieerd in het ServiceManifest.xml bestand en ingesloten in een servicepakketmap. Vervolgens wordt er naar de map van het servicepakket verwezen door het bestand van ApplicationManifest.xml een toepassingspakket. Na het maken van een benoemde toepassing kunt u in het cluster een benoemde service maken op basis van een van de servicetypen van het toepassingstype. Het bestand van ServiceManifest.xml het servicetype beschrijft de service.

Lees het artikel over het toepassingsmodel voor meer informatie.

Er zijn twee soorten services:

  • Staatloos: gebruik een staatloze service wanneer de permanente status van de service wordt opgeslagen in een externe opslagservice, zoals Azure Storage, Azure SQL Database of Azure Cosmos DB. Gebruik een stateless service wanneer de service geen permanente opslag heeft. Voor een rekenmachineservice waarbij waarden worden doorgegeven aan de service, wordt bijvoorbeeld een berekening uitgevoerd die deze waarden gebruikt en wordt vervolgens een resultaat geretourneerd.
  • Stateful: Gebruik een stateful service wanneer u wilt dat Service Fabric de status van uw service beheert via de reliable collections of Reliable Actors-programmeermodellen. Wanneer u een benoemde service maakt, geeft u op hoeveel partities u de status wilt verspreiden voor schaalbaarheid. Geef ook op hoe vaak uw status moet worden gerepliceerd over knooppunten, voor betrouwbaarheid. Elke benoemde service heeft één primaire replica en meerdere secundaire replica's. U wijzigt de status van de benoemde service wanneer u naar de primaire replica schrijft. Service Fabric repliceert deze status vervolgens naar alle secundaire replica's om uw status gesynchroniseerd te houden. Service Fabric detecteert automatisch wanneer een primaire replica mislukt en bevordert een bestaande secundaire replica naar een primaire replica. Service Fabric maakt vervolgens een nieuwe secundaire replica.

Replica's of exemplaren verwijzen naar code (en status voor stateful services) van een service die wordt geïmplementeerd en uitgevoerd. Zie Replica's en exemplaren.

Herconfiguratie verwijst naar het proces van elke wijziging in de replicaset van een service. Zie Herconfiguratie.

Servicepakket: een schijfmap met het bestand van ServiceManifest.xml het servicetype. Dit bestand verwijst naar de code, statische gegevens en configuratiepakketten voor het servicetype. Naar de bestanden in de map met servicepakketten wordt verwezen door het toepassingstypebestand ApplicationManifest.xml . Een servicepakket kan bijvoorbeeld verwijzen naar de code, statische gegevens en configuratiepakketten waaruit een databaseservice bestaat.

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

Codepakket: Een schijfmap met de uitvoerbare bestanden van het servicetype, meestal EXE/DLL-bestanden. Naar de bestanden in de map met codepakketten wordt verwezen door het bestand van ServiceManifest.xml het servicetype. Wanneer u een benoemde service maakt, wordt het codepakket gekopieerd naar het knooppunt of de knooppunten die zijn geselecteerd om de benoemde service uit te voeren. Vervolgens wordt de code uitgevoerd. Er zijn twee typen uitvoerbare codepakketten:

  • Uitvoerbare gastbestanden: uitvoerbare bestanden die als-is worden uitgevoerd op het hostbesturingssysteem (Windows of Linux). Deze uitvoerbare bestanden koppelen of verwijzen niet naar runtimebestanden van Service Fabric en gebruiken daarom geen Service Fabric-programmeermodellen. Deze uitvoerbare bestanden kunnen bepaalde Service Fabric-functies, zoals de naamgevingsservice voor eindpuntdetectie, niet gebruiken. Uitvoerbare gastbestanden kunnen geen metrische gegevens rapporteren die specifiek zijn voor elk service-exemplaar.
  • Uitvoerbare servicehosts: uitvoerbare bestanden die gebruikmaken van Service Fabric-programmeermodellen door te koppelen aan Service Fabric-runtimebestanden, waardoor Service Fabric-functies worden ingeschakeld. Een benoemd service-exemplaar kan bijvoorbeeld eindpunten registreren bij de Naamgevingsservice van Service Fabric en kan ook metrische gegevens over belasting rapporteren.

Gegevenspakket: Een schijfmap die de statische, alleen-lezen gegevensbestanden van het servicetype bevat, meestal foto-, geluids- en videobestanden. Naar de bestanden in de map met gegevenspakketten wordt verwezen door het bestand van ServiceManifest.xml het servicetype. Wanneer u een benoemde service maakt, wordt het gegevenspakket gekopieerd naar het knooppunt of de knooppunten die zijn geselecteerd om de benoemde service uit te voeren. De code wordt uitgevoerd en heeft nu toegang tot de gegevensbestanden.

Configuratiepakket: Een schijfmap die de statische configuratiebestanden van het servicetype bevat, meestal tekstbestanden met het kenmerk Alleen-lezen. Naar de bestanden in de map met configuratiepakketten wordt verwezen door het bestand van ServiceManifest.xml het servicetype. Wanneer u een benoemde service maakt, worden de bestanden in het configuratiepakket gekopieerd naar een of meer knooppunten die zijn geselecteerd om de benoemde service uit te voeren. Vervolgens wordt de code uitgevoerd en heeft deze nu toegang tot de configuratiebestanden.

Containers: Service Fabric implementeert en activeert standaard services als processen. Service Fabric kan ook services implementeren in containerinstallatiekopieën. Containers zijn een virtualisatietechnologie waarmee het onderliggende besturingssysteem van toepassingen wordt geabstraheerd. Een toepassing en de runtime, afhankelijkheden en systeembibliotheken worden uitgevoerd in een container. De container heeft volledige, persoonlijke toegang tot de eigen geïsoleerde weergave van de besturingssysteemconstructies van de container. Service Fabric ondersteunt Windows Server-containers en Docker-containers in Linux. Lees Service Fabric en containers voor meer informatie.

Partitieschema: Wanneer u een benoemde service maakt, geeft u een partitieschema op. Services met aanzienlijke hoeveelheden status splitsen de gegevens over partities, waardoor de status wordt verdeeld over de knooppunten van het cluster. Door de gegevens over partities te splitsen, kan de status van uw benoemde service worden geschaald. Binnen een partitie hebben staatloze benoemde services exemplaren, terwijl stateful benoemde services replica's hebben. Meestal hebben stateless benoemde services slechts één partitie, omdat ze geen interne status hebben. De partitie-exemplaren bieden beschikbaarheid. Als het ene exemplaar mislukt, blijven andere exemplaren normaal werken en maakt Service Fabric vervolgens een nieuw exemplaar. Stateful benoemde services onderhouden hun status binnen replica's en elke partitie heeft een eigen replicaset, zodat de status gesynchroniseerd blijft. Als een replica mislukt, bouwt Service Fabric een nieuwe replica van de bestaande replica's.

Lees het artikel over betrouwbare services van Partition Service Fabric voor meer informatie.

Systeemservices

Er zijn systeemservices die in elk cluster worden gemaakt die de platformmogelijkheden van Service Fabric bieden.

Naamgevingsservice: elk Service Fabric-cluster heeft een Naamgevingsservice, waarmee servicenamen worden omgezet in een locatie in het cluster. U beheert de servicenamen en -eigenschappen, zoals een INTERNET Domain Name System (DNS) voor het cluster. Clients communiceren veilig met elk knooppunt in het cluster door de Naamgevingsservice te gebruiken om een servicenaam en de locatie ervan op te lossen. Toepassingen worden verplaatst binnen het cluster. Dit kan bijvoorbeeld het gevolg zijn van fouten, resourceverdeling of de grootte van het cluster. U kunt services en clients ontwikkelen die de huidige netwerklocatie oplossen. Clients verkrijgen het ip-adres van de machine en de poort waarop het momenteel wordt uitgevoerd.

Lees Communiceren met services voor meer informatie over de client- en servicecommunicatie-API's die werken met de Naming Service.

Image Store-service: elk Service Fabric-cluster heeft een Image Store-service waarbij versiebeheertoepassingspakketten worden bewaard. Kopieer een toepassingspakket naar image store en registreer vervolgens het toepassingstype in dat toepassingspakket. Nadat het toepassingstype is ingericht, maakt u er een benoemde toepassing van. U kunt de registratie van een toepassingstype bij de Image Store-service ongedaan maken nadat alle benoemde toepassingen zijn verwijderd.

Lees de instelling ImageStoreConnectionString voor meer informatie over de Image Store-service.

Lees het artikel Een toepassing implementeren voor meer informatie over het implementeren van toepassingen in de Image Store-service.

Failover Manager-service: elk Service Fabric-cluster heeft een Failover Manager-service die verantwoordelijk is voor de volgende acties:

  • Voert functies uit met betrekking tot hoge beschikbaarheid en consistentie van services.
  • Hiermee worden toepassings- en clusterupgrades ingedeeld.
  • Communiceert met andere systeemonderdelen.

Repair Manager-service: dit is een optionele systeemservice waarmee herstelacties op een cluster kunnen worden uitgevoerd op een manier die veilig, automatiseerbaar en transparant is. Repair Manager wordt gebruikt in:

Implementatie- en toepassingsmodellen

Als u uw services wilt implementeren, moet u beschrijven hoe ze moeten worden uitgevoerd. Service Fabric ondersteunt drie verschillende implementatiemodellen:

Systeemeigen model

Het systeemeigen toepassingsmodel biedt uw toepassingen volledige toegang op laag niveau tot Service Fabric. Toepassingen en services worden gedefinieerd als geregistreerde typen in XML-manifestbestanden.

Het systeemeigen model ondersteunt de Reliable Services- en Reliable Actors-frameworks, die toegang biedt tot de Service Fabric Runtime-API's en clusterbeheer-API's in C# en Java. Het systeemeigen model ondersteunt ook willekeurige containers en uitvoerbare bestanden.

Reliable Services: een API voor het bouwen van stateless en stateful services. Stateful services slaan hun status op in Betrouwbare verzamelingen, zoals een woordenlijst of een wachtrij. U kunt ook verschillende communicatiestacks aansluiten, zoals Web-API en Windows Communication Foundation (WCF).

Reliable Actors: een API voor het bouwen van staatloze en stateful objecten via het programmeermodel van de virtuele actor. Dit model is handig wanneer u veel onafhankelijke rekeneenheden of statussen hebt. Dit model maakt gebruik van een turn-based threading-model, dus het is raadzaam code te vermijden die andere actoren of services aanroept, omdat een afzonderlijke actor geen andere binnenkomende aanvragen kan verwerken totdat alle uitgaande aanvragen zijn voltooid.

U kunt uw bestaande toepassingen ook uitvoeren in Service Fabric:

Containers: Service Fabric ondersteunt de implementatie van Docker-containers in Linux- en Windows Server-containers in Windows Server 2016, samen met ondersteuning voor de hyper-V-isolatiemodus. In het Service Fabric-toepassingsmodel vertegenwoordigt een container een toepassingshost waarin meerdere servicereplica's worden geplaatst. Service Fabric kan containers uitvoeren en het scenario is vergelijkbaar met het uitvoerbare gastscenario, waarbij u een bestaande toepassing in een container inpakt. Daarnaast kunt u Service Fabric-services ook uitvoeren in containers .

Uitvoerbare gastbestanden: u kunt elk type code uitvoeren, zoals Node.js, Python, Java of C++ in Azure Service Fabric als een service. Service Fabric verwijst naar deze typen services als uitvoerbare gastbestanden, die worden behandeld als stateless services. De voordelen van het uitvoeren van een uitvoerbaar gastbestand in een Service Fabric-cluster zijn hoge beschikbaarheid, statuscontrole, levenscyclusbeheer van toepassingen, high-density en detectie.

Lees het artikel Een programmeermodel kiezen voor uw serviceartikel voor meer informatie.

Docker Compose

Docker Compose maakt deel uit van het Docker-project. Service Fabric biedt beperkte ondersteuning voor het implementeren van toepassingen met behulp van het Docker Compose-model.

Omgevingen

Service Fabric is een opensource-platformtechnologie waarop verschillende services en producten zijn gebaseerd. Microsoft biedt de volgende opties:

  • Azure Service Fabric: het door Azure gehoste Service Fabric-clusteraanbod. Het biedt integratie tussen Service Fabric en de Azure-infrastructuur, samen met upgrade- en configuratiebeheer van Service Fabric-clusters.
  • Zelfstandige Service Fabric: een set installatie- en configuratiehulpprogramma's om Service Fabric-clusters overal (on-premises of op een cloudprovider) te implementeren. Niet beheerd door Azure.
  • Service Fabric-ontwikkelcluster: biedt een lokale ontwikkelervaring op Windows, Linux of Mac voor het ontwikkelen van Service Fabric-toepassingen.

Volgende stappen

Meer informatie over Service Fabric: