Cykl życia usług Reliable Services

  • Artykuł

Reliable Services to jeden z modeli programowania dostępnych w usłudze Azure Service Fabric. Podczas poznawania cyklu życia usług Reliable Services najważniejsze jest zrozumienie podstawowych zdarzeń cyklu życia. Dokładne porządkowanie zdarzeń zależy od szczegółów konfiguracji.

Ogólnie rzecz biorąc, cykl życia usług Reliable Services obejmuje następujące zdarzenia:

  • Podczas uruchamiania:
    • Usługi są konstruowane.
    • Usługi mogą tworzyć i zwracać zero lub więcej odbiorników.
    • Wszystkie zwrócone odbiorniki są otwierane na potrzeby komunikacji z usługą.
    • Metoda usługi jest wywoływana runAsync , więc usługa może wykonywać długotrwałą lub działającą w tle pracę.
  • Podczas zamykania:
    • Token anulowania przekazany do runAsync jest anulowany, a odbiorniki są zamykane.
    • Sam obiekt usługi jest zdestrukowany.

Kolejność zdarzeń w usługach Reliable Services może ulec nieznacznej zmianie w zależności od tego, czy niezawodna usługa jest bezstanowa, czy stanowa.

Ponadto w przypadku usług stanowych należy rozwiązać podstawowy scenariusz wymiany. Podczas tej sekwencji rola podstawowa jest przenoszona do innej repliki (lub wraca) bez zamykania usługi.

Na koniec należy zastanowić się nad warunkami błędu lub awarii.

Uruchamianie usługi bezstanowej

Cykl życia usługi bezstanowej jest dość prosty. Oto kolejność zdarzeń:

  1. Usługa jest tworzona.
  2. StatelessService.createServiceInstanceListeners() jest wywoływana, a wszystkie zwrócone odbiorniki są otwierane. CommunicationListener.openAsync() element jest wywoływany na każdym odbiorniku.
  3. Następnie równolegle:
    • Metoda usługi (StatelessService.runAsync()) jest wywoływanarunAsync.
    • Jeśli jest obecna, wywoływana jest własna onOpenAsync metoda usługi. W szczególności StatelessService.onOpenAsync() jest wywoływana. Jest to nietypowe zastąpienie, ale jest dostępne.

Zamykanie usługi bezstanowej

Po zamknięciu usługi bezstanowej następuje ten sam wzorzec, ale odwrotnie:

  1. Wszystkie otwarte odbiorniki są zamknięte. CommunicationListener.closeAsync() element jest wywoływany na każdym odbiorniku.
  2. Token anulowania, do którego przekazano, zostanie anulowany runAsync() . Sprawdzenie właściwości tokenu isCancelled anulowania zwraca truewartość , a jeśli zostanie wywołana, metoda tokenu throwIfCancellationRequested zgłasza błąd CancellationException.
  3. Po runAsync() zakończeniu wywoływana StatelessService.onCloseAsync() jest metoda usługi, jeśli jest obecna. Ponownie nie jest to powszechne zastąpienie, ale może służyć do bezpiecznego zamykania zasobów, zatrzymywania przetwarzania w tle, kończenie zapisywania stanu zewnętrznego lub zamykania istniejących połączeń.
  4. Po StatelessService.onCloseAsync() zakończeniu obiekt usługi zostanie zdestrukturowany.

Uruchamianie usługi stanowej

Usługi stanowe mają wzorzec podobny do usług bezstanowych z kilkoma zmianami. Oto kolejność zdarzeń uruchamiania usługi stanowej:

  1. Usługa jest tworzona.
  2. Wywołano metodę StatefulServiceBase.onOpenAsync(). To wywołanie nie jest często zastępowane w usłudze.
  3. StatefulServiceBase.createServiceReplicaListeners() jest wywoływana.
    • Jeśli usługa jest usługą podstawową, wszystkie zwrócone odbiorniki są otwierane. CommunicationListener.openAsync() element jest wywoływany na każdym odbiorniku.
    • Jeśli usługa jest usługą pomocniczą, otwierane są tylko odbiorniki oznaczone jako listenOnSecondary = true . Rzadziej spotykane są odbiorniki, które są otwarte w plikach pomocniczych.
  4. Następnie równolegle:
    • Jeśli usługa jest obecnie podstawowa, wywoływana StatefulServiceBase.runAsync() jest metoda usługi.
    • Wywołano metodę StatefulServiceBase.onChangeRoleAsync(). To wywołanie nie jest często zastępowane w usłudze.

Uwaga

W przypadku nowej repliki StatefulServiceBase.onChangeRoleAsync() pomocniczej wywoływana jest dwukrotnie. Raz po kroku 2, gdy stanie się on bezczynnym pomocniczym i ponownie w kroku 4, gdy staje się aktywnym pomocniczym. Aby uzyskać więcej informacji na temat cyklu życia repliki i wystąpienia, przeczytaj artykuł Replica and Instance Lifecycle (Cykl życia repliki i wystąpienia).

