Model hostingu usługi Azure Service Fabric

Ten artykuł zawiera omówienie modeli hostowania aplikacji udostępnianych przez usługę Azure Service Fabric i opisuje różnice między modelami procesu współużytkowanego i wyłącznego procesu . Opisano w nim sposób, w jaki wdrożona aplikacja wygląda na węźle usługi Service Fabric oraz relację między replikami (lub wystąpieniami) usługi i procesem hosta usługi.

Przed kontynuowaniem upewnij się, że rozumiesz różne pojęcia i relacje wyjaśnione w temacie Model an application in Service Fabric (Modelowanie aplikacji w usłudze Service Fabric).

Uwaga

W tym artykule, chyba że jawnie wspomniano o czymś innym:

• Replika odwołuje się zarówno do repliki usługi stanowej, jak i wystąpienia usługi bezstanowej.
• Pakiet CodePackage jest traktowany jako odpowiednik procesu ServiceHost , który rejestruje element ServiceType i hostuje repliki usług tego typu usługi.

Aby zrozumieć model hostingu, zapoznajmy się z przykładem. Załóżmy, że mamy typ aplikacji "MyAppType", który ma typ usługi "MyServiceType ". Element "MyServiceType" jest dostarczany przez pakiet ServicePackage "MyServicePackage", który ma pakiet CodePackage "MyCodePackage". Polecenie "MyCodePackage" rejestruje parametr ServiceType "MyServiceType", gdy jest uruchamiany.

Załóżmy, że mamy klaster z trzema węzłami i utworzymy sieć szkieletową aplikacji:/App1 typu "MyAppType". Wewnątrz tej sieci szkieletowej aplikacji:/App1 utworzymy usługę service fabric:/App1/ServiceA typu "MyServiceType". Ta usługa ma dwie partycje (na przykład P1 i P2) oraz trzy repliki na partycję. Na poniższym diagramie przedstawiono widok tej aplikacji po zakończeniu wdrażania w węźle.

Usługa Service Fabric aktywowała element "MyServicePackage", który uruchomił pakiet "MyCodePackage", który hostuje repliki z obu partycji. Wszystkie węzły w klastrze mają ten sam widok, ponieważ wybraliśmy liczbę replik na partycję, która będzie równa liczbie węzłów w klastrze. Utwórzmy inną usługę , sieć szkieletową:/App1/ServiceB w sieci szkieletowej aplikacji:/App1. Ta usługa ma jedną partycję (na przykład P3) i trzy repliki na partycję. Na poniższym diagramie przedstawiono nowy widok w węźle:

Usługa Service Fabric umieściła nową replikę dla partycji P3 usługi Service Fabric:/App1/ServiceB w istniejącej aktywacji elementu "MyServicePackage". Nwo. Utwórzmy inną sieć szkieletową aplikacji:/App2 typu "MyAppType". Wewnątrz sieci szkieletowej:/App2 utwórz usługę service fabric:/App2/ServiceA. Ta usługa ma dwie partycje (P4 i P5) oraz trzy repliki na partycję. Na poniższym diagramie przedstawiono nowy widok węzła:

Usługa Service Fabric aktywuje nową kopię elementu "MyServicePackage", która uruchamia nową kopię elementu "MyCodePackage". Repliki z obu partycji usługi Service Fabric:/App2/ServiceA (P4 i P5) są umieszczane w tej nowej kopii "MyCodePackage".

Model współużytkowanego procesu

W poprzedniej sekcji opisano domyślny model hostingu udostępniany przez usługę Service Fabric, nazywany modelem procesu współużytkowanego. W tym modelu dla danej aplikacji aktywowano tylko jedną kopię danego pakietu ServicePackage w węźle (który uruchamia wszystkie zawarte w nim pakiety CodePackage ). Wszystkie repliki wszystkich usług danego elementu ServiceType są umieszczane w kodziePackage , który rejestruje ten typ usługi. Innymi słowy, wszystkie repliki wszystkich usług w węźle danego elementu ServiceType współużytkuje ten sam proces.

Model wyłącznych procesów

Innym modelem hostingu dostarczonym przez usługę Service Fabric jest model procesów wyłącznych. W tym modelu w danym węźle każda replika znajduje się we własnym dedykowanym procesie. Usługa Service Fabric aktywuje nową kopię pakietu ServicePackage (która uruchamia wszystkie zawarte w nim pakiety CodePackage ). Repliki są umieszczane w kodziePackage , który zarejestrował parametr ServiceType usługi, do której należy replika.

Jeśli używasz usługi Service Fabric w wersji 5.6 lub nowszej, możesz wybrać model procesu wyłącznego podczas tworzenia usługi (przy użyciu programu PowerShell, REST lub FabricClient). Określ wartość ServicePackageActivationMode jako "ExclusiveProcess".

