Wzorzec wyłącznika

Umożliwia obsługę błędów, których naprawienie może potrwać zmienną ilość czasu podczas nawiązywania połączenia ze zdalną usługą lub zasobem. Ten wzorzec może poprawić stabilność i odporność aplikacji.

Kontekst i problem

W środowisku rozproszonym wywołania zasobów zdalnych i usług mogą zakończyć się niepowodzeniem z powodu przejściowych błędów, takich jak wolne połączenia sieciowe, przekroczenia limitu czasu lub nadmiernie zatwierdzane lub tymczasowo niedostępne. Takie błędy zwykle w krótkim czasie korygują się same, ale niezawodna aplikacja w chmurze powinna być przygotowana do obsługi tych błędów przez wprowadzenie odpowiedniej strategii, na przykład tej opisanej w temacie Retry pattern (Wzorzec ponawiania).

Może jednak zdarzyć się, że błędy spowodowane są nieprzewidzianymi zdarzeniami, a ich naprawa może potrwać dłużej. Takie błędy mogą mieć różny stopień ważności — od częściowej utraty łączności do całkowitej awarii usługi. W takich sytuacjach może być bezcelowe, aby aplikacja stale ponawiała próbę wykonania operacji, która jest mało prawdopodobna, a zamiast tego aplikacja powinna szybko zaakceptować, że operacja zakończyła się niepowodzeniem i odpowiednio obsłuży tę awarię.

Co więcej jeśli usługa jest bardzo obciążona, awaria jednej części systemu może doprowadzić do kolejnych awarii. Na przykład można skonfigurować operację, która wywołuje usługę w celu zaimplementowania limitu czasu, i odpowiedzieć z komunikatem o błędzie, jeśli usługa nie odpowie w tym okresie. Jednak ta strategia może spowodować zablokowanie wielu współbieżnych żądań do tej samej operacji do momentu wygaśnięcia limitu czasu. Te zablokowane żądania mogą blokować krytyczne zasoby systemu, na przykład pamięć, wątki czy połączenia bazy danych. W związku z tym te zasoby mogą zostać wyczerpane, powodując awarię innych, prawdopodobnie niepowiązanych części systemu, które muszą korzystać z tych samych zasobów. W takich sytuacjach lepszym rozwiązaniem jest natychmiastowe zakończenie operacji niepowodzeniem i próba wywołania usługi tylko wówczas, gdy to działanie ma szansę na powodzenie. Ustawienie krótszego limitu czasu może pomóc rozwiązać ten problem, ale przekroczenie limitu czasu nie powinno być tak krótkie, że operacja kończy się niepowodzeniem przez większość czasu, nawet jeśli żądanie do usługi zakończy się pomyślnie.

Rozwiązanie

Wzorzec wyłącznika może uniemożliwić aplikacji wielokrotne wykonywanie operacji, która prawdopodobnie zakończy się niepowodzeniem. Umożliwia aplikacji dalsze działanie bez oczekiwania na naprawienie błędu i marnowania cykli procesora CPU, do czasu określenia, czy błąd jest długotrwały. Wzorzec wyłącznika umożliwia również aplikacji wykrycie, czy błąd został naprawiony. Jeśli wydaje się, że problem został naprawiony, aplikacja może spróbować ponownie wywołać operację.

Wzorzec wyłącznika służy do innych celów niż wzorzec ponawiania. Wzorzec ponawiania umożliwia aplikacji ponowienie próby wykonania operacji przy założeniu, że operacja się powiedzie. Wzorzec wyłącznika zapobiega wykonywaniu przez aplikację operacji, która prawdopodobnie się nie powiedzie. Aplikacja może korzystać z obu wzorców, używając wzorca ponawiania do wywołania operacji za pośrednictwem wyłącznika. Jednak logika ponawiania powinna uwzględniać ewentualne wyjątki zwracane przez wyłącznik i przerwać ponawianie prób, jeśli wyłącznik wskazuje, że błąd nie jest przejściowy.

Wyłącznik działa jako serwer proxy dla operacji, które mogą zakończyć się niepowodzeniem. Serwer proxy powinien monitorować liczbę ostatnich awarii i użyć tych informacji, aby zdecydować, czy zezwolić na kontynuowanie operacji, czy natychmiast zwrócić wyjątek.

