Úvod do Service Fabric Reliable Actors

  • Článek

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

Co jsou aktéři?

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ém může velký počet těchto aktérů provádět současně a nezávisle na sobě. Aktéři spolu můžou komunikovat a můžou vytvářet další aktéry.

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í, zda použít konkrétní vzor, provádí na základě toho, jestli problém návrhu softwaru odpovídá danému 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 třeba pečlivě zvážit omezení vzoru a architektury, která ho implementuje. Jako obecné pokyny zvažte model objektu actor pro modelování problému nebo scénáře v následujících případech:

  • Váš problémový prostor zahrnuje velký počet (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 externích komponent, včetně dotazování stavu napříč sadou objektů.
  • Instance objektu actor nebudou blokovat volající s nepředvídatelnými zpožděními tím, že budou provádět vstupně-výstupní operace.

Aktéři ve službě Service Fabric

Ve Službě Service Fabric se aktéři implementují v architektuře Reliable Actors: Aplikační architektura založená na vzoru objektu actor postavená 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, který je identický se způsobem, jakým je objekt .NET instancí typu .NET. Může například existovat typ objektu actor, který implementuje funkce kalkulačky, a může existovat mnoho herců tohoto typu, které se distribuují na různých uzlech v rámci clusteru. Každý takový aktér je jedineč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 jejich reprezentací v paměti. V důsledku toho není nutné je explicitně vytvářet ani ničit. Modul runtime Reliable Actors automaticky aktivuje objekt actor při prvním přijetí požadavku na ID objektu actor. Pokud se objekt actor po určitou dobu nepoužívá, modul runtime Reliable Actors vyhodí objekt v paměti. Bude si také udržovat znalosti o existenci aktéra, pokud bude později potřeba ho znovu aktivovat. Další podrobnosti najdete v tématu Životní cyklus a uvolňování paměti objektu Actor.

Tato abstrakce životnosti virtuálního objektu actor přináší určitá upozornění jako výsledek modelu virtuálního objektu actor a implementace Reliable Actors se ve skutečnosti občas od tohoto modelu odchyluje.

  • Objekt actor je automaticky aktivován (což způsobí, že objekt actor se vytvoří) při prvním odeslání zprávy do id objektu actor. Po určité době dojde k uvolnění objektu actor. V budoucnu opětovné použití ID objektu actor způsobí vytvoření nového objektu actor. Stav objektu herce přežije životnost objektu, když je uložen ve správci stavu.
  • Volání libovolné metody actor pro ID objektu actor aktivuje tento objekt actor. Z tohoto důvodu mají typy objektů actor svůj konstruktor volaný implicitně modulem runtime. Proto klientský kód 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 vytvořeny v částečně inicializovaném stavu v době, kdy jsou na něm volány jiné metody, pokud objekt actor vyžaduje parametry inicializace z klienta. Neexistuje jediný vstupní bod pro aktivaci objektu actor z klienta.
  • Ačkoli Reliable Actors implicitně vytváří objekty 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 Služba Service Fabric distribuuje aktéry v celém clusteru a podle potřeby je automaticky migruje z uzlů, které selhaly, do uzlů, které jsou v pořádku. Jedná se o abstrakci dělené stavové služby 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ěží ve stavové spolehlivé službě 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 herců. 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ílů objektu actor by se distribuovala takto:

Distribuce Reliable Actors

Rozhraní Actor Framework spravuje schéma oddílů a nastavení rozsahu klíčů za vás. To zjednodušuje některé volby, ale také to přináší určité aspekty:

  • 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 omezený 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í se aktéři náhodně umisťují do oddílů, což vede k rovnoměrné distribuci.
  • Vzhledem k tomu, že aktéři jsou umístěni náhodně, 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, a to s latencí a režií.
  • V pokročilých scénářích je možné řídit umístění oddílů objektu actor pomocí ID objektů actor Int64, která se mapují na konkrétní oddíly. To ale může vést k nevyvážené distribuci herců mezi oddíly.

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

Komunikace objektu actor

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

Volání metod a jejich odpovědi nakonec vedou k síťovým požadavkům v rámci clusteru, takže argumenty a typy výsledků úkolů, které vracejí, musí být serializovatelné platformou. Musí být zejména serializovatelné pro kontrakt dat.

Proxy objektu actor

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

// 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 actor jsou ID 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 provede potřebné řešení k vyhledání objektu actor podle ID a otevření komunikačního kanálu s ním. V případě selhání komunikace a převzetí služeb při selhání se také znovu pokusí najít objekt actor. V důsledku toho má doručování zpráv následující vlastnosti:

  • Doručování zpráv je maximální úsilí.
  • Aktéři můžou od stejného klienta přijímat duplicitní zprávy.

Souběžnost

Modul runtime Reliable Actors poskytuje jednoduchý model přístupu na základě tahu pro přístup k metodám objektu actor. To znamená, že v kódu objektu actor nemůže být aktivní více než jedno vlákno. Tahový přístup výrazně zjednodušuje souběžné systémy, protože pro přístup k datům nejsou potřeba synchronizační mechanismy. To také znamená, že systémy musí být navrženy se zvláštními aspekty z hlediska přístupu jednotlivých instancí objektu actor s jedním vláknem.

  • Jedna instance 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 zpracovává souběžné požadavky.
  • Aktéři se můžou vzájemně vzájemně zablokovat, pokud mezi dvěma aktéry existuje cyklický požadavek, zatímco je externí požadavek na jednoho z aktérů proveden současně. Modul runtime objektu actor automaticky vyprší časový limit při voláních objektu actor a volajícímu vyvolá výjimku, která přeruší možné situace vzájemného zablokování.

Reliable Actors – komunikace

Přístup na základě na základě

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 z úplného spuště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é zatáčení musí být otočení zcela dokončeno. Jinými slovy, metoda objektu actor nebo zpětné volání časovače nebo připomenutí, které se právě spouští, musí být zcela dokončeny před povolením nového volání metody nebo zpětného volání. Metoda nebo zpětné volání se považuje za dokončené, pokud se spuštění vrátilo z metody nebo zpětného volání a úloha vrácená metodou nebo zpětným voláním byla dokončena. Je vhodné zdůraznit, že turn-based souběžnost je respektována i napříč různými metodami, časovači a zpětnými voláními.

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

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

Tahová souběžnost a přístup modulu runtime Reliable Actors

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 aktéra.
  • Události označené na každé svislé čáře se vyskytují v chronologickém pořadí, přičemž novější události se vyskytují pod těmi staršími.
  • Různé barvy se používají pro časové osy odpovídající různým aktérům.
  • Zvýraznění se používá k označení doby trvání, po kterou se zámek pro aktéra uchovává jménem metody nebo zpětného volání.

Některé důležité body, které je třeba zvážit:

  • Zatímco metoda1 provádí jménem actorId2 v reakci na požadavek klienta xyz789, přijde další požadavek klienta (abc123), který také vyžaduje metodu Method1 provést actorId2. Druhé spuštění metody Method1 se však nezačne, dokud se nedokončí předchozí spuštění. Podobně připomenutí zaregistrované objektem ActorId2 se aktivuje při provádění metody Method1 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 . To vše je způsobeno vynucenou souběžností na základě tahu pro ActorId2.
  • Podobně se pro ActorId1 vynucuje také souběžnost na základě tahu, což ukazuje spuštění metody Method1, Method2 a zpětného volání časovače jménem ActorId1 , které probíhá sériově.
  • Provádění metody Method1 jménem ActorId1 se překrývá s jeho spuštěním jménem ActorId2. Je to proto, že souběžnost na základě tahu se vynucuje pouze v rámci objektu actor, a ne napříč aktéry.
  • V některých spuštěních Taskmetody nebo zpětného volání se (C#) / CompletableFuture(Java) vrácená metodou nebo zpětným voláním dokončí po vrácení metody. V některých jiných je asynchronní operace již dokončena v době, 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 opakované zaentrancy. To znamená, že pokud metoda actor objektu Actor A volá metodu v objektu Actor B, která zase volá jinou metodu v objektu Actor A, je možné tuto metodu spustit. Je to proto, že je součástí stejného logického kontextu řetězu volání. Všechna volání časovače a připomenutí začínají novým logickým kontextem volání. Další podrobnosti najdete v tématu Reliable Actors reentrancy .

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 volání metody, která se provádí v reakci na požadavek klienta, a také pro časovač a připomenutí volání. Pokud však kód objektu actor tyto metody přímo vyvolá mimo mechanismy poskytované modulem runtime actors, pak modul runtime nemůže 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ého 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 by herci k provádění operací na pozadí měli používat časovače a připomenutí objektu actor , které respektují souběžnost na základě tahu.

Další kroky

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