Hoe Reliable Actors het Service Fabric-platform gebruiken

Artikel
06/01/2023

In dit artikel wordt uitgelegd hoe Reliable Actors werken op het Azure Service Fabric-platform. Reliable Actors worden uitgevoerd in een framework dat wordt gehost in een implementatie van een stateful betrouwbare service met de naam actorservice. De actorservice bevat alle onderdelen die nodig zijn om de levenscyclus en berichtverzending voor uw actoren te beheren:

De Actor Runtime beheert de levenscyclus, garbagecollection en dwingt toegang met één thread af.
Een externe listener van een actorservice accepteert externe toegangsaanroepen naar actoren en stuurt deze naar een dispatcher om naar het juiste actorexemplaar te routeren.
De Actor State Provider verpakt statusproviders (zoals de statusprovider Reliable Collections) en biedt een adapter voor actorstatusbeheer.

Deze onderdelen vormen samen het Reliable Actor-framework.

Servicelagen

Omdat de actorservice zelf een betrouwbare service is, worden alle concepten van het toepassingsmodel, de levenscyclus, de verpakking, de implementatie, de upgrade en het schalen van Reliable Services op dezelfde manier toegepast op actorservices.

Actor-servicelagen

In het voorgaande diagram ziet u de relatie tussen de Service Fabric-toepassingsframeworks en de gebruikerscode. Blauwe elementen vertegenwoordigen het Reliable Services-toepassingsframework, oranje vertegenwoordigt het Reliable Actor-framework en groen staat voor gebruikerscode.

In Reliable Services neemt uw service de StatefulService klasse over. Deze klasse is zelf afgeleid van StatefulServiceBase (of StatelessService voor staatloze services). In Reliable Actors gebruikt u de actor-service. De actorservice is een andere implementatie van de StatefulServiceBase klasse die het actorpatroon implementeert waar uw actoren worden uitgevoerd. Omdat de actorservice zelf slechts een implementatie van is, StatefulServiceBasekunt u uw eigen service schrijven die is afgeleid van ActorService en serviceniveaufuncties op dezelfde manier implementeren als bij het overnemen StatefulServicevan , zoals:

Back-up en herstel van de service.
Gedeelde functionaliteit voor alle actoren, bijvoorbeeld een circuitonderbreker.
Externe procedure roept de actorservice zelf aan en op elke afzonderlijke actor.

Zie Functies op serviceniveau implementeren in uw actorservice voor meer informatie.

Toepassingsmodel

Actorservices zijn Reliable Services, dus het toepassingsmodel is hetzelfde. De buildhulpprogramma's van het actorframework genereren echter enkele toepassingsmodelbestanden voor u.

Servicemanifest

De buildhulpprogramma's van het actorframework genereren automatisch de inhoud van het ServiceManifest.xml-bestand van uw actorservice. Dit bestand bevat:

Actorservicetype. De typenaam wordt gegenereerd op basis van de projectnaam van uw actor. Op basis van het persistentiekenmerk van uw actor wordt de vlag HasPersistedState ook dienovereenkomstig ingesteld.
Codepakket.
Configuratiepakket.
Resources en eindpunten.

Manifest van de toepassing

De buildhulpprogramma's van het actorframework maken automatisch een standaardservicedefinitie voor uw actorservice. De buildhulpprogramma's vullen de standaardservice-eigenschappen in:

Het aantal replicasets wordt bepaald door het persistentiekenmerk van uw actor. Telkens wanneer het persistentiekenmerk op uw actor wordt gewijzigd, wordt het aantal replicasets in de standaardservicedefinitie dienovereenkomstig opnieuw ingesteld.
Partitieschema en -bereik worden ingesteld op Uniform Int64 met het volledige Int64-sleutelbereik.

Service Fabric-partitieconcepten voor actoren

Actorservices zijn gepartitioneerde stateful services. Elke partitie van een actorservice bevat een set actoren. Servicepartities worden automatisch verdeeld over meerdere knooppunten in Service Fabric. Actorexemplaren worden als gevolg hiervan gedistribueerd.

Actor partitionering en distributie

Reliable Services kunnen worden gemaakt met verschillende partitieschema's en partitiesleutelbereiken. De actorservice maakt gebruik van het Int64-partitieschema met het volledige Int64-sleutelbereik om actoren toe te wijzen aan partities.

Actor-id

Aan elke actor die in de service is gemaakt, is een unieke id gekoppeld, vertegenwoordigd door de ActorId klasse. ActorId is een ondoorzichtige id-waarde die kan worden gebruikt voor een uniforme verdeling van actoren over de servicepartities door willekeurige id's te genereren:

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

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

Elke ActorId is gehasht naar een Int64. Daarom moet de actorservice een Int64-partitieschema gebruiken met het volledige Int64-sleutelbereik. Aangepaste id-waarden kunnen echter worden gebruikt voor een ActorID, inclusief GUID's/UUID's, tekenreeksen en Int64's.

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));

Wanneer u GUID's/UUID's en tekenreeksen gebruikt, worden de waarden gehasht naar een Int64. Wanneer u echter expliciet een Int64 aan een ActorIdopgeeft, wordt de Int64 rechtstreeks toegewezen aan een partitie zonder verdere hashing. U kunt deze techniek gebruiken om te bepalen in welke partitie de actoren worden geplaatst.

Delen via