Ten serwer proxy może być automatem stanów z następującymi stanami, które naśladują funkcje wyłącznika elektrycznego:

• Zwarty: żądanie aplikacji jest kierowane do operacji. Serwer proxy przechowuje liczbę ostatnich awarii i zwiększa ją, jeśli wywołanie do operacji nie powiedzie się. Jeśli liczba ostatnich awarii przekroczy określony próg we wskazanym czasie, serwer proxy przechodzi w stan rozwarty. W tym momencie serwer proxy uruchamia czasomierz przekroczenia limitu czasu, a po wygaśnięciu tego czasomierza serwer proxy zostanie umieszczony w stanie Half-Open.

  Celem czasomierza limitu czasu jest nadanie systemowi czasu, aby rozwiązać problem, który spowodował awarię przed zezwoleniem aplikacji na ponowne wykonanie operacji.

• Rozwarty: żądanie aplikacji natychmiast kończy się niepowodzeniem, a do aplikacji zwracany jest wyjątek.

• Połowicznie rozwarty: umożliwia przesłanie dalej ograniczonej liczby żądań aplikacji w celu wywołania operacji. Jeśli te żądania powiodą się, zakłada się, że błąd, który poprzednio powodował awarię, został naprawiony, a wyłącznik zostaje przełączony do stanu zwartego (licznik awarii zostaje zresetowany). Jeśli jakiekolwiek żądanie zakończy się niepowodzeniem, wyłącznik zakłada, że błąd jest nadal obecny, aby przywrócić stan Otwórz i ponownie uruchomi czasomierz limitu czasu, aby dać systemowi kolejny okres czasu na odzyskanie sprawności po awarii.

  Stan połowicznie rozwarty zapobiega nagłemu napływowi żądań do odzyskiwanej usługi. W miarę odzyskiwania usługi może ona być w stanie obsłużyć ograniczoną liczbę żądań do czasu zakończenia odzyskiwania, ale gdy odzyskiwanie jest w toku, powódź pracy może spowodować przekroczenie limitu czasu usługi lub ponowne niepowodzenie.

Rysunek przedstawia zależny od czasu licznik niepowodzeń używany, gdy wyłącznik znajduje się w stanie zwartym. Jest on automatycznie resetowany w regularnych odstępach czasu. Ten projekt pomaga zapobiec wejściu wyłącznika w stan Otwórz, jeśli wystąpią sporadyczne awarie. Próg błędów powodujący przełączenie wyłącznika w stan rozwarty jest osiągany dopiero po wystąpieniu określonej liczby awarii w określonym przedziale czasu. W stanie połowicznie rozwartym licznik rejestruje liczbę udanych prób wywołania operacji. Wyłącznik wraca do stanu zwartego, gdy określona liczba kolejnych wywołań operacji zakończy się pomyślnie. W przypadku niepowodzenia jakiegokolwiek wywołania wyłącznik natychmiast przechodzi w stan rozwarty, a przy następnym przejściu w stan połowicznie rozwarty licznik udanych operacji jest resetowany.

Sposób odzyskiwania systemu jest obsługiwany zewnętrznie, na przykład przez przywrócenie lub ponowne uruchomienie składnika, który uległ awarii, lub naprawę połączenia sieciowego.

Wzorzec wyłącznika zapewnia stabilność podczas odzyskiwania systemu po awarii i minimalizuje negatywny wpływ na wydajność. Umożliwia utrzymanie czasu odpowiedzi systemu dzięki szybkiemu odrzuceniu żądania operacji, która prawdopodobnie zakończy się niepowodzeniem, zamiast czekać, aż operacja przekroczy limit czasu, lub pozostawić ją bez odpowiedzi. Jeśli wyłącznik wywołuje zdarzenie przy każdej zmianie stanu, można użyć tej informacji do monitorowania kondycji tej części systemu, którą chroni wyłącznik, lub do powiadomienia administratora, gdy wyłącznik przejdzie w stan rozwarty.