PS C:\>New-ServiceFabricService -ApplicationName "fabric:/App1" -ServiceName "fabric:/App1/ServiceA" -ServiceTypeName "MyServiceType" -Stateless -PartitionSchemeSingleton -InstanceCount -1 -ServicePackageActivationMode "ExclusiveProcess"

var serviceDescription = new StatelessServiceDescription
{
    ApplicationName = new Uri("fabric:/App1"),
    ServiceName = new Uri("fabric:/App1/ServiceA"),
    ServiceTypeName = "MyServiceType",
    PartitionSchemeDescription = new SingletonPartitionSchemeDescription(),
    InstanceCount = -1,
    ServicePackageActivationMode = ServicePackageActivationMode.ExclusiveProcess
};

var fabricClient = new FabricClient(clusterEndpoints);
await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

Jeśli masz usługę domyślną w manifeście aplikacji, możesz wybrać model Wyłączny proces, określając atrybut ServicePackageActivationMode :

<DefaultServices>
  <Service Name="MyService" ServicePackageActivationMode="ExclusiveProcess">
    <StatelessService ServiceTypeName="MyServiceType" InstanceCount="1">
      <SingletonPartition/>
    </StatelessService>
  </Service>
</DefaultServices>

Teraz utwórzmy kolejną usługę fabric:/App1/ServiceC w usłudze application fabric:/App1. Ta usługa ma dwie partycje (na przykład P6 i P7) oraz trzy repliki na partycję. Należy ustawić wartość ServicePackageActivationMode na wartość "ExclusiveProcess". Na poniższym diagramie przedstawiono nowy widok w węźle:

Jak widać, usługa Service Fabric aktywowała dwie nowe kopie pakietu "MyServicePackage" (po jednej dla każdej repliki z partycji P6 i P7). Usługa Service Fabric umieściła każdą replikę w dedykowanej kopii pakietu CodePackage. W przypadku korzystania z modelu procesu wyłącznego dla danej aplikacji wiele kopii danego pakietu ServicePackage może być aktywnych w węźle. W poprzednim przykładzie trzy kopie elementu "MyServicePackage" są aktywne dla sieci szkieletowej:/App1. Każda z tych aktywnych kopii elementu "MyServicePackage" ma skojarzony identyfikator ServicePackageActivationId . Ten identyfikator identyfikuje tę kopię w sieci szkieletowej aplikacji:/App1.

W przypadku używania tylko modelu procesu współużytkowanego dla aplikacji istnieje tylko jedna aktywna kopia pakietu ServicePackage w węźle. Identyfikator ServicePackageActivationId dla tej aktywacji pakietu ServicePackage jest pustym ciągiem. Jest to na przykład przypadek z elementem fabric:/App2.

Uwaga

• Model hostingu współużytkowanego procesu odpowiada właściwości ServicePackageActivationMode równe SharedProcess. Jest to domyślny model hostingu, a element ServicePackageActivationMode nie musi być określony w momencie tworzenia usługi.

• Model hostingu Wyłączny proces odpowiada właściwości ServicePackageActivationMode równe ExclusiveProcess. Aby użyć tego ustawienia, należy określić ją jawnie podczas tworzenia usługi.

• Aby wyświetlić model hostingu usługi, wykonaj zapytanie dotyczące opisu usługi i przyjrzyj się wartości Elementu ServicePackageActivationMode.

Praca z wdrożonym pakietem usługi

Aktywna kopia pakietu ServicePackage w węźle jest nazywana wdrożonym pakietem usługi. W przypadku korzystania z modelu Wyłączny proces do tworzenia usług dla danej aplikacji może istnieć wiele wdrożonych pakietów usług dla tego samego pakietu ServicePackage. Jeśli wykonujesz operacje specyficzne dla wdrożonego pakietu usługi, należy podać parametr ServicePackageActivationId w celu zidentyfikowania określonego wdrożonego pakietu usługi. Podaj na przykład identyfikator, jeśli zgłaszasz kondycję wdrożonego pakietu usługi lub ponownie uruchamiasz pakiet kodu wdrożonego pakietu usługi.

Identyfikator ServicePackageActivationId wdrożonego pakietu usługi można znaleźć, wysyłając zapytanie do listy wdrożonych pakietów usług w węźle. Podczas wykonywania zapytań dotyczących wdrożonych typów usług, wdrożonych replik i wdrożonych pakietów kodu w węźle wynik zapytania zawiera również identyfikator ServicePackageActivationId nadrzędnego wdrożonego pakietu usługi.

Uwaga

• W ramach modelu hostingu współużytkowanego procesu w danym węźle dla danej aplikacji aktywowano tylko jedną kopię pakietu ServicePackage . Ma wartość ServicePackageActivationId równą pusty ciąg i nie trzeba jej określać podczas wykonywania operacji związanych z wdrożonym pakietem usługi.

