Sdílet prostřednictvím

Seznámení se službou Service Fabric Reliable Actors

  • Článek

Reliable Actors je aplikační architektura Service Fabric založená na vzoru virtuálního objektu actor . Rozhraní RELIABLE Actors API poskytuje programovací model s jedním vláknem založený na zárukách škálovatelnosti a spolehlivosti poskytovaných Service Fabric.

Co jsou actors?

Objekt actor je izolovaná nezávislá jednotka výpočetních prostředků a stavu s prováděním s jedním vláknem. Model objektu actor je výpočetní model pro souběžné nebo distribuované systémy, ve kterých může velký počet těchto herců provádět současně a nezávisle na sobě. Aktéři spolu můžou komunikovat a můžou vytvářet více herců.

Kdy použít Reliable Actors

Service Fabric Reliable Actors je implementace vzoru návrhu objektu actor. Stejně jako u jakéhokoli vzoru návrhu softwaru se rozhodnutí, jestli se má použít konkrétní vzor, provádí na základě toho, jestli problém návrhu softwaru odpovídá vzoru.

I když vzor návrhu objektu actor může být vhodný pro řadu problémů a scénářů distribuovaných systémů, je nutné pečlivě zvážit omezení modelu a implementace architektury. Obecně platí, že model objektu actor modeluje váš problém nebo scénář, pokud:

  • Váš problémový prostor zahrnuje velké množství (tisíce nebo více) malých, nezávislých a izolovaných jednotek stavu a logiky.
  • Chcete pracovat s objekty s jedním vláknem, které nevyžadují významnou interakci z externích komponent, včetně dotazování stavu napříč sadou objektů actor.
  • Instance objektu actor nebudou blokovat volající s nepředvídatelnými zpožděními vydáváním vstupně-výstupních operací.

Aktéři ve službě Service Fabric

V Service Fabric se aktéři implementují v rámci Reliable Actors: Architektura aplikací založená na vzoru objektu actor založená na service fabric Reliable Services. Každá služba Reliable Actor, kterou napíšete, je ve skutečnosti dělenou stavovou spolehlivou službou.

Každý objekt actor je definován jako instance typu objektu actor, shodný se způsobem, jakým je objekt .NET instancí typu .NET. Může existovat například typ objektu actor, který implementuje funkce kalkulačky a může existovat mnoho herců tohoto typu, které jsou distribuovány na různých uzlech v clusteru. Každý takový objekt actor je jednoznačně identifikován ID objektu actor.

Životnost objektu actor

Aktéři Service Fabric jsou virtuální, což znamená, že jejich životnost není svázaná s reprezentací v paměti. V důsledku toho nemusí být explicitně vytvořeny ani zničeny. Modul runtime Reliable Actors automaticky aktivuje objekt actor při prvním přijetí požadavku na TOTO ID objektu actor. Pokud objekt actor není po určitou dobu používán, modul runtime Reliable Actors shromáždí objekt v paměti. Bude také udržovat znalosti o existenci herce, pokud bude nutné ji později znovu aktivovat. Další podrobnosti najdete v tématu Životní cyklus objektu Actor a uvolňování paměti.

Tato abstrakce životnosti virtuálního objektu actor přináší určité výstrahy v důsledku modelu virtuálního objektu actor a ve skutečnosti implementace Reliable Actors se v některých případech od tohoto modelu liší.

  • Objekt actor se automaticky aktivuje (což způsobí vytvoření objektu objektu actor) při prvním odeslání zprávy do ID objektu actor. Po určité době je objekt objektu actor uvolněný z paměti. V budoucnu použití ID objektu actor znovu způsobí, že se vytvoří nový objekt objektu actor. Stav objektu, který je uložen ve správci stavu, prožívá životnost objektu.
  • Volání jakékoli metody objektu actor pro ID objektu actor aktivuje tento objekt actor. Z tohoto důvodu mají typy objektu actor svůj konstruktor, který implicitně nazývá modul runtime. Proto kód klienta nemůže předat parametry konstruktoru typu objektu actor, ačkoli parametry mohou být předány konstruktoru objektu actor samotnou službou. Výsledkem je, že aktéři mohou být částečně inicializovány v době, kdy jsou na něm volána další metody, pokud objekt actor vyžaduje inicializační parametry z klienta. Pro aktivaci objektu actor z klienta neexistuje žádný vstupní bod.
  • I když Reliable Actors implicitně vytváří objekty objekty objektu actor; máte možnost explicitně odstranit objekt actor a jeho stav.

