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 procesów udostępnionych i wyłącznych procesów . Opisuje ona 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 artykule 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 odnosi 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 typ usługi 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 wartość ServiceType "MyServiceType ". Element "MyServiceType" jest dostarczany przez pakiet ServicePackage "MyServicePackage", który ma pakiet CodePackage "MyCodePackage". Polecenie "MyCodePackage" rejestruje parametr ServiceType "MyServiceType" podczas jego uruchamiania.

Załóżmy, że mamy klaster z trzema węzłami i utworzymy sieć szkieletową aplikacji:/App1 typu "MyAppType". Wewnątrz tej aplikacji fabric:/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 uaktywnił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 kolejną usługę fabric :/App1/ServiceB w aplikacji fabric:/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". Teraz. Utwórzmy kolejną aplikację fabric:/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) i 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 aktywowana jest tylko jedna kopia danego pakietu ServicePackage w węźle (uruchamiający wszystkie zawarte w nim pakiety CodePackage). Wszystkie repliki wszystkich usług danego typu usługi są umieszczane w kodziePackage , który rejestruje ten typ usługi. Innymi słowy, wszystkie repliki wszystkich usług w węźle danego typu usługi współużytkuje ten sam proces.

Wyłączny model procesu

Innym modelem hostingu udostępnianym przez usługę Service Fabric jest model procesu wyłącznego. 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ł 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 procesu wyłącznego , 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ę, sieć szkieletową:/App1/ServiceC w usłudze application fabric:/App1. Ta usługa ma dwie partycje (na przykład P6 i P7) i trzy repliki na partycję. Dla opcji ServicePackageActivationMode należy ustawić wartość "ExclusiveProcess". Na poniższym diagramie przedstawiono nowy widok w węźle:

Jak widać, usługa Service Fabric aktywowała dwie nowe kopie elementu "MyServicePackage" (po jednym 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. Parametr ServicePackageActivationId dla tej aktywacji pakietu ServicePackage jest pustym ciągiem. Jest to na przykład przypadek z siecią szkieletową:/App2.

Uwaga

• Model hostingu procesów udostępnionych odpowiada właściwości ServicePackageActivationMode równe SharedProcess. Jest to domyślny model hostingu, a parametr ServicePackageActivationMode nie musi być określony w momencie tworzenia usługi.

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

• Aby wyświetlić model hostingu usługi, wykonaj zapytanie dotyczące opisu usługi i przyjrzyj się wartości 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 procesu wyłącznego 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. Na przykład podaj identyfikator w przypadku raportowania kondycji wdrożonego pakietu usługi lub ponownego uruchomienia pakietu kodu wdrożonego pakietu usługi.

Identyfikator ServicePackageActivationId wdrożonego pakietu usługi można znaleźć, wykonując zapytanie dotyczące 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 procesu współużytkowanego w danym węźle dla danej aplikacji aktywowano tylko jedną kopię pakietu ServicePackage . Ma on wartość ServicePackageActivationId równą pusty ciąg i nie musi być określony podczas wykonywania operacji związanych z wdrożonym pakietem usługi.

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

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

• Nie wykonuj 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 (proces lub kontener) nie ma środowiska uruchomieniowego usługi Service Fabric. Ponieważ te usługi są samodzielne, liczba replik na serviceHost nie ma zastosowania dla tych usług. Najczęstszą 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).

Wartość domyślna ServicePackageActivationMode dla tych usług to SharedProcess, w tym przypadku usługa Service Fabric aktywuje tylko jedną kopię elementu 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 parametr ServicePackageActivationMode jako ExclusiveProcess podczas tworzenia usługi. Można to zrobić na przykład podczas tworzenia wielu usług (Service1 to ServiceN) typu ServiceType (określonego w pliku ServiceManifest) 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).

Wybieranie między modelami hostingu

Należy ocenić, który model hostingu najlepiej spełnia Twoje wymagania. Model współużytkowanego procesu używa zasobów systemu operacyjnego lepiej, ponieważ zduplikowanych jest mniej procesów, a wiele replik w tym samym procesie może współużytkować porty. Jeśli jednak jeden 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 jeden 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 typ usługi na pakiet ServicePackage.

W niektórych przypadkach usługa Service Fabric zezwala również na więcej niż jeden typ usługi 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 wyłącznych procesów nie jest spójny z modelem aplikacji o wielu typach ServiceTypes na pakiet ServicePackage. Jest to spowodowane tym, że wiele typów usługi na pakiet ServicePackage zaprojektowano w celu osiągnięcia wyższego udostępniania zasobów między replikami i umożliwia większą gęstość replik na proces. Model procesu wyłącznego został zaprojektowany w celu osiągnięcia różnych wyników.

Rozważmy przypadek wielu typów usługi 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ż użyliśmy modelu procesu wyłącznego do utworzenia usług, usługa Service Fabric aktywuje nową kopię elementu "MyServicePackage" dla każdej repliki. Każda aktywacja elementu "MultiTypeServicePackage" rozpoczyna kopię elementu "MyCodePackageA" i "MyCodePackageB". Jednak tylko jeden z "MyCodePackageA" lub "MyCodePackageB" hostuje replikę, dla której aktywowano element "MultiTypeServicePackage". Na poniższym diagramie przedstawiono widok węzła:

W aktywacji elementu "MultiTypeServicePackage" dla repliki partycji P1 usługi Service Fabric:/SpecialApp/ServiceA element "MyCodePackageA" hostuje replikę. Polecenie "MyCodePackageB" jest uruchomione. Podobnie w przypadku aktywacji elementu "MultiTypeServicePackage" dla repliki partycji P3 usługi Service Fabric:/SpecialApp/ServiceB element "MyCodePackageB" 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 współużytkowanego procesu, 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 "MyServiceTypeA", jak i "MyServiceTypeB", a następnie nie ma nadmiarowego pakietu CodePackageB . 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 wystarczy umieścić każdy parametr ServiceType we własnym elemecie ServicePackage.

Reliable Services and Actor forking subprocesses (Usługi Reliable Services i aktor) — podprocesy podrzędne

Usługa Service Fabric nie obsługuje niezawodnych usług, a następnie niezawodnych aktorów tworzenia podprocesów. Przykładem, 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, co powoduje 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.