• W ramach modelu hostingu Wyłączny proces w danym węźle dla danej aplikacji może być aktywna co najmniej jedna kopia pakietu ServicePackage . Każda aktywacja ma niepustą wartość ServicePackageActivationId określoną podczas wykonywania operacji związanych z wdrożonym pakietem usługi.

• Jeśli identyfikator ServicePackageActivationId zostanie pominięty, domyślnie jest pusty ciąg. Jeśli wdrożony pakiet usługi, który został aktywowany w ramach modelu procesu współużytkowanego, operacja zostanie wykonana na nim. W przeciwnym razie operacja zakończy się niepowodzeniem.

• Nie wysyłaj zapytań raz i buforuj identyfikator ServicePackageActivationId. Identyfikator jest generowany dynamicznie i może ulec zmianie z różnych powodów. Przed wykonaniem operacji wymagającej identyfikatora ServicePackageActivationId należy najpierw wykonać zapytanie dotyczące listy wdrożonych pakietów usług w węźle. Następnie użyj identyfikatora ServicePackageActivationId z wyniku zapytania, aby wykonać oryginalną operację.

Aplikacje wykonywalne i kontenery gościa

Usługa Service Fabric traktuje aplikacje wykonywalne gościa i kontenera jako usługi bezstanowe, które są samodzielne. W usłudze ServiceHost nie ma środowiska uruchomieniowego usługi Service Fabric (procesu lub kontenera). Ponieważ te usługi są samodzielne, liczba replik na serviceHost nie ma zastosowania do tych usług. Najbardziej typową konfiguracją używaną z tymi usługami jest pojedyncza partycja z wartością InstanceCount równą -1 (jedna kopia kodu usługi uruchomionego w każdym węźle klastra).

Domyślna wartość ServicePackageActivationMode dla tych usług to SharedProcess, w tym przypadku usługa Service Fabric aktywuje tylko jedną kopię pakietu ServicePackage w węźle dla danej aplikacji. Oznacza to, że tylko jedna kopia kodu usługi uruchomi węzeł. Jeśli chcesz, aby wiele kopii kodu usługi było uruchamianych w węźle, określ wartość ServicePackageActivationMode jako ExclusiveProcess w momencie tworzenia usługi. Można to zrobić na przykład podczas tworzenia wielu usług (Service1 to ServiceN) typu ServiceType (określonego w plikuServiceManifest) lub gdy usługa jest podzielona na wiele partycji.

Zmienianie modelu hostingu istniejącej usługi

Obecnie nie można zmienić modelu hostingu istniejącej usługi z procesu udostępnionego na wyłączność (lub odwrotnie).

Wybór między modelami hostingu

Należy ocenić, który model hostingu najlepiej spełnia twoje wymagania. Model współużytkowanego procesu korzysta z zasobów systemu operacyjnego lepiej, ponieważ jest tworzonych mniej procesów, a wiele replik w tym samym procesie może współużytkować porty. Jeśli jednak jedna z replik ma błąd polegający na tym, że musi obniżyć hosta usługi, ma wpływ na wszystkie inne repliki w tym samym procesie.

Model Procesu wyłącznego zapewnia lepszą izolację, z każdą repliką we własnym procesie. Jeśli jedna z replik ma błąd, nie ma to wpływu na inne repliki. Ten model jest przydatny w przypadkach, gdy udostępnianie portów nie jest obsługiwane przez protokół komunikacyjny. Ułatwia to stosowanie ładu zasobów na poziomie repliki. Jednak proces wyłączny zużywa więcej zasobów systemu operacyjnego, ponieważ duplikuje jeden proces dla każdej repliki w węźle.

Zagadnienia dotyczące wyłącznego modelu procesów i modelu aplikacji

W przypadku większości aplikacji można modelować aplikację w usłudze Service Fabric, zachowując jeden parametr ServiceType na pakiet ServicePackage.

W niektórych przypadkach usługa Service Fabric zezwala również na więcej niż jeden parametr ServiceType na pakiet ServicePackage (a jeden pakiet CodePackage może zarejestrować więcej niż jeden typ usługi). Poniżej przedstawiono niektóre scenariusze, w których te konfiguracje mogą być przydatne:

• Chcesz zoptymalizować wykorzystanie zasobów przez zduplikowanie mniejszej liczby procesów i większą gęstość replik na proces.
• Repliki z różnych typów usługi muszą współdzielić niektóre typowe dane, które mają wysoki koszt inicjowania lub pamięci.
• Masz bezpłatną ofertę usług i chcesz ograniczyć wykorzystanie zasobów, umieszczając wszystkie repliki usługi w tym samym procesie.