Distribuce a převzetí služeb při selhání

Kvůli zajištění škálovatelnosti a spolehlivosti Service Fabric distribuuje aktéry v celém clusteru a podle potřeby je automaticky migruje z neúspěšných uzlů na uzly, které jsou v pořádku. Toto je abstrakce nad dělenou stavovou službou Reliable Service. Distribuce, škálovatelnost, spolehlivost a automatické převzetí služeb při selhání jsou poskytovány na základě skutečnosti, že aktéři běží uvnitř stavové spolehlivé služby označované jako služba actor.

Aktéři se distribuují napříč oddíly služby actor a tyto oddíly se distribuují mezi uzly v clusteru Service Fabric. Každý oddíl služby obsahuje sadu objektů actor. Service Fabric spravuje distribuci a převzetí služeb při selhání oddílů služby.

Například služba actor s devíti oddíly nasazenými do tří uzlů pomocí výchozího umístění oddílu objektu actor by se distribuovala takto:

Distribuce Reliable Actors

Architektura actor spravuje schéma oddílů a nastavení rozsahu klíčů za vás. To zjednodušuje některé volby, ale také je třeba vzít v úvahu:

  • Reliable Services umožňuje zvolit schéma dělení, rozsah klíčů (při použití schématu dělení rozsahu) a počet oddílů. Reliable Actors je omezeno na schéma dělení rozsahu (jednotné schéma Int64) a vyžaduje, abyste použili úplný rozsah klíčů Int64.
  • Ve výchozím nastavení jsou aktéři náhodně umístěni do oddílů, což vede k jednotnému rozdělení.
  • Vzhledem k tomu, že jsou aktéři náhodně umístěni, je třeba očekávat, že operace objektu actor budou vždy vyžadovat síťovou komunikaci, včetně serializace a deserializace dat volání metody, v důsledku latence a režie.
  • V pokročilých scénářích je možné řídit umístění oddílů objektu actor pomocí ID objektu actor Int64, která se mapují na konkrétní oddíly. To ale může vést k nevyvážené distribuci objektů actor napříč oddíly.

Další informace o tom, jak jsou služby actor rozdělené na oddíly, najdete v konceptech dělení objektů actor pro aktéry.

Komunikace objektu actor

Interakce objektu actor jsou definovány v rozhraní, které je sdíleno objektem actor, který implementuje rozhraní, a klient, který získá proxy server objektu actor přes stejné rozhraní. Vzhledem k tomu, že toto rozhraní se používá k asynchronnímu vyvolání metod objektu actor, musí být každá metoda v rozhraní vrácena úlohou.

Volání metody a jejich odpovědi nakonec vedou k síťovým požadavkům v clusteru, takže argumenty a typy výsledků úloh, které vrací, musí být serializovatelné platformou. Konkrétně musí být data contract serializovatelná.

Proxy objektu actor

Rozhraní API klienta Reliable Actors poskytuje komunikaci mezi instancí objektu actor a klientem objektu actor. Pro komunikaci s objektem actor vytvoří klient objekt proxy objekt objektu objektu actor, který implementuje rozhraní objektu actor. Klient komunikuje s objektem actor vyvoláním metod na objektu proxy. Proxy objektu actor lze použít pro komunikaci mezi klientem a objektem actor-to-actor.

// Create a randomly distributed actor ID
ActorId actorId = ActorId.CreateRandom();

