Share via


Azure Service Fabric-hostingmodel

Dit artikel bevat een overzicht van de modellen voor het hosten van toepassingen die worden geleverd door Azure Service Fabric en beschrijft de verschillen tussen de modellen 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 service-hostproces.

Voordat u verdergaat, moet u de verschillende concepten en relaties begrijpen die worden uitgelegd in Een toepassing modelleren 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 equivalent aan een ServiceHost-proces dat een ServiceType registreert en replica's van services van dat ServiceType host.

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

Stel dat we een cluster met drie knooppunten hebben en 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 op een knooppunt wordt geïmplementeerd.

Diagram met de weergave van deze toepassing wanneer deze op een knooppunt wordt geïmplementeerd.

Service Fabric heeft 'MyServicePackage' geactiveerd, waarmee 'MyCodePackage' is gestart, dat replica's van beide partities host. Alle knooppunten in het cluster hebben dezelfde weergave, omdat we ervoor hebben gekozen om het aantal replica's per partitie gelijk te stellen aan het aantal knooppunten in het cluster. Laten we een andere service maken, fabric:/App1/ServiceB, in de toepassingsinfrastructuur:/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:

Diagram met de nieuwe weergave op het knooppunt.

Service Fabric heeft de nieuwe replica voor partitie P3 van service fabric:/App1/ServiceB in de bestaande activering van 'MyServicePackage' geplaatst. Nwo. Laten we een andere toepassingsinfrastructuur maken:/App2 van het type 'MyAppType'. Maak in infrastructuur:/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:

Diagram met 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 standaard hostingmodel beschreven dat door Service Fabric wordt geleverd, ook wel het Model voor gedeelde processen genoemd. In dit model wordt voor een bepaalde toepassing slechts één kopie van een bepaalde ServicePackage geactiveerd op een knooppunt (waarmee alle CodePackages worden gestart die erin zijn opgenomen). Alle replica's van alle services van een bepaald ServiceType worden in het CodePackage geplaatst waarmee dat ServiceType wordt geregistreerd. 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 model Exclusief proces. In dit model bevindt elke replica zich op een bepaald knooppunt in een eigen toegewezen proces. Service Fabric activeert een nieuwe kopie van ServicePackage (waarmee alle CodePackages worden gestart die erin zijn opgenomen). Replica's worden geplaatst in het CodePackage 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 model Exclusief proces 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 uw toepassingsmanifest een standaardservice bevat, kunt u het model Exclusief proces kiezen door het kenmerk ServicePackageActivationMode op te geven:

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

Nu gaan we een andere service maken, fabric:/App1/ServiceC, 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 de nieuwe weergave op het knooppunt:

Diagram van de knooppuntweergave van de geïmplementeerde toepassing

Zoals u kunt zien, heeft Service Fabric twee nieuwe exemplaren 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 model Exclusief proces gebruikt voor een bepaalde toepassing, kunnen meerdere kopieën 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 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 met fabric:/App2.

Notitie

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

  • Het hostingmodel exclusief proces komt overeen met ServicePackageActivationMode is gelijk aan ExclusiveProcess. Als u deze instelling wilt gebruiken, moet u deze expliciet opgeven op het moment dat de service wordt gemaakt.

  • Als u het hostingmodel van een service wilt weergeven, voert u een query uit op de servicebeschrijving en kijkt u naar 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 model Exclusief proces gebruikt voor het maken van services, zijn er voor een bepaalde toepassing 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 kunt de ServicePackageActivationId van een geïmplementeerd servicepakket vinden 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 shared process hostingmodel, op een bepaald knooppunt, wordt voor een bepaalde toepassing slechts één exemplaar van een ServicePackage geactiveerd. 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 kopieën van een ServicePackage actief zijn. Elke activering heeft een niet-legeServicePackageActivationId, die is opgegeven tijdens het uitvoeren van bewerkingen met betrekking tot het geïmplementeerde servicepakket.

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

  • Voer niet eenmaal een query uit en sla de ServicePackageActivationId in de cache op. De id wordt dynamisch gegenereerd en kan om verschillende redenen worden gewijzigd. 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 staatloze services, die op zichzelf staan. 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 exemplaar van de servicecode een knooppunt uitvoert. Als u meerdere kopieën van uw servicecode wilt uitvoeren 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 naar 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 niet wijzigen van Gedeeld proces in Exclusief proces (of omgekeerd).

Kiezen tussen de hostingmodellen

U moet evalueren welk hostingmodel het beste past bij uw vereisten. Het model Gedeeld proces maakt beter gebruik van besturingssysteembronnen, omdat er minder processen worden voortgebracht en meerdere replica's in hetzelfde proces poorten kunnen delen. Als een van de replica's echter een fout heeft waarbij de servicehost moet worden uitgeschakeld, heeft dit 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 het delen van poorten niet wordt ondersteund door het communicatieprotocol. Het vereenvoudigt de mogelijkheid om resourcebeheer op replicaniveau toe te passen. Het exclusieve proces verbruikt echter meer besturingssysteemresources, omdat er één proces wordt uitgevoerd voor elke replica op het knooppunt.

Overwegingen voor exclusief procesmodel en toepassingsmodel

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

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 van de 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 met hoge initialisatie- of geheugenkosten.
  • U hebt een gratis serviceaanbod en u wilt het resourcegebruik beperken door alle replica's van de service in hetzelfde proces te plaatsen.

Het exclusieve proceshostingmodel is niet consistent met een toepassingsmodel met meerdere ServiceTypes per ServicePackage. Dit komt doordat meerdere ServiceTypes per ServicePackage zijn ontworpen om een hogere resourcedeling tussen replica's te bereiken en 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 elk ServiceType door een ander CodePackage wordt geregistreerd. Stel dat we een ServicePackage 'MultiTypeServicePackage' hebben, die twee CodePackages heeft:

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

Stel nu dat we een toepassing maken, fabric:/SpecialApp. In infrastructuur:/SpecialApp maken we de volgende twee services met het model Exclusief proces:

  • 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 model Exclusief proces 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 de 'MyCodePackageA' of 'MyCodePackageB' host de replica waarvoor 'MultiTypeServicePackage' is geactiveerd. In het volgende diagram ziet u de knooppuntweergave:

Diagram met de knooppuntweergave.

Bij 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 (waarbij verschillende ServiceTypes worden geregistreerd) per ServicePackage, hoe hoger het redundante resourcegebruik.

Als we echter de services-fabric:/SpecialApp/ServiceA en fabric:/SpecialApp/ServiceB maken met het model Gedeeld proces, 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:

Diagram van de knooppuntweergave van de geïmplementeerde toepassing

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.

Subprocessen van Reliable Services en Actor forking

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

Volgende stappen

Een toepassing verpakken en voorbereiden voor implementatie.

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