Wzorzec można dostosowywać do prawdopodobnych typów błędów. Na przykład można zastosować do wyłącznika zwiększenie limitu czasu. Wyłącznik można umieścić w stanie Otwórz przez kilka sekund, a następnie, jeśli awaria nie została rozwiązana, zwiększ limit czasu do kilku minut itd. W niektórych przypadkach lepszym rozwiązaniem niż zwrócenie błędu i wywołanie wyjątku przez stan rozwarty jest zwrócenie wartości domyślnej znaczącej dla aplikacji.

Problemy i kwestie do rozważenia

Podczas podejmowania decyzji o sposobie wdrażania tego wzorca należy rozważyć następujące kwestie:

obsługa wyjątków: aplikacja wywołująca operację za pośrednictwem wyłącznika musi być przygotowana do obsługi wyjątków zgłoszonych, jeśli operacja jest niedostępna. Sposób obsługi wyjątków zależy od aplikacji. Aplikacja może na przykład tymczasowo ograniczyć funkcjonalność, wywołać inną operację w celu wykonania tego samego zadania lub uzyskania tych samych danych albo zgłosić wyjątek użytkownikowi i poprosić go o ponowienie próby później.

Typy wyjątków: Żądanie może zakończyć się niepowodzeniem z wielu powodów, z których niektóre mogą wskazywać na poważniejszy typ awarii niż inne. Na przykład żądanie może zakończyć się niepowodzeniem, ponieważ usługa zdalna uległa awarii i odzyskanie może potrwać kilka minut lub z powodu przekroczenia limitu czasu z powodu tymczasowego przeciążenia usługi. Wyłącznik może być w stanie sprawdzić typ występujących wyjątków i dostosować do nich strategię działania. Może to na przykład wymagać większej liczby wyjątków przekroczenia limitu czasu w celu uruchomienia wyłącznika do stanu Otwórz w porównaniu z liczbą awarii z powodu całkowitej niedostępności usługi.

monitorowanie: Wyłącznik powinien zapewnić wyraźną obserwację zarówno żądań zakończonych niepowodzeniem, jak i pomyślnych, umożliwiając zespołom operacyjnym ocenę kondycji systemu. Użyj śledzenia rozproszonego, aby uzyskać kompleksową widoczność między usługami.

możliwości odzyskiwania: należy skonfigurować wyłącznik tak, aby był zgodny z prawdopodobnym wzorcem odzyskiwania operacji, którą chroni. Na przykład, jeśli wyłącznik pozostaje w stanie rozwartym przez długi czas, może wywoływać wyjątki, nawet jeśli przyczyna niepowodzenia została usunięta. Podobnie zbyt szybkie przełączanie ze stanu rozwartego do stanu połowicznie rozwartego może powodować wahania i pogorszenie czasu odpowiedzi aplikacji.

Testowanie nieudanych operacji: w stanie Otwórz zamiast używać czasomierza do określenia, kiedy należy przełączyć się na stan half-Open, wyłącznik może zamiast tego okresowo wysyłać polecenia ping do zdalnej usługi lub zasobu, aby określić, czy jest ponownie dostępny. Polecenie ping może by próbą wywołania operacji wcześniej zakończonej niepowodzeniem, ale może też korzystać ze specjalnej operacji udostępnionej przez usługę zdalną w celu sprawdzenia jej kondycji, tak jak opisano w temacie Health Endpoint Monitoring pattern (Wzorzec monitorowania punktów końcowych kondycji).

Ręczne przesłonięcia: w systemie, w którym czas odzyskiwania operacji zakończonej niepowodzeniem jest bardzo zmienny, korzystne jest zapewnienie opcji ręcznego resetowania, która umożliwia administratorowi zamknięcie wyłącznika (i zresetowanie licznika awarii). Podobnie administrator może wymusić wyłącznik do stanu Otwórz (i ponownie uruchomić czasomierz limitu czasu), jeśli operacja chroniona przez wyłącznik jest tymczasowo niedostępna.

współbieżności: dostęp do tego samego wyłącznika może uzyskać duża liczba współbieżnych wystąpień aplikacji. Wdrożenie nie powinno blokować współbieżnych żądań ani dodawać nadmiernego obciążenia do każdego wywołania operacji.

