Azure Service Fabric-hostingmodel

Dit artikel bevat een overzicht van toepassingshostingmodellen van Azure Service Fabric en beschrijft de verschillen tussen de modellen voor gedeeld proces en exclusief proces . Hierin wordt beschreven hoe een geïmplementeerde toepassing eruitziet op een Service Fabric-knooppunt en de relatie tussen replica's (of exemplaren) van de service en het servicehostproces.

Voordat u verdergaat, moet u ervoor zorgen dat u de verschillende concepten en relaties begrijpt die worden uitgelegd in Model an application in Service Fabric.

Notitie

In dit artikel, tenzij expliciet vermeld als betekenis iets anders:

• Replica verwijst naar zowel een replica van een stateful service als een exemplaar van een stateless service.
• CodePackage wordt behandeld als gelijkwaardig aan een ServiceHost-proces waarmee een ServiceType wordt geregistreerd en replica's van services van dat ServiceType worden gehost.

Laten we een voorbeeld bekijken om inzicht te hebben in het hostingmodel. Stel dat we een ApplicationType 'MyAppType' hebben, dat een ServiceType 'MyServiceType' heeft. 'MyServiceType' wordt geleverd door de ServicePackage 'MyServicePackage', die een CodePackage 'MyCodePackage' heeft. 'MyCodePackage' registreert ServiceType 'MyServiceType' wanneer het wordt uitgevoerd.

Stel dat we een cluster met drie knooppunten hebben en dat we een toepassingsinfrastructuur maken:/App1 van het type 'MyAppType'. In deze toepassingsinfrastructuur :/App1 maken we een service fabric:/App1/ServiceA van het type 'MyServiceType'. Deze service heeft twee partities (bijvoorbeeld P1 en P2) en drie replica's per partitie. In het volgende diagram ziet u de weergave van deze toepassing wanneer deze wordt geïmplementeerd op een knooppunt.

Service Fabric heeft 'MyServicePackage' geactiveerd, waarmee 'MyCodePackage' is gestart, die replica's van beide partities host. Alle knooppunten in het cluster hebben dezelfde weergave, omdat we het aantal replica's per partitie hebben gekozen dat gelijk is aan het aantal knooppunten in het cluster. Laten we een andere service, fabric:/App1/ServiceB, maken in de application fabric:/App1. Deze service heeft één partitie (bijvoorbeeld P3) en drie replica's per partitie. In het volgende diagram ziet u de nieuwe weergave op het knooppunt:

Service Fabric heeft de nieuwe replica geplaatst voor partitie P3 van service fabric:/App1/ServiceB in de bestaande activering van 'MyServicePackage'. Nu. Laten we een andere toepassingsinfrastructuur maken:/App2 van het type 'MyAppType'. Maak in fabric:/App2 een Service Fabric:/App2/ServiceA. Deze service heeft twee partities (P4 en P5) en drie replica's per partitie. In het volgende diagram ziet u de nieuwe knooppuntweergave:

Service Fabric activeert een nieuwe kopie van 'MyServicePackage', waarmee een nieuwe kopie van MyCodePackage wordt gestart. Replica's van beide partities van service fabric:/App2/ServiceA (P4 en P5) worden in dit nieuwe exemplaar 'MyCodePackage' geplaatst.

Model voor gedeeld proces

In de voorgaande sectie wordt het standaardhostingmodel beschreven dat wordt geleverd door Service Fabric, aangeduid als het model voor gedeeld proces. In dit model wordt voor een bepaalde toepassing slechts één kopie van een gegeven ServicePackage geactiveerd op een knooppunt (waarmee alle CodePackages erin worden gestart). Alle replica's van alle services van een bepaald ServiceType worden in de CodePackage geplaatst die dat ServiceType registreert. Met andere woorden, alle replica's van alle services op een knooppunt van een bepaald ServiceType delen hetzelfde proces.

Exclusief procesmodel

Het andere hostingmodel dat door Service Fabric wordt geleverd, is het exclusieve procesmodel. In dit model, op een bepaald knooppunt, bevindt elke replica zich in een eigen toegewezen proces. Service Fabric activeert een nieuwe kopie van ServicePackage (waarmee alle CodePackages erin worden gestart). Replica's worden in de CodePackage geplaatst waarmee het ServiceType is geregistreerd van de service waartoe de replica behoort.

Als u Service Fabric versie 5.6 of hoger gebruikt, kunt u het exclusieve procesmodel kiezen op het moment dat u een service maakt (met behulp van PowerShell, REST of FabricClient). Geef ServicePackageActivationMode op als 'ExclusiveProcess'.