Model hostingu procesów wyłącznych nie jest spójny z modelem aplikacji z wieloma typami usługi na pakiet ServicePackage. Jest to spowodowane tym, że wiele typów usług na pakiet ServicePackage zaprojektowano w celu osiągnięcia wyższego udostępniania zasobów między replikami i zapewnia większą gęstość replik na proces. Model wyłącznych procesów został zaprojektowany w celu osiągnięcia różnych wyników.

Rozważmy przypadek wielu typów usług na pakiet ServicePackage z innym pakietem CodePackage rejestrującym każdy typ usługi. Załóżmy, że mamy pakiet ServicePackage "MultiTypeServicePackage", który ma dwa pakiety CodePackage:

• "MyCodePackageA", który rejestruje typ usługi "MyServiceTypeA ".
• "MyCodePackageB", który rejestruje typ usługi "MyServiceTypeB ".

Teraz załóżmy, że utworzymy aplikację fabric :/SpecialApp. Wewnątrz sieci szkieletowej:/SpecialApp tworzymy następujące dwie usługi za pomocą modelu Procesu wyłącznego:

• Service fabric:/SpecialApp/ServiceA typu "MyServiceTypeA", z dwiema partycjami (na przykład P1 i P2) i trzema replikami na partycję.
• Service fabric:/SpecialApp/ServiceB typu "MyServiceTypeB", z dwiema partycjami (P3 i P4) i trzema replikami na partycję.

W danym węźle obie usługi mają dwie repliki. Ponieważ do utworzenia usług użyliśmy modelu Procesu wyłącznego, usługa Service Fabric aktywuje nową kopię elementu "MyServicePackage" dla każdej repliki. Każda aktywacja elementu "MultiTypeServicePackage" rozpoczyna kopię "MyCodePackageA" i "MyCodePackageB". Jednak tylko jeden element "MyCodePackageA" lub "MyCodePackageB" hostuje replikę, dla której aktywowano element "MultiTypeServicePackage". Na poniższym diagramie przedstawiono widok węzła:

W aktywacji "MultiTypeServicePackage" dla repliki partycji P1 usługi service fabric:/SpecialApp/ServiceA, "MyCodePackageA" hostuje replikę. Polecenie "MyCodePackageB" jest uruchomione. Podobnie w przypadku aktywacji elementu "MultiTypeServicePackage" dla repliki partycji P3 usługi service fabric:/SpecialApp/ServiceB hostuje replikę. Polecenie "MyCodePackageA" jest uruchomione. W związku z tym im większa liczba elementów CodePackage (rejestrujących różne typy usług) na pakiet ServicePackage, tym większe jest nadmiarowe użycie zasobów.

Jeśli jednak utworzymy sieć szkieletową usług:/SpecialApp/ServiceA i fabric:/SpecialApp/ServiceB z modelem procesu współużytkowanego, usługa Service Fabric aktywuje tylko jedną kopię elementu "MultiTypeServicePackage" dla aplikacji fabric:/SpecialApp. Element "MyCodePackageA" hostuje wszystkie repliki dla usługi Service Fabric:/SpecialApp/ServiceA. Element "MyCodePackageB" hostuje wszystkie repliki dla usługi Service Fabric:/SpecialApp/ServiceB. Na poniższym diagramie przedstawiono widok węzła w tym ustawieniu:

W poprzednim przykładzie można pomyśleć, że jeśli element "MyCodePackageA" zarejestruje zarówno element "MyServiceTypeA", jak i "MyServiceTypeB", a nie ma elementu "MyCodePackageB", wówczas nie jest uruchomiony nadmiarowy pakiet CodePackage . Mimo że jest to poprawne, ten model aplikacji nie jest zgodny z modelem hostingu procesów wyłącznych. Jeśli celem jest umieszczenie każdej repliki we własnym dedykowanym procesie, nie trzeba rejestrować obu typów usługi z tego samego pakietu CodePackage. Zamiast tego należy po prostu umieścić każdy parametr ServiceType we własnym elemecie ServicePackage.

Usługi Reliable Services i aktor rozwidliły podprocesy

Usługa Service Fabric nie obsługuje niezawodnych usług, a następnie niezawodnych aktorów do tworzenia podprocesów. Przykładem tego, dlaczego nie jest obsługiwany kodPackageActivationContext , nie można użyć do zarejestrowania nieobsługiwanego podprocesu, a tokeny anulowania są wysyłane tylko do zarejestrowanych procesów; Powoduje to wszelkiego rodzaju problemy, takie jak błędy uaktualniania, gdy podprocesy nie zamykają się po otrzymaniu tokenu anulowania przez proces nadrzędny.

Następne kroki

Spakuj aplikację i przygotuj ją do wdrożenia.

Wdrażanie i usuwanie aplikacji. W tym artykule opisano sposób używania programu PowerShell do zarządzania wystąpieniami aplikacji.