różnicowanie zasobów: należy zachować ostrożność podczas korzystania z jednego wyłącznika dla jednego typu zasobu, jeśli może istnieć wielu niezależnych dostawców. Na przykład w magazynie danych zawierającym wiele fragmentów, jeden fragmentu może być w pełni dostępny, podczas gdy w innym tymczasowo występuje problem. Jeśli błędy zwracane w tych scenariuszach zostaną scalone, aplikacja może próbować uzyskać dostęp do niektórych fragmentów, nawet jeśli istnieje duże prawdopodobieństwo wystąpienia awarii, a dostęp do innych fragmentów może zostać zablokowany, nawet jeśli istnieje prawdopodobieństwo powodzenia.

przyspieszone wyłączniki: czasami odpowiedź na awarię może zawierać wystarczającą ilość informacji, aby wyłącznik natychmiast się potknął i pozostał z opóźnieniem przez minimalny czas. Na przykład błąd zwrócony przez przeciążony zasób udostępniony może wskazywać, że natychmiastowe ponawianie próby nie jest zalecane, i że aplikacja powinna spróbować ponownie za kilka minut.

wdrożenia w wielu regionach: wyłącznik można zaprojektować na potrzeby wdrożeń w jednym lub wielu regionach. Te ostatnie można zaimplementować przy użyciu globalnych modułów równoważenia obciążenia lub niestandardowych strategii przerywania obwodów obsługujących region, które zapewniają kontrolowany tryb failover, optymalizację opóźnień i zgodność z przepisami.

wyłączniki siatki usługi: wyłączniki mogą być implementowane w warstwie aplikacji lub jako funkcja krzyżowa, abstrakcyjna. Na przykład siatki usług często obsługują przerywanie obwodu jako przyczepki lub jako autonomiczną możliwość bez modyfikowania kodu aplikacji.

żądania zakończone niepowodzeniem: w stanie Otwórz, a nie po prostu niepowodzeniem, wyłącznik może również zarejestrować szczegóły każdego żądania do dziennika i zorganizować ponowne odtwarzanie tych żądań, gdy zasób zdalny lub usługa stanie się dostępny.

nieodpowiednie limity czasu w usługach zewnętrznych: Wyłącznik może nie być w stanie w pełni chronić aplikacji przed operacjami, które kończą się niepowodzeniem w usługach zewnętrznych skonfigurowanych z długim limitem czasu. Jeśli przekroczenie limitu czasu jest zbyt długie, wątek z wyłącznikiem może zostać zablokowany przez dłuższy czas, zanim wyłącznik wskazuje, że operacja nie powiodła się. W tym czasie wiele innych wystąpień aplikacji może również próbować wywołać usługę za pośrednictwem wyłącznika, blokując wiele wątków, zanim wszystkie żądania zakończą się niepowodzeniem.

dostosowanie do dywersyfikacji zasobów obliczeniowych: wyłączniki powinny uwzględniać różne środowiska obliczeniowe, od bezserwerowych po konteneryzowane obciążenia, w których czynniki takie jak zimne starty i obsługa awarii wpływu na skalowalność. Metody adaptacyjne mogą dynamicznie dostosowywać strategie na podstawie typu obliczeniowego, zapewniając odporność między architekturami heterogenicznymi.

Kiedy używać tego wzorca

Użyj tego wzorca, aby:

• Aby zapobiec awariom kaskadowym, zatrzymując nadmierne wywołania przez usługę zdalną lub żądania dostępu do udostępnionego zasobu, jeśli te operacje mogą zakończyć się niepowodzeniem.
• Aby zwiększyć odporność na wiele regionów, inteligentnie rozsyłając ruch na podstawie sygnałów awarii w czasie rzeczywistym.
• Aby chronić się przed wolnymi zależnościami, pomagając nadążyć za celami poziomu usług (SLO) i uniknąć obniżenia wydajności z powodu usług o wysokim opóźnieniu.
• Aby obsłużyć sporadyczne problemy z łącznością i zmniejszyć liczbę błędów żądań w środowiskach rozproszonych.

Ten wzorzec nie jest zalecany:

