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

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?

Actor je izolovaná a nezávislá jednotka výpočetních prostředků a stavu s jednovláknovým prováděním. Model aktorů je výpočetní vzorec pro souběžné nebo distribuované systémy, ve kterých může velký počet těchto aktorů provádět úkoly 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 návrhového vzoru aktora. 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é doporučení: Zvažte použití vzorce herce pro modelování vašeho problému nebo scénáře, 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 actorů nebudou blokovat volající nepředvídatelnými zpožděními při provádění vstupně-výstupních operací.

Aktéři na platformě Service Fabric

V Service Fabric se aktéři implementují v rámci Reliable Actors: Aplikační rámec založený na vzoru 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ý actor je definován jako instance typu actor, stejně jako 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ý herec je jednoznačně identifikován ID herce.

Životnost herce

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 aktéra při prvním přijetí požadavku na ID tohoto aktéra. Pokud není aktér po určitou dobu používán, modul runtime Reliable Actors odstraní objekt z 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ší.

• Actor je automaticky aktivován (což způsobí vytvoření objektu actor) při prvním odeslání zprávy na jeho ID herce. Po určité době je objekt herce vyčištěn z paměti. V budoucnu použití ID objektu actor znovu způsobí, že se vytvoří nový objekt objektu actor. Stav aktéra, když je uložen ve správci stavu, přežívá životnost objektu.
• Volání jakékoli metody aktora pro ID aktora aktivuje tohoto aktora. Z tohoto důvodu konstruktor typů actor volá implicitně 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áni v době, kdy jsou na ně volány další metody, pokud aktéři vyžadují inicializační parametry od klienta. Neexistuje žádný jednotný vstupní bod pro aktivaci objektu actor z klienta.
• Ačkoli Reliable Actors implicitně vytváří objekty actora, můžete explicitně smazat actora a jeho stav.

Distribuce a přepnutí 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 rozdělenou stavovou službou Reliable Service. Distribuce, škálovatelnost, spolehlivost a automatické převzetí služeb při selhání jsou zajištěny tím, že aktéři běží uvnitř stavové spolehlivé služby nazývané Služba Actor.

Aktéři jsou rozděleni mezi oddíly služby herce a tyto oddíly jsou distribuovány mezi uzly v clusteru Service Fabric. Každý oddíl služby obsahuje sadu aktorů. Service Fabric spravuje distribuci a zajištění dostupnosti 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:

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

• Reliable Services umožňuje zvolit schéma dělení, klíčový rozsah (při použití schématu dělení rozsahu) a počet particí. 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 aktérů budou vždy vyžadovat síťovou komunikaci, včetně serializace a deserializace dat volání metody, což zvyšuje latenci a režii.
• V pokročilých scénářích je možné řídit umístění oddílů herce pomocí ID typu Int64, která se mapují na konkrétní oddíly. To ale může vést k nevyvážené distribuci aktorů napříč oddíly.

Další informace o tom, jak jsou služby aktérů rozděleny, najdete v konceptech dělení pro aktéry.

Komunikace aktorů

Interakce aktérů jsou definovány v rozhraní, které je sdíleno aktérem, jenž toto rozhraní implementuje, a klientem, který získá proxy k aktérovi prostřednictvím stejného rozhraní. Vzhledem k tomu, že toto rozhraní se používá k asynchronnímu vyvolání metod typu actor, musí každá metoda v rozhraní vracet úlohu.

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í actoru a klientem actoru. Pro komunikaci s aktérem klient vytvoří proxy objekt, který implementuje rozhraní aktéra. Klient interaguje s aktérem voláním metod na proxy objektu. Proxy herce lze použít pro komunikaci mezi klientem a hercem i pro komunikaci mezi herci.

// 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 dva údaje použité k vytvoření proxy objektu herce jsou ID herce 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řebnou realizaci pro vyhledání herce podle ID a otevření komunikačního kanálu s ním. Také se opakuje pokus o nalezení aktora v případech komunikačních chyb a při 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.

Konkurentnost

Modul runtime Reliable Actors poskytuje jednoduchý model přístupu na základě tahů k metodám herce. To znamená, že v kódu objektu aktéra nemůže být aktivní více než jedno vlákno najednou. Tahový přístup výrazně zjednodušuje souběžné systémy, protože není potřeba synchronizačních mechanismů pro přístup k datům. Také to znamená, že systémy musí být navrženy se zvláštními ohledy na povahu jednoho vlákna pro přístup k jednotlivým instancím aktéra.

• 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 a současně je na jednoho z aktérů proveden externí požadavek. 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í.

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

Krok se skládá z úplného provedení metody aktéra v reakci na požadavek od jiných aktérů nebo klientů, nebo z úplného provedení zpětného volání časovače či připomenutí. I když jsou tyto metody a zpětná volání asynchronní, běhové prostředí Actors je neprokládá. Před povolením nového turnu musí být otáčení zcela dokončeno. Jinými slovy, metoda herce nebo časovač či připomenutí, které právě běží, musí být plně dokončeny, než může být provedeno 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 na bázi střídání je respektována i u různých metod, časovačů a zpětných volání.

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 řízená po tazích vynucuje pro jednotlivé aktéry, nikoli mezi nimi. 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.

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

• Každá svislá čára zobrazuje logický tok provádění metody nebo zpětného volání pro konkrétního aktéra.
• 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 hercům.
• Zvýraznění se používá k označení doby trvání, po kterou se drží zámek na úrovni aktéra 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. Připomínací volání se spustí až po dokončení obou spuštění Method1. Všechno toto je způsobeno tím, že pro ActorId2 je vynucena souběžnost založená na tazích.
• 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 metod/zpětného volání se kód vrácený Task(C#) / CompletableFuture(Java) dokončí až po návratu metody. V některých případech je asynchronní operace dokončena v době, kdy se metoda nebo zpětné volání vrátí. V obou případech se zámek přiřazený k aktéru uvolní až poté, co se vrátí jak metoda, tak i zpětné volání, a dokončí se asynchronní operace.

Znovuvstupnost

Modul Actors runtime ve výchozím nastavení umožňuje znovuvstup. 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í s novým logickým kontextem volání. Další podrobnosti najdete v 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 vyvolání metod, které se provádějí v reakci na požadavky klienta, i pro časovače a 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 herce a připomenutí herce, které respektují souběžnost založenou na tazích.

Další kroky

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

• Začínáme s Reliable Actors v .NET
• Začínáme s Reliable Actors v Javě