PS C:\>New-ServiceFabricService -ApplicationName "fabric:/App1" -ServiceName "fabric:/App1/ServiceA" -ServiceTypeName "MyServiceType" -Stateless -PartitionSchemeSingleton -InstanceCount -1 -ServicePackageActivationMode "ExclusiveProcess"

var serviceDescription = new StatelessServiceDescription
{
    ApplicationName = new Uri("fabric:/App1"),
    ServiceName = new Uri("fabric:/App1/ServiceA"),
    ServiceTypeName = "MyServiceType",
    PartitionSchemeDescription = new SingletonPartitionSchemeDescription(),
    InstanceCount = -1,
    ServicePackageActivationMode = ServicePackageActivationMode.ExclusiveProcess
};

var fabricClient = new FabricClient(clusterEndpoints);
await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

Als u een standaardservice in uw toepassingsmanifest hebt, kunt u het exclusieve procesmodel kiezen door het kenmerk ServicePackageActivationMode op te geven:

<DefaultServices>
  <Service Name="MyService" ServicePackageActivationMode="ExclusiveProcess">
    <StatelessService ServiceTypeName="MyServiceType" InstanceCount="1">
      <SingletonPartition/>
    </StatelessService>
  </Service>
</DefaultServices>

We gaan nu een andere service, fabric:/App1/ServiceC, maken in application fabric:/App1. Deze service heeft twee partities (bijvoorbeeld P6 en P7) en drie replica's per partitie. U stelt ServicePackageActivationMode in op 'ExclusiveProcess'. In het volgende diagram ziet u een nieuwe weergave op het knooppunt:

Zoals u ziet, heeft Service Fabric twee nieuwe kopieën van 'MyServicePackage' geactiveerd (één voor elke replica van partitie P6 en P7). Service Fabric heeft elke replica in de toegewezen kopie van CodePackage geplaatst. Wanneer u het exclusieve procesmodel gebruikt, kunnen voor een bepaalde toepassing meerdere exemplaren van een bepaalde ServicePackage actief zijn op een knooppunt. In het voorgaande voorbeeld zijn drie exemplaren van 'MyServicePackage' actief voor fabric:/App1. Aan elk van deze actieve kopieën van 'MyServicePackage' is een ServicePackageActivationId gekoppeld. Deze id identificeert die kopie in application fabric:/App1.

Wanneer u alleen het model voor gedeeld proces voor een toepassing gebruikt, is er slechts één actieve kopie van ServicePackage op een knooppunt. De ServicePackageActivationId voor deze activering van ServicePackage is een lege tekenreeks. Dit is bijvoorbeeld het geval bij fabric:/App2.

Notitie

• Het shared process-hostingmodel komt overeen met ServicePackageActivationMode is gelijk aan SharedProcess. Dit is het standaardhostingmodel en ServicePackageActivationMode hoeft niet te worden opgegeven op het moment dat de service wordt gemaakt.

• Het exclusieve proceshostingmodel komt overeen met ServicePackageActivationMode is gelijk aan ExclusiveProcess. Als u deze instelling wilt gebruiken, moet u deze expliciet opgeven op het moment van het maken van de service.

• Als u het hostingmodel van een service wilt bekijken, voert u een query uit op de servicebeschrijving en bekijkt u de waarde van ServicePackageActivationMode.

Werken met een geïmplementeerd servicepakket

Een actieve kopie van een ServicePackage op een knooppunt wordt een geïmplementeerd servicepakket genoemd. Wanneer u het exclusieve procesmodel gebruikt voor het maken van services voor een bepaalde toepassing, zijn er mogelijk meerdere geïmplementeerde servicepakketten voor dezelfde ServicePackage. Als u bewerkingen uitvoert die specifiek zijn voor een geïmplementeerd servicepakket, moet u ServicePackageActivationId opgeven om een specifiek geïmplementeerd servicepakket te identificeren. Geef bijvoorbeeld de id op als u de status van een geïmplementeerd servicepakket rapporteert of het codepakket van een geïmplementeerd servicepakket opnieuw start.

U vindt de ServicePackageActivationId van een geïmplementeerd servicepakket door een query uit te voeren op de lijst met geïmplementeerde servicepakketten op een knooppunt. Wanneer u query's uitvoert op de geïmplementeerde servicetypen, geïmplementeerde replica's en geïmplementeerde codepakketten op een knooppunt, bevat het queryresultaat ook de ServicePackageActivationId van het bovenliggende geïmplementeerde servicepakket.

Notitie