• Do obsługi dostępu do lokalnych zasobów prywatnych w aplikacji, takich jak struktura danych w pamięci. W takim środowisku użycie wyłącznika zwiększałoby obciążenie systemu.
• Jako substytut obsługi wyjątków w logice biznesowej aplikacji.
• Gdy dobrze znane algorytmy ponawiania prób są wystarczające, a zależności są przeznaczone do obsługi mechanizmów ponawiania prób. Zaimplementowanie wyłącznika w aplikacji w tym przypadku może spowodować dodanie niepotrzebnej złożoności do systemu.
• Podczas oczekiwania na zresetowanie wyłącznika może spowodować niedopuszczalne opóźnienia.
• Jeśli masz architekturę sterowaną komunikatami lub opartą na zdarzeniach, ponieważ często kierują komunikaty, które nie powiodły się do kolejki utraconych listów (DLQ) na potrzeby ręcznego lub odroczonego przetwarzania. Wbudowana izolacja błędów i mechanizmy ponawiania prób zwykle implementowane w tych projektach są często wystarczające.
• Jeśli odzyskiwanie po awarii jest zarządzane na poziomie infrastruktury lub platformy, na przykład w przypadku kontroli kondycji globalnych modułów równoważenia obciążenia lub siatki usług, wyłączniki mogą nie być konieczne.

Projekt obciążenia

Architekt powinien ocenić, w jaki sposób wzorzec wyłącznika może być używany w projekcie obciążenia, aby sprostać celom i zasadom opisanym w filarach platformy Azure Well-Architected Framework. Na przykład:

Podobnie jak w przypadku każdej decyzji projektowej, należy rozważyć wszelkie kompromisy w stosunku do celów innych filarów, które mogą zostać wprowadzone przy użyciu tego wzorca.

Przykład

W tym przykładzie przedstawiono wzorzec wyłącznika zaimplementowany w celu zapobiegania przekroczeniu limitu przydziału przy użyciu warstwy bezpłatnej azure Cosmos DB. Ta warstwa jest używana głównie w przypadku danych niekrytycznych. Przepływność jest określana przez plan pojemności, który aprowizuje wyznaczony limit przydziału jednostek zasobów na sekundę. Podczas wydarzeń sezonowych zapotrzebowanie może przekroczyć podaną pojemność, co powoduje 429 odpowiedzi (zbyt wiele żądań).

Gdy wystąpi wzrost zapotrzebowania, alerty usługi Azure Monitor z progami dynamicznymi wykrywa i aktywnie powiadamia zespoły ds. operacji i zarządzania wskazujące, że może być wymagane skalowanie w górę pojemności bazy danych. Jednocześnie wyłącznik — dostrojony przy użyciu historycznych wzorców błędów — umożliwia zapobieganie awariom kaskadowym. W tym stanie aplikacja bezpiecznie obniża wydajność, zwracając domyślne lub buforowane odpowiedzi, informując użytkowników o tymczasowej niedostępności niektórych danych przy zachowaniu ogólnej stabilności systemu.

Ta strategia zwiększa odporność zgodną z uzasadnieniem biznesowym. Kontrolowanie wzrostów pojemności umożliwia zespołowi obciążeń zarządzanie kosztami celowo zwiększa się, a jakość usług jest utrzymywana bez nieoczekiwanego zawyżania wydatków operacyjnych. Gdy zapotrzebowanie ustąpi lub zwiększy pojemność, a wyłącznik zostanie zresetowany, a aplikacja powróci do pełnej funkcjonalności zgodnie z celami technicznymi i budżetowymi.

Przepływ A — stan zamknięty

1. System działa normalnie, a wszystkie żądania docierają do bazy danych bez zwracania odpowiedzi HTTP 429 (zbyt wiele żądań).
2. Wyłącznik pozostaje zamknięty i nie są wymagane żadne odpowiedzi domyślne ani buforowane.

Przepływ B — stan otwarcia

1. Po otrzymaniu pierwszej odpowiedzi 429 wyłącznik przechodzi do stanu otwarcia.
2. Kolejne żądania są natychmiast zwarcie, zwracane odpowiedzi domyślne lub buforowane podczas informowania użytkowników o tymczasowym pogorszeniu, a aplikacja jest chroniona przed dalszym przeciążeniem.
3. Dzienniki i dane telemetryczne są przechwytywane i wysyłane do usługi Azure Monitor w celu oceny progów dynamicznych. Alert jest wyzwalany, jeśli spełnione są warunki reguły alertu.
4. Grupa akcji aktywnie powiadamia zespół operacyjny o stanie przeciążenia.
5. Po zatwierdzeniu przez zespół ds. obciążeń zespół operacyjny może zwiększyć aprowizowaną przepływność w celu złagodzenia przeciążenia lub może opóźnić skalowanie, jeśli obciążenie ustąpi naturalnie.

Przepływ C — stan pół otwarcia

1. Po wstępnie zdefiniowanym przekroczeniu limitu czasu wyłącznik przechodzi w stan półwartości, zezwalając na ograniczoną liczbę żądań próbnych.
2. Jeśli te żądania w wersji próbnej kończą się powodzeniem bez zwracania 429 odpowiedzi, wyłącznik resetuje się do stanu zamkniętego, przywracając normalne operacje z powrotem do usługi Flow A. Jeśli awarie będą nadal występować, zostanie przywrócony stan otwarcia, który jest usługą Flow B.

Projektowanie

• usługi Azure App Services hostuje aplikację internetową działającą jako podstawowy punkt wejścia dla żądań klientów. Kod aplikacji implementuje logikę wymuszającą zasady wyłącznika i dostarcza domyślne lub buforowane odpowiedzi po otwarciu obwodu. Ta architektura zapobiega przeciążeniu systemów podrzędnych i zapewnia, że środowisko użytkownika jest utrzymywane podczas szczytowego zapotrzebowania lub awarii.
• usługi Azure Cosmos DB jest jednym z magazynów danych aplikacji. Udostępnia ona dane niekrytyczne przy użyciu warstwy Bezpłatna. Warstwa Bezpłatna jest najlepiej używana do uruchamiania małych obciążeń produkcyjnych. Mechanizm wyłącznika pomaga ograniczyć ruch do bazy danych w okresach wysokiego zapotrzebowania.
• usługa Azure Monitor działa jako scentralizowane rozwiązanie do monitorowania, agregując wszystkie dzienniki aktywności w celu zapewnienia kompleksowej możliwości obserwacji. Dzienniki i dane telemetryczne z usług Azure App Services i kluczowych metryk z usługi Azure Cosmos DB (na przykład liczba odpowiedzi 429) są wysyłane do usługi Azure Monitor w celu agregacji i analizy.
• alerty usługi Azure Monitor ważyć reguły alertów względem progów dynamicznych w celu zidentyfikowania potencjalnych awarii na podstawie danych historycznych. Wstępnie zdefiniowane alerty powiadamiają zespół operacyjny o naruszeniu progów. Czasami zespół ds. obciążeń zatwierdza wzrost aprowizowanej przepływności, ale zespół operacyjny przewiduje, że system zostanie odzyskany samodzielnie, ponieważ obciążenie nie jest zbyt wysokie. W takich przypadkach limit czasu wyłącznika upłynie naturalnie. W tym czasie, jeśli 429 odpowiedzi przestaną działać, obliczenie progu wykrywa długotrwałe awarie i wyklucza je z algorytmu uczenia. W rezultacie przy następnym przeciążeniu próg czeka na wyższy współczynnik błędów w usłudze Azure Cosmos DB, a powiadomienie jest opóźnione. Ta zmiana umożliwia wyłącznikowi obsługę problemu bez natychmiastowego alertu, a wydajność kosztów i obciążeń operacyjnych jest zrealizowana.

Powiązane zasoby

Podczas wdrażania tego wzorca przydatne mogą być następujące wzorce:

• Wzorzec niezawodnej aplikacji internetowej pokazuje, jak zastosować wzorzec wyłącznika do aplikacji internetowych zbieżnych w chmurze.

• Wzorzec ponawiania. Opisuje, w jaki sposób aplikacja może obsługiwać przewidywane tymczasowe błędy podczas próby połączenia z usługą lub zasobem sieciowym, w sposób niewidoczny ponawiając operację, która poprzednio zakończyła się niepowodzeniem.

• Wzorzec monitorowania punktu końcowego kondycji. Wyłącznik może sprawdzić kondycję usługi, wysyłając żądanie do punktu końcowego uwidocznionego przez usługę. Usługa powinna zwrócić informacje wskazujące jej stan.