Cykl życia usług Reliable Services

• C# w systemie Windows
• Java w systemie Linux

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 runAsync jest wywoływana, więc usługa może wykonywać długotrwałą pracę lub w tle.
• Podczas zamykania:
  • Token anulowania przekazany do runAsync jest anulowany, a odbiorniki są zamykane.
  • Sam obiekt usługi jest zdestrukturowany.

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 zamiany. Podczas tej sekwencji rola podstawowa jest przenoszona do innej repliki (lub powraca) bez zamykania usługi.

Na koniec musisz myśleć o błędach lub warunkach awarii.

Uruchamianie usługi bezstanowej

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

1. Usługa jest konstruowana.
2. StatelessService.createServiceInstanceListeners() jest wywoływana, a wszystkie zwrócone odbiorniki są otwierane. CommunicationListener.openAsync() program jest wywoływany na każdym odbiorniku.
3. Następnie równolegle:
   • Wywoływana runAsync jest metoda usługi (StatelessService.runAsync()).
   • Jeśli istnieje, 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ą zamykane. CommunicationListener.closeAsync() program jest wywoływany na każdym odbiorniku.
2. Token anulowania, do którego przekazano, jest anulowany runAsync() . Sprawdzanie właściwości tokenu isCancelled anulowania zwraca truewartość , a jeśli zostanie wywołana, metoda tokenu throwIfCancellationRequested zgłasza CancellationExceptionbłąd .
3. Po runAsync() zakończeniu wywoływana StatelessService.onCloseAsync() jest metoda usługi, jeśli jest obecna. Ponownie nie jest to typowe przesłonięcia, ale może służyć do bezpiecznego zamykania zasobów, zatrzymywania przetwarzania w tle, kończenie zapisywania stanu zewnętrznego lub zamykanie 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 konstruowana.
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() program jest wywoływany na każdym odbiorniku.
   • Jeśli usługa jest usługą pomocniczą, otwarte są tylko odbiorniki oznaczone jako listenOnSecondary = true . Używanie odbiorników otwartych w sekundach jest mniej powszechne.
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 jest wywoływana 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 odwrócone. Po zamknięciu usługi stanowej występują następujące zdarzenia:

1. Wszystkie otwarte odbiorniki są zamykane. CommunicationListener.closeAsync() program jest wywoływany na każdym odbiorniku.
2. Token anulowania, do którego przekazano, jest 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ą.

3. Po runAsync() zakończeniu wywoływana StatefulServiceBase.onCloseAsync() jest metoda usługi. To wywołanie jest nietypowym przesłonięciem, ale jest dostępne.
4. 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, które może zobaczyć replika stanowa, zależą od tego, czy jest ona zdegradowana, czy promowana podczas zamiany.

Dla zdegradowanej podstawowej

Usługa Service Fabric wymaga repliki podstawowej, 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ępują wówczas następujące zdarzenia:

1. Wszystkie otwarte odbiorniki są zamykane. CommunicationListener.closeAsync() program jest wywoływany na każdym odbiorniku.
2. Token anulowania, do którego przekazano, jest anulowany runAsync() . Sprawdzanie metody tokenu isCancelled() anulowania zwraca truewartość . Jeśli zostanie wywołana, 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 promowanej pomocniczej

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ępują wówczas następujące zdarzenia:

1. CommunicationListener.closeAsync() jest wywoływana dla wszystkich otwartych odbiorników (oznaczonych jako listenOnSecondary = true)
2. Wszystkie odbiorniki komunikacji są otwarte. CommunicationListener.openAsync() program 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 obniżania poziomu; 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 stanowego zamykania usługi i podstawowego obniżania poziomu

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 szanowała usługę cancellationToken. 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, mogą wystąpić kilka problemów. Te operacje są powolne, ponieważ usługa Service Fabric czeka na bezproblemowe zatrzymywanie usług. Może to ostatecznie prowadzić do niepowodzenia uaktualnień, które przekroczyły limit czasu i wycofały się. 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ż przeniesienie ich do innego miejsca zajmuje zbyt dużo czasu.

Ponieważ usługi są stanowe, prawdopodobnie usługi korzystają z kolekcji Reliable Collections. W usłudze Service Fabric, gdy podstawowa jest zdegradowana, jedną z pierwszych rzeczy, które się dzieje, jest to, że dostęp do zapisu do stanu bazowego 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). Wyjątki trwałe powinny być rejestrowane i zgłaszane. Wyjątki przejściowe można ponawiać na podstawie logiki ponawiania prób.

Ważną częścią testowania i walidacji usług Reliable Services jest obsługa wyjątków, które pochodzą z użycia ReliableCollections w połączeniu ze 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 została prawidłowo zaimplementowana i czy prawidłowo obsługuje zdarzenia cyklu życia.

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 nie. 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ć usługę runAsync().
• Usługa jest prawidłowa do pomyślnego ukończenia runAsync() i powrotu z niej. Nie jest to uznawane za warunek niepowodzenia. Reprezentuje on pracę w tle ukończenia usługi. W przypadku stanowych usług Reliable Services zostanie ponownie wywołana, runAsync() jeśli usługa zostanie zdegradowana z warstwy podstawowej, a następnie zostanie podniesiona z powrotem do warstwy podstawowej.
• Jeśli usługa zakończy działanie, 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 rzeczywistej pracy. Zalecamy jak najszybsze zwrócenie żądania anulowania. Jeśli usługa nie odpowiada na te wywołania interfejsu API w rozsądnym czasie, usługa Service Fabric może przymusowo przerwać działanie usługi. Zwykle dzieje się tak tylko podczas uaktualniania aplikacji lub gdy usługa jest usuwana. Ten limit czasu wynosi domyślnie 15 minut.
• Błędy w ścieżce onCloseAsync() 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 trwał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ływany, gdy replika usługi stanowej zmienia rolę, na przykład na podstawową lub pomocniczą. Repliki podstawowe mają stan zapisu (mogą tworzyć i zapisywać w elementach Reliable Collections). Repliki pomocnicze mają stan odczytu (mogą odczytywać tylko z istniejących kolekcji Reliable Collections). Większość pracy w usłudze stanowej jest wykonywana w repliki podstawowej. Repliki pomocnicze mogą wykonywać walidację tylko do odczytu, generowanie raportów, wyszukiwania danych lub inne zadania tylko do odczytu.

Następne kroki

• Wprowadzenie do usług Reliable Services
• Przewodnik Szybki start dotyczący usług Reliable Services