Wzorzec wyłącznika obwodu

Wzorzec wyłącznika obwodu pomaga radzić sobie z błędami, które mogą wymagać różnego czasu na odzyskanie, gdy aplikacja łączy się z zdalną usługą lub zasobem. Wyłącznik tymczasowo blokuje dostęp do wadliwej usługi po wykryciu awarii. Ta akcja zapobiega powtarzającym się nieudanym próbom, dzięki czemu system może skutecznie odzyskiwać dane. Ten wzorzec może poprawić stabilność i odporność aplikacji.

Kontekst i problem

W środowisku rozproszonym wywołania zdalnych zasobów i usług mogą zakończyć się niepowodzeniem z powodu przejściowych błędów. Błędy przejściowe obejmują przeciążone lub tymczasowo niedostępne zasoby, wolne połączenia sieciowe lub timeouty. Te błędy zwykle naprawiają się po krótkim czasie. Aby ułatwić zarządzanie tymi błędami, należy zaprojektować aplikację w chmurze w celu użycia strategii, takiej jak wzorzec ponawiania prób.

Nieprzewidziane zdarzenia mogą tworzyć błędy, które mogą trwać dłużej, aby naprawić. Te błędy mogą być w zakresie ważności od częściowej utraty łączności z kompletną awarią usługi. W takich sytuacjach aplikacja nie powinna stale ponawiać próby wykonania operacji, która prawdopodobnie nie powiedzie się. Zamiast tego aplikacja powinna szybko rozpoznać operację, która zakończyła się niepowodzeniem i odpowiednio obsłużyć awarię.

Jeśli usługa jest zajęta, awaria w jednej części systemu może prowadzić do awarii kaskadowych. Można na przykład skonfigurować operację, która wywołuje usługę w celu zaimplementowania limitu czasu. Jeśli usługa nie odpowie w tym okresie, operacja odpowiada komunikatem o błędzie.

Jednak ta strategia może blokować równoczesne żądania do tej samej operacji do momentu wygaśnięcia limitu czasu. Te zablokowane żądania mogą zajmować krytyczne zasoby systemowe, takie jak pamięć, wątki i połączenia z bazą danych. Ten problem może wyczerpać zasoby, co może zakończyć się niepowodzeniem innych niepowiązanych części systemu, które muszą korzystać z tych samych zasobów.

W takich sytuacjach operacja powinna zakończyć się niepowodzeniem natychmiast i spróbować wywołać usługę tylko wtedy, gdy prawdopodobnie zakończy się powodzeniem. Aby rozwiązać ten problem, ustaw krótszy limit czasu. Upewnij się jednak, że limit czasu jest wystarczająco długi, aby operacja powiodła się przez większość czasu.

Rozwiązanie

Wzorzec wyłącznika pomaga zapobiec temu, aby aplikacja wielokrotnie próbowała uruchomić operację, która prawdopodobnie zakończy się niepowodzeniem. Ten wzorzec umożliwia aplikacji kontynuowanie działania bez oczekiwania na naprawienie błędu lub marnowanie cykli procesora CPU na ustalenie, czy błąd jest trwały. Wzorzec wyłącznika umożliwia również aplikacji wykrywanie, kiedy błąd zostanie rozwiązany. Jeśli błąd zostanie rozwiązany, aplikacja może spróbować wywołać operację ponownie.

Uwaga / Notatka

Wzorzec zabezpieczenia przeciążeniowego ma inny cel niż wzorzec ponownego próbowania. Wzorzec ponawiania umożliwia aplikacji ponawianie próby wykonania operacji z oczekiwaniem, że ostatecznie zakończy się powodzeniem. Wzorzec wyłącznika uniemożliwia aplikacji wykonywanie operacji, która prawdopodobnie zakończy się niepowodzeniem. 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 być wrażliwa na wszelkie wyjątki, które zwraca wyłącznik, i zatrzymać próby ponawiania, jeśli 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 natychmiastowe zwrócenie wyjątku.

Proxy można zaimplementować jako maszynę stanu, która zawiera następujące stany. Stany te naśladują funkcjonalność wyłącznika elektrycznego:

• Zamknięty: Żądanie z aplikacji jest kierowane do operacji. Serwer proxy utrzymuje liczbę ostatnich niepowodzeń. Jeśli wywołanie operacji zakończy się niepowodzeniem, serwer proxy zwiększa tę liczbę. Jeśli liczba ostatnich niepowodzeń przekracza określony próg w danym okresie, serwer proxy zostanie umieszczony w stanie Otwórz i uruchomi limit czasu. Po wygaśnięciu czasomierza serwer proxy zostanie umieszczony w stanie Half-Open .

  Uwaga / Notatka

  Podczas przekroczenia limitu czasu system próbuje rozwiązać problem, który spowodował awarię, zanim umożliwi aplikacji ponowne podjęcie próby wykonania operacji.

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

• Półotwarta: Ograniczona liczba żądań z aplikacji może przechodzić przez system i wywoływać operację. Jeśli te żądania zakończyły się pomyślnie, wyłącznik zakłada, że usterka, która spowodowała awarię, jest naprawiona, a wyłącznik przełącza się w stan Zamknięty . Licznik błędów jest resetowany. Jeśli jakiekolwiek żądanie zakończy się niepowodzeniem, wyłącznik zakłada, że błąd jest nadal obecny, więc przywraca stan Otwarcia . Ponownie uruchamia licznik czasu, aby system mógł się odzyskać po awarii.

  Uwaga / Notatka

  Stan Half-Open pomaga zapobiec nagłemu zalewaniu żądaniami serwisu, który jest w trakcie odzyskiwania. W miarę odzyskiwania usługi może być możliwe obsługę ograniczonej liczby żądań do czasu ukończenia odzyskiwania. Ale gdy odzyskiwanie jest w toku, duże obciążenie pracą może spowodować przekroczenie limitu czasu usługi lub ponowny błąd.

Na poniższym diagramie przedstawiono operacje licznika dla każdego stanu.

Na diagramie przedstawiono trzy sekcje z etykietą zamknięte, półwarte i otwarte. Stan zamknięty obejmuje akcję resetowania licznika błędów. Jeśli operacja powiedzie się, zwraca wynik, w przeciwnym razie licznik niepowodzeń przyrostowych zwraca błąd. Stan półotwarty obejmuje akcję resetowania licznika sukcesu. Jeśli operacja powiedzie się, licznik powodzenia przyrostu zwraca wynik, w przeciwnym razie zwraca błąd. Stan otwarty obejmuje akcje uruchomienia zegara odmierzającego czas bezczynności, a następnie zwrócenie komunikatu błędu. Strzałka od stanu zamkniętego do otwartego wskazuje, że próg awarii został osiągnięty. Strzałka ze stanu otwartego do stanu półotwartego wskazuje, że zegar oczekiwania wygasł. Strzałka wskazująca przejście ze stanu półotwartego do zamkniętego oznacza, że próg liczby udanych prób został osiągnięty. Strzałka wskazująca przejście z półotwartego do otwartego stanu oznacza, że operacja się nie powiodła.

Licznik awarii stanu Zamknięte jest oparty na czasie. Automatycznie resetuje się w okresowych odstępach czasu. Ten projekt pomaga zapobiec wejściu wyłącznika w stan otwarty , jeśli wystąpią sporadyczne awarie. Próg niepowodzenia wyzwala stan otwarty tylko wtedy, gdy określona liczba awarii wystąpi w określonym interwale.

Licznik powodzenia stanu Half-Open rejestruje liczbę pomyślnych prób wywołania operacji. Wyłącznik powraca do stanu Zamknięte po określonej liczbie pomyślnych wywołań operacji. Jeśli jakiekolwiek wywołanie zakończy się niepowodzeniem, wyłącznik natychmiast przechodzi w stan Otwarty , a licznik powodzenia resetuje się przy następnym wejściu w stan Half-Open .