Zamykanie usługi stanowej

Podobnie jak w przypadku usług bezstanowych zdarzenia cyklu życia podczas zamykania są takie same jak podczas uruchamiania, ale są odwrócone. Po zamknięciu usługi stanowej występują następujące zdarzenia:

  1. Wszystkie otwarte odbiorniki są zamknięte. CommunicationListener.closeAsync() element jest wywoływany na każdym odbiorniku.
  2. Token anulowania, do którego przekazano, zostanie anulowany runAsync() . Wywołanie metody tokenu isCancelled() anulowania zwraca truemetodę , a jeśli zostanie wywołana, metoda tokenu throwIfCancellationRequested() zgłasza błąd OperationCanceledException. Usługa Service Fabric czeka na runAsync() ukończenie.

Uwaga

Oczekiwanie na runAsync zakończenie jest konieczne tylko wtedy, gdy ta replika jest repliką podstawową.

  1. Po runAsync() zakończeniu wywoływana StatefulServiceBase.onCloseAsync() jest metoda usługi. To wywołanie jest nietypowe, ale jest dostępne.
  2. Po StatefulServiceBase.onCloseAsync() zakończeniu obiekt usługi zostanie zdestrukturowany.

Zamiany podstawowe usługi stanowej

Gdy usługa stanowa jest uruchomiona, odbiorniki komunikacji są otwierane, a runAsync metoda jest wywoływana tylko dla replik podstawowych tych usług stanowych. Repliki pomocnicze są konstruowane, ale nie widzą żadnych dalszych wywołań. Gdy usługa stanowa jest uruchomiona, replika, która jest obecnie podstawowa, może ulec zmianie. Zdarzenia cyklu życia widoczne przez replikę stanową zależą od tego, czy replika jest zdegradowana, czy promowana podczas zamiany.

W przypadku zdegradowany podstawowy

Usługa Service Fabric wymaga podstawowej repliki, która została zdegradowana, aby zatrzymać przetwarzanie komunikatów i zatrzymać pracę w tle. Ten krok jest podobny do tego, gdy usługa zostanie zamknięta. Jedną z różnic jest to, że usługa nie jest zdestrukowana ani zamknięta, ponieważ pozostaje jako pomocnicza. Wystąpią następujące zdarzenia:

  1. Wszystkie otwarte odbiorniki są zamknięte. CommunicationListener.closeAsync() element jest wywoływany na każdym odbiorniku.
  2. Token anulowania, do którego przekazano, zostanie anulowany runAsync() . Sprawdzanie metody tokenu isCancelled() anulowania zwraca wartość true. W przypadku wywołania metoda tokenu throwIfCancellationRequested() zgłasza błąd OperationCanceledException. Usługa Service Fabric czeka na runAsync() ukończenie.
  3. Odbiorniki oznaczone jako listenOnSecondary = true są otwierane.
  4. Usługa jest wywoływana StatefulServiceBase.onChangeRoleAsync() . To wywołanie nie jest często zastępowane w usłudze.

Dla promowanego pomocniczego

Podobnie usługa Service Fabric potrzebuje repliki pomocniczej, która jest promowana, aby rozpocząć nasłuchiwanie komunikatów w sieci i uruchomić wszystkie zadania w tle, które należy wykonać. Ten proces jest podobny do procesu tworzenia usługi. Różnica polega na tym, że sama replika już istnieje. Wystąpią następujące zdarzenia:

  1. CommunicationListener.closeAsync() metoda jest wywoływana dla wszystkich otwartych odbiorników (oznaczonych atrybutem listenOnSecondary = true)
  2. Wszystkie odbiorniki komunikacji są otwarte. CommunicationListener.openAsync() element jest wywoływany na każdym odbiorniku.
  3. Następnie równolegle:
    • Wywoływana StatefulServiceBase.runAsync() jest metoda usługi.
    • Wywołano metodę StatefulServiceBase.onChangeRoleAsync(). To wywołanie nie jest często zastępowane w usłudze.

Uwaga

createServiceReplicaListeners jest wywoływany tylko raz i nie jest wywoływany ponownie podczas podwyższania poziomu repliki lub procesu degradacji; te same ServiceReplicaListener wystąpienia są używane, ale nowe CommunicationListener wystąpienia są tworzone (przez wywołanie ServiceReplicaListener.createCommunicationListener metody) po zamknięciu poprzednich wystąpień.

Typowe problemy podczas zamykania usługi stanowej i degradacji podstawowej

Usługa Service Fabric zmienia podstawową usługę stanową z wielu powodów. Najczęstsze przyczyny to ponowne równoważenie klastra i uaktualnianie aplikacji. Podczas tych operacji ważne jest, aby usługa uwzględniała cancellationTokenelement . Dotyczy to również normalnego zamknięcia usługi, na przykład jeśli usługa została usunięta.