// This only creates a proxy object, it does not activate an actor or invoke any methods yet.
IMyActor myActor = ActorProxy.Create<IMyActor>(actorId, new Uri("fabric:/MyApp/MyActorService"));

// This will invoke a method on the actor. If an actor with the given ID does not exist, it will be activated by this method call.
await myActor.DoWorkAsync();

// Create actor ID with some name
ActorId actorId = new ActorId("Actor1");

// This only creates a proxy object, it does not activate an actor or invoke any methods yet.
MyActor myActor = ActorProxyBase.create(actorId, new URI("fabric:/MyApp/MyActorService"), MyActor.class);

// This will invoke a method on the actor. If an actor with the given ID does not exist, it will be activated by this method call.
myActor.DoWorkAsync().get();

Všimněte si, že dvě informace použité k vytvoření objektu proxy objektu objektu actor jsou ID objektu objektu actor a název aplikace. ID objektu actor jednoznačně identifikuje objekt actor, zatímco název aplikace identifikuje aplikaci Service Fabric, ve které je objekt actor nasazený.

Třída ActorProxy(C#) / ActorProxyBase(Java) na straně klienta provádí potřebné řešení k vyhledání objektu actor podle ID a otevření komunikačního kanálu s ním. Opakuje se také pokus o vyhledání objektu actor v případech selhání komunikace a převzetí služeb při selhání. V důsledku toho má doručení zpráv následující charakteristiky:

  • Doručování zpráv je nejlepší úsilí.
  • Aktéři mohou přijímat duplicitní zprávy ze stejného klienta.

Souběžnost

Modul runtime Reliable Actors poskytuje jednoduchý model přístupu na základě přístupu pro přístup k metodám objektu actor. To znamená, že v kódu objektu objektu objektu actor může být kdykoli aktivní více než jedno vlákno. Přístup založený na turn výrazně zjednodušuje souběžné systémy, protože není nutné provádět synchronizační mechanismy pro přístup k datům. Také to znamená, že systémy musí být navrženy se zvláštními aspekty pro přístup k jednotlivým instancím objektu actor s jedním vláknem.

  • Instance jednoho objektu actor nemůže zpracovat více než jeden požadavek najednou. Instance objektu actor může způsobit kritický bod propustnosti, pokud se očekává, že bude zpracovávat souběžné požadavky.
  • Aktéři se můžou vzájemně zablokovat, pokud je mezi dvěma aktéry cyklický požadavek, zatímco externí požadavek se provádí na jednom z herců současně. Modul runtime objektu actor automaticky vyprší časový limit volání objektu actor a vyvolá výjimku volajícího, aby přerušil možné situace zablokování.

Komunikace Reliable Actors

Přístup založený na turn-based

Otočení se skládá z úplného spuštění metody objektu actor v reakci na požadavek od jiných aktérů nebo klientů nebo dokončení provádění zpětného volání časovače nebo připomenutí . I když jsou tyto metody a zpětná volání asynchronní, modul runtime Actors je neprokládá. Před povolením nového turnu musí být otáčení zcela dokončeno. Jinými slovy, metoda objektu actor nebo časovač nebo zpětné volání připomenutí, které se právě spouští, musí být plně dokončeny, než bude povoleno nové volání metody nebo zpětného volání. Metoda nebo zpětné volání se považuje za dokončené, pokud se provádění vrátilo z metody nebo zpětného volání a úloha vrácená metodou nebo zpětné volání byla dokončena. Stojí za to zdůraznit, že souběžnost založená na turnu se respektuje i napříč různými metodami, časovači a zpětnými voláními.

Modul runtime Actors vynucuje souběžnost na základě turn tím, že na začátku turnu získá zámek objektu actor a uvolní zámek na konci turnu. Proto se souběžnost na základě turnu vynucuje pro jednotlivé objekty actor, nikoli mezi aktéry. Metody objektu actor a zpětné volání časovače nebo připomenutí se můžou spouštět souběžně jménem různých herců.

Následující příklad ukazuje výše uvedené koncepty. Zvažte typ objektu actor, který implementuje dvě asynchronní metody (například Method1 a Method2), časovač a připomenutí. Následující diagram znázorňuje příklad časové osy pro spuštění těchto metod a zpětné volání jménem dvou herců (ActorId1 a ActorId2), které patří tomuto typu objektu actor.

Modul runtime Reliable Actors na základě souběžnosti a přístupu

Tento diagram se řídí těmito konvencemi:

  • Každá svislá čára zobrazuje logický tok spuštění metody nebo zpětného volání jménem konkrétního objektu actor.
  • Události označené na každé svislé přímce se vyskytují v chronologickém pořadí s novějšími událostmi, ke kterým dochází pod staršími.
  • Různé barvy se používají pro časové osy odpovídající různým objektům actor.
  • Zvýraznění se používá k označení doby trvání, po kterou se zámek objektu actor uchovává jménem metody nebo zpětného volání.

Některé důležité body, které je potřeba vzít v úvahu:

  • Zatímco Metoda1 provádí jménem ActorId2 v reakci na požadavek klienta xyz789, dorazí jiný požadavek klienta (abc123), který také vyžaduje , aby metoda Method1 byla spuštěna objektem ActorId2. Druhé spuštění metody Method1 se však nezačne, dokud se nedokončí předchozí spuštění. Podobně se aktivuje připomenutí registrované objektem ActorId2 , zatímco metoda1 se spouští v reakci na požadavek klienta xyz789. Zpětné volání připomenutí se spustí až po dokončení obou spuštění metody Method1 . Důvodem je vynucení souběžnosti na základě turn pro ActorId2.
  • Podobně se pro ActorId1 vynucuje souběžnost založená na turnu, jak ukazuje spuštění metody Method1, Method2 a zpětného volání časovače jménem ActorId1, které se provádí sériově.
  • Spuštění metody Method1 jménem ActorId1 se překrývá s jeho spuštěním jménem ActorId2. Důvodem je to, že souběžnost založená na turnu se vynucuje pouze v rámci objektu actor, a ne v rámci herců.
  • V některých spuštěních Taskmetod/zpětného volání se dokončí (C#) / CompletableFuture(Java) vrácená metodou nebo zpětném voláním po vrácení metody. V některých jiných už asynchronní operace dokončila čas, kdy metoda nebo zpětné volání vrátí. V obou případech se zámek objektu actor uvolní až po vrácení metody nebo zpětného volání a dokončení asynchronní operace.

Vícenásobný přístup

Modul runtime Actors ve výchozím nastavení umožňuje znovu zadat architekturu. To znamená, že pokud metoda objektu actor A volá metodu objektu Actor B, která pak volá jinou metodu objektu Actor A, je tato metoda povolena ke spuštění. Je to proto, že je součástí stejného kontextu logického řetězce volání. Všechna volání časovače a připomenutí začínají novým kontextem logického volání. Další podrobnosti najdete v reentrancy Reliable Actors.

Rozsah záruk souběžnosti

Modul runtime Actors poskytuje tyto záruky souběžnosti v situacích, kdy řídí vyvolání těchto metod. Poskytuje například tyto záruky pro vyvolání metody, které se provádějí v reakci na požadavek klienta, stejně jako pro časovače a zpětné volání připomenutí. Pokud však kód objektu actor přímo vyvolá tyto metody mimo mechanismy poskytované modulem Runtime Actors, nemůže modul runtime poskytnout žádné záruky souběžnosti. Pokud je například metoda vyvolána v kontextu některé úlohy, která není přidružena k úkolu vráceným metodami objektu actor, pak modul runtime nemůže poskytnout záruky souběžnosti. Pokud je metoda vyvolána z vlákna, které objekt actor vytvoří sám, pak modul runtime také nemůže poskytnout záruky souběžnosti. Proto k provádění operací na pozadí by herci měli používat časovače objektu actor a připomenutí herců, které respektují souběžnost na základě turn.

Další kroky

Začněte vytvořením první služby Reliable Actors: