Hur Reliable Actors använder Service Fabric-plattformen
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 avsändare för att dirigera till lämplig aktörsinstans.
- Aktörstillståndsprovidern omsluter tillståndsprovidern (till exempel tillståndsprovidern Reliable Collections) 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.
Föregående diagram visar relationen mellan Service Fabric-programramverken och användarkoden. Blå element representerar reliable services-programramverket, orange representerar ramverket Reliable Actor och grönt representerar användarkod.
I Reliable Services ärver StatefulService tjänsten 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 din aktörstjänst.
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
Utvecklarverktygen för aktörsramverket 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 även flaggan HasPersistedState i enlighet med detta.
- Kodpaket.
- Konfigurationspaket.
- Resurser och slutpunkter.
Programmanifest
Kompileringsverktygen för aktörsramverket skapar automatiskt en standardtjänstdefinition för aktörstjänsten. Byggverktygen fyller i standardegenskaperna för tjänsten:
- Antal repliker bestäms av persistence-attributet för aktören. Varje gång persistenceattributet 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.
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 associerat med det, representerat av ActorId klassen. ActorId är ett ogenomskinliga 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 ett ActorID, inklusive 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 aktörerna placeras i.