Uwaga / Notatka

Odzyskiwanie systemu jest oparte na operacjach zewnętrznych, takich jak przywracanie lub ponowne uruchamianie składnika, który zakończył się niepowodzeniem lub naprawianie połączenia sieciowego.

Wzorzec wyłącznika zapewnia stabilność podczas odzyskiwania systemu po awarii i minimalizuje negatywny wpływ na wydajność. Może pomóc w utrzymaniu czasu odpowiedzi systemu. Ten wzorzec szybko odrzuca żądanie operacji, która prawdopodobnie zakończy się niepowodzeniem, zamiast czekać na przekroczenie limitu czasu operacji lub nigdy nie zostanie zwrócona. Jeśli wyłącznik zgłasza zdarzenie za każdym razem, gdy zmienia stan, te informacje mogą pomóc monitorować kondycję składnika systemu chronionego lub ostrzegać administratora, gdy wyłącznik przełącza się do stanu Otwórz .

Ten wzorzec można dostosować do różnych typów awarii. Na przykład można zastosować do wyłącznika zwiększenie limitu czasu. Wyłącznik można umieścić w stanie Otwarcia przez kilka sekund. Jeśli błąd nie zostanie rozwiązany, zwiększ limit czasu do kilku minut i odpowiednio dostosuj go. W niektórych przypadkach zamiast zwracać błąd i zgłaszać wyjątek, stan Otwórz może zwrócić wartość domyślną zrozumiałą dla aplikacji.

Uwaga / Notatka

Tradycyjnie wyłączniki opierały się na wstępnie skonfigurowanych progach, takich jak liczba awarii i czas wyczekiwania. Takie podejście spowodowało deterministyczne, ale czasami nieoptymalne zachowanie.

Techniki adaptacyjne korzystające ze sztucznej inteligencji i uczenia maszynowego mogą dynamicznie dostosowywać progi na podstawie wzorców ruchu w czasie rzeczywistym, anomalii i historycznych współczynników błędów. Takie podejście zwiększa odporność i wydajność.

Problemy i zagadnienia

Podczas implementowania tego wzorca należy wziąć pod uwagę następujące czynniki:

• Obsługa wyjątków: Aplikacja, która wywołuje operację za pośrednictwem wyłącznika, musi być w stanie obsłużyć wyjątki, jeśli operacja jest niedostępna. Zarządzanie wyjątkami jest oparte na aplikacji. Na przykład aplikacja może tymczasowo obniżyć jej funkcjonalność, wywołać alternatywną operację, aby spróbować wykonać to samo zadanie lub uzyskać te same dane, albo zgłosić wyjątek użytkownikowi i poprosić go o próbę ponownie później.

• Typy wyjątków: Przyczyny niepowodzenia żądania mogą się różnić w ważności. Na przykład żądanie może zakończyć się niepowodzeniem, ponieważ usługa zdalna ulega awarii i wymaga kilku minut na odzyskiwanie, lub ponieważ przeciążona usługa powoduje wystąpienie limitu czasu. Wyłącznik może być w stanie zbadać typy występujących wyjątków i dostosować swoją strategię w zależności od ich charakteru. Na przykład może wymagać większej liczby wyjątków przekroczenia limitu czasu w celu wyzwolenia wyłącznika do stanu otwarcia w porównaniu z liczbą awarii spowodowanych niedostępną usługą.

• Monitoring: Wyłącznik powinien zapewnić wyraźną zauważalność zarówno żądań zakończonych niepowodzeniem, jak i pomyślnych, aby zespoły operacyjne mogły ocenić kondycję systemu. Użyj śledzenia rozproszonego, aby uzyskać kompleksową widoczność między usługami.

• Odzyskiwalność: Należy skonfigurować wyłącznik obwodu tak, aby odpowiadał prawdopodobnemu wzorcowi odtwarzania operacji, którą chroni. Jeśli na przykład wyłącznik pozostaje w stanie Otwartym przez długi czas, może zgłaszać wyjątki nawet wtedy, gdy przyczyna awarii zostanie usunięta. Podobnie wyłącznik może ulegać wahaniom i zmniejszać czasy odpowiedzi aplikacji, jeśli przełączy się ze stanu Otwarte do stanu Półotwarty zbyt szybko.

• Testowanie operacji błędnych: W stanie Otwartym, zamiast z wykorzystaniem timera, aby określić, kiedy przełączyć się do stanu Półotwartym, wyłącznik może okresowo wysyłać polecenia ping do zdalnej usługi lub zasobu, aby sprawdzić dostępność. To polecenie ping może próbować wywołać wcześniej nieudaną operację lub użyć specjalnej operacji sprawdzania kondycji zapewnianej przez usługę zdalną. Aby uzyskać więcej informacji, zobacz wzorzec monitorowania punktów końcowych kondycji .

• Ręczne sterowanie: Jeśli czas odzyskiwania operacji zakończonej niepowodzeniem jest bardzo zmienny, należy podać opcję ręcznego resetowania, która umożliwia administratorowi przełączenie wyłącznika i zresetowanie licznika awarii. Podobnie administrator może wymusić wyłącznik w stanie Otwartego i ponownie uruchomić czasomierz limitu czasu, jeśli chroniona operacja jest tymczasowo niedostępna.

• Współbieżności: Duża liczba współbieżnych wystąpień aplikacji może uzyskać dostęp do tego samego wyłącznika. 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, który zawiera wiele fragmentów, jeden fragment może być w pełni dostępny, podczas gdy inny doświadcza tymczasowego problemu. Jeśli odpowiedzi na błędy w tych scenariuszach zostaną scalone, aplikacja może spróbować uzyskać dostęp do niektórych fragmentów nawet wtedy, gdy prawdopodobnie wystąpi awaria. Dostęp do innych fragmentów może zostać zablokowany, mimo że prawdopodobnie zakończy się powodzeniem.

• Przyspieszone przerywanie obwodu: Czasami odpowiedź na awarię może zawierać wystarczającą ilość informacji, aby wyłącznik natychmiast się wyłączył i pozostał wyłączony przez minimalny okres czasu. Na przykład odpowiedź o błędzie z zasobu udostępnionego, który jest przeciążony, może wskazywać, że aplikacja powinna zamiast ponawiać próbę natychmiast, spróbować ponownie za kilka minut.

• Wdrożenia w wielu regionach: Wyłącznik można zaprojektować dla wdrożeń w jednym regionie lub w wielu regionach. Aby zaprojektować wdrożenia w wielu regionach, należy użyć globalnych modułów równoważenia obciążenia lub niestandardowych strategii przerywania obwodów obsługujących region, które pomagają zapewnić kontrolowany tryb failover, optymalizację opóźnień i zgodność z przepisami.

• Wyłączniki siatki usług: Wyłączniki można zaimplementować w warstwie aplikacji lub jako funkcję przekrojową, abstrakcyjną. Na przykład siatki usług często obsługują przerywanie obwodu jako przyczepki lub jako autonomiczną możliwość bez modyfikowania kodu aplikacji.

  Uwaga / Notatka

  Usługa może zwrócić HTTP 429 (zbyt wiele żądań), jeśli wstrzymuje klienta lub HTTP 503 (usługa niedostępna), jeśli usługa jest niedostępna. Odpowiedź może zawierać inne informacje, takie jak przewidywany czas trwania opóźnienia.

• Ponowne odtwarzanie żądania, które zakończyło się niepowodzeniem: W stanie Otwarcia wyłącznik zamiast po prostu szybko się wyłączyć może również rejestrować szczegóły każdego żądania w dzienniku i ustawiać te żądania do ponownego odtworzenia, gdy zdalny zasób lub usługa będzie dostępna.