• Onder het hostmodel voor gedeeld proces, op een bepaald knooppunt, wordt slechts één exemplaar van een ServicePackage geactiveerd voor een bepaalde toepassing. Het heeft een ServicePackageActivationId die gelijk is aan een lege tekenreeks en hoeft niet te worden opgegeven tijdens het uitvoeren van bewerkingen met betrekking tot het geïmplementeerde servicepakket.

• Onder het exclusieve proceshostingmodel, op een bepaald knooppunt, kunnen voor een bepaalde toepassing een of meer exemplaren van een ServicePackage actief zijn. Elke activering heeft een niet-lege ServicePackageActivationId, opgegeven tijdens het uitvoeren van bewerkingen met betrekking tot het geïmplementeerde servicepakket.

• Als ServicePackageActivationId wordt weggelaten, wordt standaard een lege tekenreeks gebruikt. Als een geïmplementeerd servicepakket dat is geactiveerd onder het model Gedeeld proces aanwezig is, wordt de bewerking erop uitgevoerd. Anders mislukt de bewerking.

• Voer geen query's uit en cache de ServicePackageActivationId. De id wordt dynamisch gegenereerd en kan om verschillende redenen veranderen. Voordat u een bewerking uitvoert waarvoor ServicePackageActivationId is vereist, moet u eerst een query uitvoeren op de lijst met geïmplementeerde servicepakketten op een knooppunt. Gebruik vervolgens de ServicePackageActivationId uit het queryresultaat om de oorspronkelijke bewerking uit te voeren.

Uitvoerbare gasttoepassingen en containertoepassingen

Service Fabric behandelt uitvoerbare gasttoepassingen en containertoepassingen als stateless services, die zelfstandig zijn. Er is geen Service Fabric-runtime in ServiceHost (een proces of container). Omdat deze services op zichzelf staan, is het aantal replica's per ServiceHost niet van toepassing op deze services. De meest voorkomende configuratie die met deze services wordt gebruikt, is één partitie, waarbij InstanceCount gelijk is aan -1 (één kopie van de servicecode die wordt uitgevoerd op elk knooppunt van het cluster).

De standaardServicePackageActivationMode voor deze services is SharedProcess. In dat geval activeert Service Fabric slechts één exemplaar van ServicePackage op een knooppunt voor een bepaalde toepassing. Dit betekent dat slechts één kopie van de servicecode een knooppunt uitvoert. Als u wilt dat meerdere exemplaren van uw servicecode worden uitgevoerd op een knooppunt, geeft u ServicePackageActivationMode op als ExclusiveProcess op het moment dat de service wordt gemaakt. U kunt dit bijvoorbeeld doen wanneer u meerdere services (Service1 to ServiceN) van ServiceType maakt (opgegeven in ServiceManifest) of wanneer uw service meerdere partities heeft.

Het hostingmodel van een bestaande service wijzigen

Op dit moment kunt u het hostingmodel van een bestaande service van Gedeeld proces niet wijzigen in Exclusief proces (of omgekeerd).

Kiezen tussen de hostingmodellen

U moet evalueren welk hostingmodel het beste past bij uw vereisten. In het model Gedeeld proces worden besturingssysteemresources beter gebruikt, omdat er minder processen worden uitgevoerd en meerdere replica's in hetzelfde proces poorten kunnen delen. Als een van de replica's echter een fout heeft waarbij deze de servicehost moet neerhalen, is dit van invloed op alle andere replica's in hetzelfde proces.

Het exclusieve procesmodel biedt een betere isolatie, waarbij elke replica in een eigen proces wordt uitgevoerd. Als een van de replica's een fout heeft, heeft dit geen invloed op andere replica's. Dit model is handig voor gevallen waarin delen van poorten niet wordt ondersteund door het communicatieprotocol. Het vereenvoudigt de mogelijkheid om resourcebeheer toe te passen op replicaniveau. Het exclusieve proces verbruikt echter meer besturingssysteemresources, omdat er één proces voor elke replica op het knooppunt wordt uitgevoerd.

Overwegingen voor exclusief procesmodel en toepassingsmodel

Voor de meeste toepassingen kunt u uw toepassing modelleren in Service Fabric door één ServiceType per ServicePackage te bewaren.

In bepaalde gevallen staat Service Fabric ook meer dan één ServiceType per ServicePackage toe (en één CodePackage kan meer dan één ServiceType registreren). Hier volgen enkele scenario's waarin deze configuraties nuttig kunnen zijn:

• U wilt het resourcegebruik optimaliseren door minder processen uit te voeren en een hogere replicadichtheid per proces te hebben.
• Replica's van verschillende ServiceTypes moeten enkele algemene gegevens delen die een hoge initialisatie- of geheugenkosten hebben.
• U hebt een gratis serviceaanbod en u wilt een limiet voor resourcegebruik plaatsen door alle replica's van de service in hetzelfde proces te plaatsen.

