Jak elementy Reliable Actors korzystają z platformy usługi Service Fabric
W tym artykule wyjaśniono, jak działają elementy Reliable Actors na platformie Azure Service Fabric. Funkcja Reliable Actors działa w strukturze hostowanej w implementacji stanowej niezawodnej usługi nazywanej usługą aktora. Usługa aktora zawiera wszystkie składniki niezbędne do zarządzania cyklem życia i wysyłaniem komunikatów dla aktorów:
- Środowisko uruchomieniowe aktora zarządza cyklem życia, odzyskiwaniem pamięci i wymusza dostęp jednowątkowy.
- Odbiornik komunikacji zdalnej usługi aktora akceptuje wywołania dostępu zdalnego do aktorów i wysyła je do dyspozytora w celu kierowania do odpowiedniego wystąpienia aktora.
- Dostawca stanu aktora opakowuje dostawców stanu (takich jak dostawca stanu Reliable Collections) i udostępnia kartę do zarządzania stanem aktora.
Te składniki tworzą strukturę Reliable Actor.
Warstwy usług
Ponieważ sama usługa aktora jest niezawodną usługą, wszystkie modele aplikacji, cykl życia, pakowanie, wdrażanie, uaktualnianie i skalowanie usług Reliable Services mają taki sam sposób zastosowania do usług aktorów.
Na powyższym diagramie przedstawiono relację między strukturami aplikacji usługi Service Fabric a kodem użytkownika. Niebieskie elementy reprezentują strukturę aplikacji Reliable Services, pomarańczową reprezentację platformy Reliable Actor, a kolor zielony reprezentuje kod użytkownika.
W usługach Reliable Services usługa dziedziczy klasę StatefulService . Ta klasa pochodzi od StatefulServiceBase (lub StatelessService dla usług bezstanowych). W usłudze Reliable Actors używasz usługi aktora. Usługa aktora to inna implementacja StatefulServiceBase klasy, która implementuje wzorzec aktora, w którym działają aktorzy. Ponieważ sama usługa aktora jest tylko implementacją StatefulServiceBaseprogramu , możesz napisać własną usługę, która pochodzi z ActorService funkcji na poziomie usługi i implementować funkcje na poziomie usług w taki sam sposób, jak w przypadku dziedziczenia StatefulService, na przykład:
- Tworzenie i przywracanie kopii zapasowej usługi.
- Udostępnione funkcje dla wszystkich aktorów, na przykład wyłącznika.
- Zdalne wywołania procedury dla samej usługi aktora i poszczególnych aktorów.
Aby uzyskać więcej informacji, zobacz Implementowanie funkcji na poziomie usługi w usłudze aktora.
Model aplikacji
Usługi aktorów są usługami Reliable Services, więc model aplikacji jest taki sam. Jednak narzędzia kompilacji platformy aktora generują niektóre pliki modelu aplikacji.
Manifest usługi
Narzędzia kompilacji platformy aktora automatycznie generują zawartość pliku ServiceManifest.xml usługi aktora. Ten plik zawiera następujące elementy:
- Typ usługi aktora. Nazwa typu jest generowana na podstawie nazwy projektu aktora. Na podstawie atrybutu trwałości aktora flaga HasPersistedState jest również ustawiona odpowiednio.
- Pakiet kodu.
- Pakiet konfiguracji.
- Zasoby i punkty końcowe.
Manifest aplikacji
Narzędzia kompilacji platformy aktora automatycznie tworzą domyślną definicję usługi dla twojego aktora. Narzędzia kompilacji wypełniają domyślne właściwości usługi:
- Liczba zestawów replik jest określana przez atrybut trwałości aktora. Za każdym razem, gdy atrybut trwałości aktora jest zmieniany, liczba zestawów replik w definicji usługi domyślnej jest odpowiednio resetowany.
- Schemat partycji i zakres są ustawione na Uniform Int64 z pełnym zakresem kluczy Int64.
Pojęcia dotyczące partycji usługi Service Fabric dla aktorów
Usługi aktora to partycjonowane usługi stanowe. Każda partycja usługi aktora zawiera zestaw aktorów. Partycje usługi są automatycznie dystrybuowane przez wiele węzłów w usłudze Service Fabric. Wystąpienia aktora są dystrybuowane w wyniku.
Usługi Reliable Services można tworzyć przy użyciu różnych schematów partycji i zakresów kluczy partycji. Usługa aktora używa schematu partycjonowania Int64 z pełnym zakresem kluczy Int64 do mapowania aktorów na partycje.
Identyfikator aktora
Każdy aktor utworzony w usłudze ma skojarzony unikatowy identyfikator reprezentowany przez klasę ActorId . ActorId jest nieprzezroczystą wartością identyfikatora, która może służyć do równomiernego rozkładu aktorów w partycjach usługi przez wygenerowanie losowych identyfikatorów:
ActorProxy.Create<IMyActor>(ActorId.CreateRandom());
ActorProxyBase.create<MyActor>(MyActor.class, ActorId.newId());
Każdy ActorId jest skrótem do int64. Dlatego usługa aktora musi używać schematu partycjonowania Int64 z pełnym zakresem kluczy Int64. Jednak niestandardowe wartości identyfikatorów mogą być używane dla ActorIDelementu , w tym identyfikatorów GUID/identyfikatorów UUID, ciągów i 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));
W przypadku używania identyfikatorów GUID/identyfikatorów UUID i ciągów wartości są skrótami do int64. Jeśli jednak jawnie udostępniasz int64 do ActorIdelementu , int64 mapuje się bezpośrednio na partycję bez dalszego tworzenia skrótów. Za pomocą tej techniki można kontrolować, w której partycji znajdują się aktorzy.