Usługi, które nie obsługują anulowania w sposób czysty, mogą napotykać kilka problemów. Te operacje są powolne, ponieważ usługa Service Fabric czeka na zatrzymanie usług w sposób bezproblemowy. Może to ostatecznie prowadzić do niepowodzenia uaktualnień, które upłynął limit czasu i wycofania. Niepowodzenie honorowania tokenu anulowania może również spowodować nierównowagę klastrów. Klastry stają się niezrównoważone, ponieważ węzły stają się gorące. Nie można jednak ponownie zrównoważyć usług, ponieważ przenoszenie ich w innym miejscu trwa zbyt długo.

Ponieważ usługi są stanowe, prawdopodobnie usługi korzystają z usług Reliable Collections. W usłudze Service Fabric, gdy podstawowy zostanie zdegradowany, jedną z pierwszych rzeczy, które się dzieje, jest to, że dostęp do zapisu w stanie bazowym jest odwołany. Prowadzi to do drugiego zestawu problemów, które mogą mieć wpływ na cykl życia usługi. Kolekcje zwracają wyjątki na podstawie chronometrażu i tego, czy replika jest przenoszona, czy zamykana. Ważne jest, aby prawidłowo obsługiwać te wyjątki.

Wyjątki zgłaszane przez usługę Service Fabric są trwałe (FabricException) lub przejściowe (FabricTransientException). Należy rejestrować i zgłaszać trwałe wyjątki. Wyjątki przejściowe można ponowić na podstawie logiki ponawiania prób.

Ważną częścią testowania i weryfikowania usług Reliable Services jest obsługa wyjątków, które pochodzą z użycia ReliableCollections w połączeniu z zdarzeniami cyklu życia usługi. Zalecamy, aby zawsze uruchamiać usługę pod obciążeniem. Przed wdrożeniem w środowisku produkcyjnym należy również przeprowadzić uaktualnienia i testowanie chaosu . Te podstawowe kroki pomagają upewnić się, że usługa jest prawidłowo zaimplementowana i czy obsługuje zdarzenia cyklu życia prawidłowo.

Uwagi dotyczące cyklu życia usługi

  • Zarówno metoda, jak runAsync() i createServiceInstanceListeners/createServiceReplicaListeners wywołania są opcjonalne. Usługa może mieć jedną, obie lub żadną z nich. Jeśli na przykład usługa wykonuje całą swoją pracę w odpowiedzi na wywołania użytkownika, nie ma potrzeby jej implementowania runAsync(). Niezbędne są tylko odbiorniki komunikacji i skojarzony z nimi kod. Podobnie tworzenie i zwracanie odbiorników komunikacji jest opcjonalne. Usługa może mieć tylko pracę w tle, więc musi tylko zaimplementować runAsync()usługę .
  • Jest to prawidłowe, aby usługa została ukończona runAsync() pomyślnie i została zwrócona z niej. Nie jest to uważane za warunek niepowodzenia. Reprezentuje on pracę w tle zakończenia usługi. W przypadku stanowych usług Reliable Services zostanie ponownie wywołana, runAsync() jeśli usługa zostanie zdegradowana z poziomu podstawowego, a następnie podniesiona z powrotem do warstwy podstawowej.
  • Jeśli usługa zostanie zakończona runAsync() , zgłaszając nieoczekiwany wyjątek, jest to błąd. Obiekt usługi jest zamykany i zgłaszany jest błąd kondycji.
  • Chociaż nie ma limitu czasu na powrót z tych metod, natychmiast utracisz możliwość zapisu. W związku z tym nie można ukończyć żadnej prawdziwej pracy. Zalecamy, aby powrócić tak szybko, jak to możliwe po otrzymaniu żądania anulowania. Jeśli Twoja usługa nie odpowiada na te wywołania interfejsu API w rozsądnym czasie, usługa Service Fabric może wymuszać wymuszone zakończenie usługi. Zwykle dzieje się tak tylko podczas uaktualniania aplikacji lub usuwania usługi. Ten limit czasu to domyślnie 15 minut.
  • Błędy w onCloseAsync() ścieżce powodują onAbort() wywoływanie. To wywołanie jest ostatnią szansą, najlepszą szansą dla usługi w celu oczyszczenia i zwolnienia wszelkich zasobów, które zostały zgłoszone. Jest to zwykle wywoływane w przypadku wykrycia stałego błędu w węźle lub gdy usługa Service Fabric nie może niezawodnie zarządzać cyklem życia wystąpienia usługi z powodu awarii wewnętrznych.
  • OnChangeRoleAsync() jest wywoływana, gdy replika usługi stanowej zmienia rolę, na przykład na podstawową lub pomocniczą. Repliki podstawowe mają stan zapisu (mogą tworzyć i zapisywać w kolekcjach Reliable Collections). Repliki pomocnicze mają stan odczytu (mogą być odczytywane tylko z istniejących kolekcji reliable). Większość pracy w usłudze stanowej jest wykonywana w repliki podstawowej. Repliki pomocnicze mogą wykonywać walidację tylko do odczytu, generowanie raportów, eksplorację danych lub inne zadania tylko do odczytu.

Następne kroki