Så använder Reliable Actors Service Fabric-plattformen

  • Artikel

Den här artikeln förklarar hur Reliable Actors fungerar på Azure Service Fabric-plattformen. Reliable Actors körs i ett ramverk som finns i en implementering av en tillståndskänslig tillförlitlig tjänst som kallas aktörstjänsten. Aktörstjänsten innehåller alla komponenter som krävs för att hantera livscykeln och meddelandesändningen för dina aktörer:

  • Actor Runtime hanterar livscykel, skräpinsamling och framtvingar enkeltrådad åtkomst.
  • En lyssnare för aktörstjänstens fjärrkommunikation accepterar fjärråtkomstanrop till aktörer och skickar dem till en dispatcher för att dirigera till lämplig aktörsinstans.
  • Aktörstillståndsprovidern omsluter tillståndsprovidrar (till exempel tillståndsprovidern för tillförlitliga samlingar) och tillhandahåller ett kort för hantering av aktörstillstånd.

Dessa komponenter utgör tillsammans ramverket Reliable Actor.

Tjänstskiktning

Eftersom aktörstjänsten i sig är en tillförlitlig tjänst gäller alla programmodeller, livscykel, paketering, distribution, uppgradering och skalning av Reliable Services på samma sätt för aktörstjänster.

Aktörstjänstskiktning

Föregående diagram visar relationen mellan Service Fabric-programramverk och användarkod. Blå element representerar reliable services-programramverket, orange representerar ramverket Reliable Actor och grönt representerar användarkod.

I Reliable Services ärver StatefulService din tjänst klassen. Den här klassen härleds själv från StatefulServiceBase (eller StatelessService för tillståndslösa tjänster). I Reliable Actors använder du aktörstjänsten. Aktörstjänsten är en annan implementering av StatefulServiceBase klassen som implementerar aktörsmönstret där dina aktörer körs. Eftersom aktörstjänsten i sig bara är en implementering av StatefulServiceBasekan du skriva en egen tjänst som härleds från ActorService och implementera funktioner på tjänstnivå på samma sätt som när du ärver StatefulService, till exempel:

  • Tjänstsäkerhetskopiering och återställning.
  • Delade funktioner för alla aktörer, till exempel en kretsbrytare.
  • Fjärrproceduren anropar själva aktörstjänsten och på varje enskild aktör.

Mer information finns i Implementera funktioner på tjänstnivå i aktörstjänsten.

Programmodell

Aktörstjänster är Reliable Services, så programmodellen är densamma. Utvecklarverktygen för aktörsramverket genererar dock några av programmodellfilerna åt dig.

Tjänstmanifest

Aktörsramverkets byggverktyg genererar automatiskt innehållet i aktörstjänstens ServiceManifest.xml-fil. Den här filen innehåller:

  • Aktörstjänsttyp. Typnamnet genereras baserat på aktörens projektnamn. Baserat på persistence-attributet för din aktör anges också HasPersistedState-flaggan i enlighet med detta.
  • Kodpaket.
  • Konfigurationspaket.
  • Resurser och slutpunkter.

Programmanifest

Utvecklarverktygen för aktörsramverket skapar automatiskt en standardtjänstdefinition för aktörstjänsten. Byggverktygen fyller i standardtjänstegenskaperna:

  • Antal replikeringsuppsättningar bestäms av persistence-attributet för din aktör. Varje gång beständighetsattributet för aktören ändras återställs antalet replikuppsättningar i standardtjänstdefinitionen i enlighet med detta.
  • Partitionsschema och intervall är inställda på Uniform Int64 med det fullständiga Int64-nyckelintervallet.

Service Fabric-partitionsbegrepp för aktörer

Aktörstjänster är partitionerade tillståndskänsliga tjänster. Varje partition av en aktörstjänst innehåller en uppsättning aktörer. Tjänstpartitioner distribueras automatiskt över flera noder i Service Fabric. Aktörsinstanser distribueras därför.

Aktörspartitionering och distribution

Reliable Services kan skapas med olika partitionsscheman och partitionsnyckelintervall. Aktörstjänsten använder Int64-partitioneringsschemat med hela Int64-nyckelintervallet för att mappa aktörer till partitioner.

Aktörs-ID

Varje aktör som skapas i tjänsten har ett unikt ID som är associerat med det, representerat av ActorId klassen. ActorId är ett täckande ID-värde som kan användas för enhetlig distribution av aktörer över tjänstpartitionerna genom att generera slumpmässiga ID:t:

ActorProxy.Create<IMyActor>(ActorId.CreateRandom());

ActorProxyBase.create<MyActor>(MyActor.class, ActorId.newId());

Varje ActorId hashas till en Int64. Det är därför aktörstjänsten måste använda ett Int64-partitioneringsschema med hela Int64-nyckelintervallet. Anpassade ID-värden kan dock användas för , ActorIDinklusive GUID/UUID, strängar och Int64s.

ActorProxy.Create<IMyActor>(new ActorId(Guid.NewGuid()));
ActorProxy.Create<IMyActor>(new ActorId("myActorId"));
ActorProxy.Create<IMyActor>(new ActorId(1234));

ActorProxyBase.create(MyActor.class, new ActorId(UUID.randomUUID()));
ActorProxyBase.create(MyActor.class, new ActorId("myActorId"));
ActorProxyBase.create(MyActor.class, new ActorId(1234));

När du använder GUID:er/UUID:er och strängar hashas värdena till en Int64. Men när du uttryckligen tillhandahåller en Int64 till en ActorIdmappas Int64 direkt till en partition utan ytterligare hashning. Du kan använda den här tekniken för att styra vilken partition som aktörerna placeras i.

Nästa steg