• Nieodpowiednie czasy oczekiwania dla usług zewnętrznych: Wyłącznik może nie w pełni chronić aplikacje przed awariami w usługach zewnętrznych, które charakteryzują się długim czasem oczekiwania. Jeśli przerwa czasowa jest zbyt długa, wątek, która uruchamia wyłącznik, może zostać zablokowany na długi czas, zanim wyłącznik wskazuje na to, ż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 i powiązać wiele wątków przed awarią.

• Dostosowanie do dywersyfikacji zasobów obliczeniowych: Wyłączniki powinny uwzględniać różne środowiska obliczeniowe, od bezserwerowych po konteneryzowane obciążenia, gdzie czynniki takie jak zimne starty i skalowalność wpływają na obsługę awarii. Metody adaptacyjne mogą dynamicznie dostosowywać strategie na podstawie typu obliczeniowego, co pomaga zapewnić odporność między architekturami heterogenicznymi.

Kiedy należy używać tego wzorca

Użyj tego wzorca, gdy:

• Chcesz zapobiec awariom kaskadowym, zatrzymując nadmierne wywołania usług zdalnych lub żądań dostępu do udostępnionego zasobu, jeśli te operacje mogą zakończyć się niepowodzeniem.

• Chcesz inteligentnie kierować ruch na podstawie sygnałów awarii w czasie rzeczywistym, aby zwiększyć odporność wielu regionów.

• Chcesz chronić się przed wolnymi zależnościami, aby móc utrzymać cele poziomu usług i uniknąć obniżenia wydajności przez usługi o wysokim opóźnieniu.

• Chcesz zarządzać sporadycznymi problemami z łącznością i zmniejszyć liczbę błędów żądań w środowiskach rozproszonych.

Ten wzorzec może nie być odpowiedni w następujących przypadkach:

• Musisz zarządzać dostępem do lokalnych zasobów prywatnych w aplikacji, takich jak struktury danych w pamięci. W tym środowisku wyłącznik zwiększa obciążenie systemu.

• Należy użyć go jako zamiennika do obsługi wyjątków w logice biznesowej aplikacji.

• Dobrze znane algorytmy ponawiania prób są wystarczające, a zależności są przeznaczone do obsługi mechanizmów ponawiania prób. W tym scenariuszu wyłącznik w aplikacji może zwiększyć niepotrzebną złożoność systemu.

• Oczekiwanie na zresetowanie wyłącznika może spowodować niedopuszczalne opóźnienia.

• Masz architekturę opartą na komunikatach lub architekturę sterowaną zdarzeniami, ponieważ często kierują niepowodzone komunikaty do kolejki martwych listów na potrzeby ręcznego lub odroczonego przetwarzania. Wbudowane mechanizmy izolacji błędów i ponawiania prób są często wystarczające.

• 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.

Projektowanie obciążenia

Oceń, jak używać wzorca wyłącznika w projekcie obciążenia, aby sprostać celom i zasadom opisanym w filarach platformy Azure Well-Architected Framework. Poniższa tabela zawiera wskazówki dotyczące tego, jak ten wzorzec obsługuje cele poszczególnych filarów.

Filar	Jak ten wzorzec obsługuje cele filaru
Decyzje projektowe dotyczące niezawodności pomagają obciążeniom stały się odporne na awarię i zapewniają, że zostanie ono przywrócone do w pełni funkcjonalnego stanu po wystąpieniu awarii.	Ten wzorzec pomaga zapobiec przeciążeniu zależności, która powoduje błędy. Użyj tego wzorca, aby wyzwolić łagodne obniżenie obciążenia. Łącz wyłączniki z automatycznym przywracaniem, aby zapewnić samozachowanie i samonaprawianie. - ANALIZA trybu awarii RE:03 - Błędy przejściowe - RE:07 Instynkt samozachowawczy
Efektywność wydajności pomaga wydajnie sprostać wymaganiom dzięki optymalizacjom skalowania, danych i kodu.	Ten wzorzec pozwala uniknąć metody ponawiania próby przy błędzie, co może prowadzić do nadmiernego użycia zasobów podczas odzyskiwania zależności i może przeciążyć wydajność zależności, która próbuje odzyskać. - PE:07 Kod i infrastruktura - PE:11 Odpowiedzi na problemy na żywo

Jeśli ten wzorzec wprowadza kompromisy w ramach filaru, rozważ je przed celami innych filarów.

Przykład

W tym przykładzie zaimplementowano wzorzec zabezpieczenia przed przeciążeniem, aby zapobiec przekroczeniu limitu przydziału, korzystając z darmowej warstwy na czas istnienia usługi Azure Cosmos DB. Ta warstwa jest przeznaczona głównie dla danych niekrytycznych i działa w ramach planu pojemności, który przydziela określony limit przydziału jednostek zasobów na sekundę. W przypadku wydarzeń sezonowych zapotrzebowanie może przekroczyć podaną wydajność, co może spowodować 429 odpowiedzi.

Gdy wystąpi wzrost zapotrzebowania, alerty usługi Azure Monitor z progami dynamicznymi wykrywają i aktywnie powiadamiają zespoły ds. operacji i zarządzania, że baza danych wymaga większej pojemności. Jednocześnie wyłącznik dostrojony przy użyciu historycznych wzorców błędów zadziała, aby zapobiec awariom kaskadowym. W tym stanie aplikacja bezpiecznie obniża wydajność, zwracając domyślne lub buforowane odpowiedzi. Aplikacja informuje użytkowników o tymczasowej niedostępności niektórych danych przy zachowaniu ogólnej stabilności systemu.

Ta strategia zwiększa odporność, która jest zgodna z uzasadnieniem biznesowym. Kontroluje wzrosty pojemności, dzięki czemu zespoły zajmujące się obciążeniami mogą celowo zarządzać kosztami i utrzymywać jakość usług bez nieoczekiwanego zwiększania wydatków operacyjnych. Po potwierdzeniu zapotrzebowania lub zwiększeniu pojemności wyłącznik resetuje się, a aplikacja powraca do pełnej funkcjonalności, która jest zgodna zarówno z celami technicznymi, jak i budżetowymi.

Diagram zawiera trzy główne sekcje. Pierwsza sekcja zawiera dwie ikony przeglądarki internetowej. Pierwsza ikona wyświetla w pełni funkcjonalny interfejs użytkownika, a druga ikona przedstawia obniżone środowisko użytkownika z ostrzeżeniem na ekranie wskazującym problem dla użytkowników. Druga sekcja jest ujęta w prostokąt linii kreskowanej, który jest podzielony na dwie grupy. Najwyższa grupa obejmuje zasoby związane z obciążeniem, App Service i Azure Cosmos DB. Strzałki z obu ikon przeglądarki internetowej wskazują instancję usługi App Service, reprezentując żądania przychodzące od klienta. Ponadto strzałki z wystąpienia App Service wskazują na Azure Cosmos DB, sygnalizując interakcje danych między usługami aplikacji a bazą danych. Kolejna strzałka zapętla się z wystąpienia usługi App Service z powrotem do samego siebie, symbolizując mechanizm przekroczenia limitu czasu wyłącznika. Ta pętla oznacza, że po wykryciu odpowiedzi 429 Zbyt wiele żądań system powraca do obsługi buforowanych odpowiedzi, obniżając wydajność środowiska użytkownika, dopóki sytuacja nie zostanie rozwiązana. Dolna grupa tej sekcji koncentruje się na obserwacji i alertach. Usługa Azure Monitor zbiera dane z zasobów platformy Azure w pierwszej grupie. Usługa Azure Monitor łączy się również z ikoną reguły alertu. W trzeciej sekcji przedstawiono przepływ pracy skalowalności wyzwalany podczas zgłaszania alertu. Strzałka łączy ikonę alertu z osobami zatwierdzających, co oznacza, że powiadomienie jest wysyłane do nich w celu przejrzenia. Kolejna strzałka prowadzi od osób zatwierdzających do konsoli programistycznej, co oznacza proces zatwierdzania skalowania bazy danych. Na koniec kolejna strzałka rozciąga się z konsoli programistycznej na usługę Azure Cosmos DB, która przedstawia akcję skalowania bazy danych w odpowiedzi na warunek przeciążenia.

Pobierz plik programu Visio tej architektury.

Przepływ A: stan zamknięty

• System działa normalnie, a wszystkie żądania docierają do bazy danych bez zwracania odpowiedzi 429 HTTP.

• Wyłącznik pozostaje zamknięty i nie są wymagane żadne odpowiedzi domyślne ani buforowane.

Przepływ B: stan otwarty

1. Gdy wyłącznik odbiera pierwszą 429 odpowiedź, przechodzi do stanu Otwórz .

2. Kolejne żądania są natychmiast przerywane, co zwraca domyślne lub z pamięci podręcznej odpowiedzi i informuje użytkowników o tymczasowym pogorszeniu. Aplikacja jest chroniona przed dalszym przeciążeniem.

3. Usługa Azure Monitor odbiera dzienniki i dane telemetryczne i ocenia je pod kątem progów dynamicznych. Alert jest wyzwalany w przypadku spełnienia warunków 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ść, aby złagodzić przeciążenie lub opóźnić skalowanie, jeśli obciążenie ustąpi naturalnie.

Stan Half-Open: Przepływ C

1. Po wstępnie zdefiniowanym przekroczeniu limitu czasu wyłącznik przechodzi w stan Half-Open , który zezwala na ograniczoną liczbę żądań próbnych.

2. Jeśli te żądania próbne się powiodą bez zwracania 429 odpowiedzi, wyłącznik resetuje się do stanu Zamknięty, a normalne operacje wracają do Flow A. Jeśli awarie będą się powtarzać, wyłącznik powróci do stanu Otwarte lub do Flow B.

Komponenty

• Usługa Azure App Service hostuje aplikację internetową, która służy 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 pomaga zapobiegać przeciążeniu systemów podrzędnych i utrzymywać środowisko użytkownika podczas szczytowego zapotrzebowania lub awarii.

• usługi Azure Cosmos DB jest jednym z magazynów danych aplikacji. Udostępnia ona dane niekrytyczne poprzez bezpłatną warstwę, która jest idealna dla niewielkich zadań 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. Agreguje wszystkie dzienniki aktywności, aby zapewnić kompleksową, szeroką obserwowalność. Usługa Azure Monitor odbiera dzienniki i dane telemetryczne z usługi App Service oraz kluczowe metryki z usługi Azure Cosmos DB (na przykład liczbę 429 odpowiedzi) na potrzeby 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ń może zatwierdzić wzrost aprowizowanej przepływności, ale zespół operacyjny przewiduje, że system może odzyskać 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, co opóźnia powiadomienie. Ta korekta umożliwia wyłącznikowi obsługę problemu bez natychmiastowego alertu, co zwiększa koszty i wydajność operacyjną.

Powiązane zasoby

• Wzorzec niezawodnej aplikacji internetowej stosuje wzorzec obwodu w aplikacjach internetowych, które działają w chmurze.

• Wzorzec ponawiania prób opisuje, jak aplikacja może obsługiwać przewidywane tymczasowe błędy podczas próby nawiązania połączenia z usługą lub zasobem sieciowym przez przezroczyste ponawianie próby wykonania operacji, która wcześniej zakończyła się niepowodzeniem.

• Wzorzec monitorowania kondycji końcowej usługi opisuje, w jaki sposób wyłącznik obwodu może testować stan zdrowia usługi poprzez wysyłanie żądania do punktu końcowego wystawianego przez tę usługę. Usługa powinna zwrócić informacje wskazujące jej stan.