Het exclusieve proceshostingmodel is niet coherent met een toepassingsmodel met meerdere ServiceTypes per ServicePackage. Dit komt doordat meerdere ServiceTypes per ServicePackage zijn ontworpen om het delen van resources tussen replica's te verhogen en een hogere replicadichtheid per proces mogelijk te maken. Het Exclusieve procesmodel is ontworpen om verschillende resultaten te bereiken.

Overweeg het geval van meerdere ServiceTypes per ServicePackage, waarbij een ander CodePackage elk ServiceType registreert. Stel dat we een ServicePackage 'MultiTypeServicePackage' hebben, met twee CodePackages:

• 'MyCodePackageA', waarmee ServiceType 'MyServiceTypeA' wordt geregistreerd.
• 'MyCodePackageB', waarmee ServiceType 'MyServiceTypeB' wordt geregistreerd.

Stel nu dat we een toepassing maken, fabric:/SpecialApp. Binnen fabric:/SpecialApp maken we de volgende twee services met het exclusieve procesmodel:

• Service fabric:/SpecialApp/ServiceA van het type 'MyServiceTypeA', met twee partities (bijvoorbeeld P1 en P2) en drie replica's per partitie.
• Service fabric:/SpecialApp/ServiceB van het type 'MyServiceTypeB', met twee partities (P3 en P4) en drie replica's per partitie.

Op een bepaald knooppunt hebben beide services elk twee replica's. Omdat we het exclusieve procesmodel hebben gebruikt om de services te maken, activeert Service Fabric een nieuwe kopie van 'MyServicePackage' voor elke replica. Elke activering van 'MultiTypeServicePackage' start een kopie van 'MyCodePackageA' en 'MyCodePackageB'. Slechts één van 'MyCodePackageA' of 'MyCodePackageB' host echter de replica waarvoor 'MultiTypeServicePackage' is geactiveerd. In het volgende diagram ziet u de knooppuntweergave:

In de activering van 'MultiTypeServicePackage' voor de replica van partitie P1 van service fabric:/SpecialApp/ServiceA host 'MyCodePackageA' de replica. 'MyCodePackageB' wordt uitgevoerd. In de activering van 'MultiTypeServicePackage' voor de replica van partitie P3 van service fabric:/SpecialApp/ServiceB host 'MyCodePackageB' de replica. 'MyCodePackageA' wordt uitgevoerd. Hoe groter het aantal CodePackages (het registreren van verschillende ServiceTypes) per ServicePackage, hoe hoger het redundante resourcegebruik.

Als we echter de services fabric maken:/SpecialApp/ServiceA en fabric:/SpecialApp/ServiceB met het shared process model, activeert Service Fabric slechts één exemplaar van 'MultiTypeServicePackage' voor de toepassingsinfrastructuur :/SpecialApp. 'MyCodePackageA' host alle replica's voor de service fabric:/SpecialApp/ServiceA. 'MyCodePackageB' host alle replica's voor de service fabric:/SpecialApp/ServiceB. In het volgende diagram ziet u de knooppuntweergave in deze instelling:

In het voorgaande voorbeeld denkt u misschien dat als 'MyCodePackageA' zowel 'MyServiceTypeA' als 'MyServiceTypeB' registreert en er geen 'MyCodePackageB' is, er geen redundante CodePackage wordt uitgevoerd. Hoewel dit juist is, is dit toepassingsmodel niet afgestemd op het exclusieve proceshostingmodel. Als het doel is om elke replica in een eigen toegewezen proces te plaatsen, hoeft u niet beide ServiceTypes van dezelfde CodePackage te registreren. In plaats daarvan plaatst u elk ServiceType in een eigen ServicePackage.

Reliable Services en Actor forking-subprocessen

Service Fabric biedt geen ondersteuning voor betrouwbare services en vervolgens betrouwbare actoren voor het aanbrengen van subprocessen. Een voorbeeld van waarom het niet wordt ondersteund, is CodePackageActivationContext , kan niet worden gebruikt om een niet-ondersteund subproces te registreren en annuleringstokens worden alleen verzonden naar geregistreerde processen, wat resulteert in allerlei problemen, zoals upgradefouten, wanneer subprocessen niet worden gesloten nadat het bovenliggende proces een annuleringstoken heeft ontvangen.

Volgende stappen

Pak een toepassing in en bereid deze voor op de implementatie.

Toepassingen implementeren en verwijderen. In dit artikel wordt beschreven hoe u PowerShell gebruikt om toepassingsexemplaren te beheren.