Service Fabric terminologieoverzicht
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 proces-orchestrator waarmee u uw clustersoveral kunt hosten: in Azure, in een on-premises datacenter of bij een cloudprovider. U kunt elk framework gebruiken om uw services te schrijven en kiezen waar u de toepassing wilt uitvoeren vanuit meerdere omgevingskeuzen. In dit artikel wordt de terminologie beschreven die door de Service Fabric om inzicht te krijgen in de termen die in de documentatie 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 computer of VM heeft een Windows-service voor automatisch starten, , die wordt uitgevoerd bij het opstarten en vervolgens twee uitvoerbare bestanden FabricHost.exe start: Fabric.exe en FabricGateway.exe . Deze twee uitvoerbare bestanden maken het knooppunt uit. Voor testscenario's kunt u meerdere knooppunten op één computer of VM hosten door meerdere exemplaren van en uit Fabric.exe te FabricGateway.exe voeren.
Toepassings- en serviceconcepten
Service Fabric native toepassing: Service Fabric native toepassingen worden beschreven door het native toepassingsmodel (op XML gebaseerde toepassings- en servicemanifests).
Service Fabric van native toepassingen
Toepassing: een toepassing is een verzameling samenstellende services die een bepaalde functie of functies uitvoeren. De levenscyclus van elk toepassings exemplaar kan onafhankelijk worden beheerd.
Service: een service voert een volledige en zelfstandige functie uit en kan onafhankelijk van andere services worden starten en uitvoeren. Een service bestaat uit code, configuratie en gegevens. Voor elke service bestaat code uit de uitvoerbare binaire bestanden, configuratie bestaat uit service-instellingen die tijdens run time kunnen worden geladen en gegevens bestaan uit willekeurige statische gegevens die door de service moeten worden gebruikt.
Toepassingstype: de naam/versie die is toegewezen aan een verzameling servicetypen. Deze wordt gedefinieerd in een bestand ApplicationManifest.xml en ingesloten in een toepassingspakketmap. De map wordt vervolgens gekopieerd naar het Service Fabric van het cluster. U kunt vervolgens een benoemde toepassing maken van dit toepassingstype in het cluster.
Lees het artikel Toepassingsmodel voor meer informatie.
Toepassingspakket: een schijfmap met het bestand van het ApplicationManifest.xml toepassingstype. Verwijst naar de servicepakketten voor elk servicetype waar het toepassingstype uit is. De bestanden in de toepassingspakketmap worden gekopieerd naar Service Fabric van het cluster. Een toepassingspakket voor een e-mailtoepassingstype kan bijvoorbeeld verwijzingen bevatten naar een queue-service-pakket, een front-endservicepakket en een databaseservicepakket.
Benoemde toepassing: nadat u een toepassingspakket naar de afbeeldingsopslag hebt kopieert, 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. Aan elk exemplaar van het toepassingstype wordt een URI-naam (Uniform Resource Identifier) toegewezen die er als voorbeeld uitziet: "fabric:/MyNamedApp" . Binnen een cluster kunt u meerdere benoemde toepassingen maken van één toepassingstype. U kunt ook benoemde toepassingen maken van verschillende toepassingstypen. Elke benoemde toepassing wordt onafhankelijk van elkaar beheerd en versies ervan gemaakt.
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. Er wordt vervolgens naar de map van het servicepakket verwezen door het bestand van een ApplicationManifest.xml toepassingspakket. Nadat u een benoemde toepassing hebt aanmaken, kunt u binnen het cluster een benoemde service maken van een van de servicetypen van het toepassingstype. Het bestand van het ServiceManifest.xml servicetype beschrijft de service.
Lees het artikel Toepassingsmodel voor meer informatie.
Er zijn twee soorten services:
- Staatloos: gebruik een stateless 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 bijvoorbeeld worden doorgegeven aan de service, wordt een berekening uitgevoerd die gebruikmaakt van deze waarden, waarna er een resultaat wordt geretourneerd.
- Stateful: gebruik een stateful service wanneer u Service Fabric de status van uw service wilt beheren via de betrouwbare verzamelingen of Reliable Actors programmeermodellen. Wanneer u een benoemde service maakt, geeft u op hoeveel partities u wilt verdelen over uw status voor schaalbaarheid. Geef ook op hoe vaak uw status moet worden gerepliceerd tussen 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 synchroon te houden. Service Fabric detecteert automatisch wanneer een primaire replica mislukt en promovert 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 het ServiceManifest.xml servicetype. Dit bestand verwijst naar de code, statische gegevens en configuratiepakketten voor het servicetype. Naar de bestanden in de map van het servicepakket wordt verwezen door het bestand van het ApplicationManifest.xml toepassingstype. Een servicepakket kan bijvoorbeeld verwijzen naar de code, statische gegevens en configuratiepakketten die samen een databaseservice maken.
Benoemde service: nadat u een benoemde toepassing hebt maken, kunt u een exemplaar van een van de servicetypen in het cluster maken. U geeft het servicetype op met behulp van de naam/versie. Aan elk exemplaar van het servicetype wordt een URI-naam toegewezen die valt onder de URI van de benoemde toepassing. Als u bijvoorbeeld een 'MyDatabase'-service met de naam maakt binnen een 'MyNamedApp'-toepassing met de naam , ziet de URI er als volgende uit: "fabric:/MyNamedApp/MyDatabase" . Binnen een benoemde toepassing kunt u verschillende benoemde services maken. Elke benoemde service kan een eigen partitieschema en aantal instanties of replica's hebben.
Codepakket: een schijfmap met de uitvoerbare bestanden van het servicetype, meestal EXE-/DLL-bestanden. Naar de bestanden in de map van het codepakket wordt verwezen door het bestand van het ServiceManifest.xml 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 gastbare bestanden: uitvoerbare bestanden die worden uitgevoerd zoals ze zijn op het hostbesturingssysteem (Windows of Linux). Deze uitvoerbare bestanden worden niet gekoppeld aan of verwijzen naar Service Fabric runtime-bestanden en maken daarom geen gebruik van Service Fabric programmeermodellen. Deze uitvoerbare bestanden kunnen bepaalde functies Service Fabric gebruiken, zoals de naamgevingsservice voor eindpuntdetectie. Uitvoerbare gastgegevens kunnen geen metrische belastingsgegevens rapporteren die specifiek zijn voor elk service-exemplaar.
- Uitvoerbare servicehosts: uitvoerbare bestanden die gebruikmaken van Service Fabric programmeermodellen door te koppelen aan Service Fabric runtime-bestanden, waardoor Service Fabric inschakelen. Een benoemd service-exemplaar kan bijvoorbeeld eindpunten registreren bij de Service Fabric van Naming Service en kan ook metrische gegevens over de belasting rapporteren.
Gegevenspakket: een schijfmap die de statische, alleen-lezen gegevensbestanden van het servicetype bevat, meestal foto-, geluid- en videobestanden. Naar de bestanden in de map van het gegevenspakket wordt verwezen door het bestand van het ServiceManifest.xml 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, alleen-lezen configuratiebestanden van het servicetype bevat, meestal tekstbestanden. Naar de bestanden in de map van het configuratiepakket wordt verwezen door het bestand van het ServiceManifest.xml 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 toegang tot de configuratiebestanden.
Containers: standaard worden Service Fabric services geïmplementeerd en geactiveerd als processen. Service Fabric kunt ook services implementeren in containerafbeeldingen. Containers zijn een virtualisatietechnologie die het onderliggende besturingssysteem abstract maakt van toepassingen. 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 constructies van het besturingssysteem van de container. Service Fabric ondersteunt Windows Server-containers en Docker-containers in Linux. Lees de 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 over de knooppunten van het cluster wordt verdeeld. Door de gegevens over partities te splitsen, kan de status van uw benoemde service worden geschaald. Binnen een partitie hebben staatloze benoemde services instanties, terwijl stateful benoemde services replica's hebben. Staatloze benoemde services hebben meestal 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 wordt Service Fabric een nieuwe instantie gemaakt. Stateful benoemde services behouden hun status binnen replica's en elke partitie heeft een eigen replicaset, zodat de status synchroon wordt gehouden. Als een replica mislukt, Service Fabric een nieuwe replica van de bestaande replica's.
Lees het artikel Service Fabric reliable services voor meer informatie.
Systeemservices
Er zijn systeemservices die in elk cluster worden gemaakt en die de platformmogelijkheden van Service Fabric.
Naming Service: elk Service Fabric cluster heeft een Naming Service, waarmee servicenamen worden opgelost naar 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 met behulp van de Naming Service om een servicenaam en de locatie op te lossen. Toepassingen worden binnen het cluster verplaatst. Dit kan bijvoorbeeld worden veroorzaakt door fouten, resourceverdeling of het formaat van het cluster. U kunt services en clients ontwikkelen die de huidige netwerklocatie oplossen. Clients verkrijgen het werkelijke IP-adres van de computer en de poort waarop deze momenteel wordt uitgevoerd.
Lees Communiceren met services voor meer informatie over de API's voor client- en servicecommunicatie die met de Naming Service.
Image Store service: elk Service Fabric cluster heeft een Image Store-service waar geïmplementeerde toepassingspakketten met versies worden bewaard. Kopieer een toepassingspakket naar het Image Store 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 begrijpen voor meer informatie over de Image Store service.
Lees het artikel Deploy an application (Een toepassing implementeren) voor meer informatie over het implementeren van toepassingen in Image Store service.
Failover Manager service: elk Service Fabric cluster heeft een Failover Manager-service die verantwoordelijk is voor de volgende acties:
- Hiermee worden functies uitgevoerd die betrekking hebben op hoge beschikbaarheid en consistentie van services.
- Orchestrat toepassings- en clusterupgrades.
- Communiceert met andere systeemonderdelen.
Repair Manager service: dit is een optionele systeemservice waarmee herstelacties op een cluster kunnen worden uitgevoerd op een veilige, automatische en transparante manier. Repair Manager wordt gebruikt in:
- Azure-onderhoudsreparaties uitvoeren op Azure-clusters met duurzaamheid van Silver Service Fabric Gold.
- Herstelacties uitvoeren voor patch-orchestrationtoepassing
Implementatie- en toepassingsmodellen
Als u uw services wilt implementeren, moet u beschrijven hoe deze moeten worden uitgevoerd. Service Fabric ondersteunt drie verschillende implementatiemodellen:
Native 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 bieden tot de Service Fabric runtime-API's en api's voor clusterbeheer in C# en Java. Het native 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 virtual Actor-programmeermodel. Dit model is handig wanneer u veel onafhankelijke eenheden van berekening of status hebt. Dit model maakt gebruik van een op beurt gebaseerd threadingmodel. Het is dus het beste om code te vermijden die naar andere actors of services wordt aanroept, omdat een afzonderlijke actor geen andere binnenkomende aanvragen kan verwerken totdat alle uitgaande aanvragen zijn voltooid.
U kunt uw bestaande toepassingen ook uitvoeren op Service Fabric:
Containers: Service Fabric ondersteuning voor de implementatie van Docker-containers op Linux- en Windows Server-containers in Windows Server 2016, samen met ondersteuning voor de Hyper-V-isolatiemodus. In het Service Fabric toepassingsmodelvertegenwoordigt een container een toepassingshost waarin meerdere servicereplica's worden geplaatst. Service Fabric kunt alle containers uitvoeren en het scenario is vergelijkbaar met het scenario dat door gasten kan worden uitgevoerd, waarbij u een bestaande toepassing in een container inpakt. Daarnaast kunt u ook Service Fabric in containers uitvoeren.
Uitvoerbare gast-bestanden: 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 gast-bestanden, die worden behandeld als stateless services. De voordelen van het uitvoeren van een uitvoerbaar gastcluster in een Service Fabric-cluster zijn hoge beschikbaarheid, statuscontrole, beheer van de levenscyclus van toepassingen, high-density en detecteerbaarheid.
Lees het artikel Choose a programming model for your service (Een programmeermodel kiezen voor uw service) 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: de door Azure gehoste Service Fabric clusteraanbieding. Het biedt integratie tussen Service Fabric en de Azure-infrastructuur, samen met upgrade- en configuratiebeheer van Service Fabric clusters.
- Service Fabric zelfstandig: een set installatie- en configuratiehulpprogramma's voor het implementeren van Service Fabric clusters overal (on-premises of op een cloudprovider). Niet beheerd door Azure.
- Service Fabric ontwikkelcluster: biedt een lokale ontwikkelervaring op Windows, Linux of Mac voor de ontwikkeling van Service Fabric toepassingen.
Volgende stappen
Voor meer informatie over Service Fabric: