Rekomendacje dotyczące obsługi błędów przejściowych

Ten przewodnik opisuje rekomendacje dotyczące obsługi błędów przejściowych w aplikacjach w chmurze. Wszystkie aplikacje, które komunikują się ze zdalnymi usługami i zasobami, muszą być wrażliwe na błędy przejściowe. Jest to przydatne w przypadku aplikacji uruchamianych w chmurze, gdzie ze względu na charakter środowiska i łączność za pośrednictwem Internetu ten typ awarii prawdopodobnie będzie spotykany częściej. Błędy przejściowe obejmują chwilową utratę połączeń sieciowych ze składnikami i usługami, tymczasową niedostępność usługi oraz przekroczenia limitów czasu, które występują podczas intensywnej pracy usługi. Te błędy często się poprawiają, więc jeśli akcja zostanie powtórzona po odpowiedniej opóźnieniu, prawdopodobnie się powiedzie.

Ten artykuł zawiera ogólne wskazówki dotyczące obsługi błędów przejściowych. Aby uzyskać informacje na temat implementowania ponownych prób w kodzie aplikacji do obsługi błędów przejściowych, zobacz wzorzec ponawiania prób i podczas korzystania z usług platformy Azure, zobacz Wskazówki dotyczące ponawiania prób dla usług platformy Azure.

Błędy przejściowe

Błędy przejściowe mogą występować w dowolnym środowisku, na dowolnej platformie lub w systemie operacyjnym i w każdym typie aplikacji. W przypadku rozwiązań, które działają w lokalnej infrastrukturze lokalnej, wydajność i dostępność aplikacji i jej składników są zwykle utrzymywane za pośrednictwem kosztownej i często niedostatecznej nadmiarowości sprzętowej, a składniki i zasoby znajdują się blisko siebie. Takie podejście sprawia, że awaria jest mniej prawdopodobna, ale błędy przejściowe mogą nadal występować, ponieważ mogą wystąpić awarie spowodowane nieprzewidzianymi zdarzeniami, takimi jak zewnętrzne problemy z zasilaniem lub siecią, lub scenariusze awarii.

Hosting w chmurze, w tym systemy chmury prywatnej, może oferować większą ogólną dostępność dzięki wykorzystaniu dzielonych zasobów, redundancji, mechanizmu automatycznego przełączania awaryjnego i dynamicznej alokacji zasobów na wielu typowych węzłach obliczeniowych. Jednak ze względu na charakter środowisk w chmurze błędy przejściowe są bardziej prawdopodobne. Istnieje kilka powodów tego:

• Wiele zasobów w środowisku chmury jest współużytkowanych, a dostęp do tych zasobów podlega ograniczaniu w celu ochrony zasobów. Niektóre usługi odmawiają połączeń, gdy obciążenie wzrośnie do określonego poziomu lub gdy zostanie osiągnięty maksymalny współczynnik przepływności, aby umożliwić przetwarzanie istniejących żądań i utrzymanie wydajności usługi dla wszystkich użytkowników. Ograniczanie pomaga zachować jakość usług dla sąsiadów i innych najemców, którzy korzystają z udostępnionego zasobu.

• Środowiska w chmurze używają dużej liczby zwykłego sprzętu. Zapewniają one wydajność dzięki dynamicznej dystrybucji obciążenia między wieloma jednostkami obliczeniowymi i składnikami infrastruktury. Zapewniają one niezawodność przez automatyczne przywracanie lub zastępowanie jednostek, które zakończyły się niepowodzeniem. Ze względu na ten dynamiczny charakter błędy przejściowe i tymczasowe błędy połączenia mogą czasami wystąpić.

• Istnieje często więcej składników sprzętowych, w tym infrastruktury sieciowej, takich jak routery i moduły równoważenia obciążenia, między aplikacją a zasobami i usługami, których używa. Ta dodatkowa infrastruktura może czasami wprowadzać dodatkowe opóźnienia połączenia i przejściowe błędy połączenia.

• Warunki sieciowe między klientem a serwerem mogą być zmienne, szczególnie w przypadku komunikacji przez Internet. Nawet w lokalizacjach lokalnych duże obciążenia ruchu mogą spowalniać komunikację i powodować sporadyczne błędy połączeń.

Błędy przejściowe mogą mieć znaczący wpływ na ograniczoną dostępność aplikacji, nawet jeśli została dokładnie przetestowana w wszystkich okolicznościach. Aby zapewnić niezawodne działanie aplikacji hostowanych w chmurze, należy upewnić się, że mogą one reagować na następujące wyzwania:

• Aplikacja musi być w stanie wykrywać błędy podczas ich wystąpienia i określić, czy prawdopodobne są przejściowe, długotrwałe czy ostateczne. Różne zasoby prawdopodobnie zwracają różne odpowiedzi w momencie wystąpienia zdarzeń, a odpowiedzi te mogą się różnić w zależności od kontekstu operacji. Na przykład odpowiedź na błąd podczas gdy aplikacja odczytuje dane z magazynu, może różnić się od odpowiedzi na błąd, gdy zapisuje dane do magazynu. Wiele zasobów i usług ma dobrze udokumentowane kontrakty na błędy przejściowe. Jednak jeśli takie informacje nie są dostępne, może być trudne do odnalezienia charakteru błędu i tego, czy może to być przejściowe.

• Aplikacja musi mieć możliwość ponownego wykonania operacji, jeśli ustali, że błąd jest prawdopodobne przejściowy. Musi również śledzić liczbę ponownych prób wykonania operacji.

• Aplikacja musi używać odpowiedniej strategii na potrzeby ponownych prób. Strategia określa liczbę razy, kiedy aplikacja powinna ponowić próbę, opóźnienie między każdą próbą i akcje do podjęcia po nieudanej próbie. Często trudno jest określić odpowiednią liczbę prób i opóźnienie między nimi. Strategia zależy od typu zasobu oraz bieżących warunków działania zasobu i aplikacji.

Poniższe wytyczne mogą ułatwić projektowanie odpowiednich mechanizmów obsługi aplikacji.

Implementowanie mechanizmu ponownych prób

Określanie, czy jest wbudowany mechanizm ponawiania prób

• Wiele usług udostępnia zestaw SDK lub bibliotekę klienta, która zawiera mechanizm obsługi błędów przejściowych. Używane zasady ponawiania jest zwykle dostosowana do charakteru i wymagań usługi docelowej. Alternatywnie, interfejsy REST dla usług mogą zwracać informacje, które mogą pomóc w określeniu, czy i jak długo należy poczekać przed kolejną próbą.

• Gdy jest on dostępny, należy użyć wbudowanego mechanizmu ponawiania, chyba że są spełnione określone i dobrze zrozumiałe wymagania, które bardziej odpowiedniego zachowania ponawiania.

Określ, czy operacja jest odpowiednia do ponownego wykonania

• Operacje ponowione należy wykonać tylko wtedy, gdy błędy są przejściowe (zazwyczaj wskazane przez charakter błędu) i jeśli istnieje co najmniej prawdopodobieństwo, że operacja zakończy się pomyślnie po kolejnej operacji. Nie ma sensu ponawiać operacji, które próbują wykonać nieprawidłową operację, na przykład aktualizacji bazy danych do elementu, który nie istnieje, ani żądania do usługi lub zasobu, który doznał błędu krytycznego.

• Ogólnie rzecz biorąc, zaimplementuj ponawianie prób tylko wtedy, gdy można określić pełny efekt tego działania i kiedy warunki są dobrze zrozumiałe i można je zweryfikować. W przeciwnym razie niech kod wywołujący implementuje ponawianie prób. Należy pamiętać, że błędy zwracane z zasobów i usług poza kontrolą mogą rozwinąć się w czasie i może okazać się konieczny powrót do logiki wykrywania błędów.

• Podczas tworzenia usług lub składników rozważ zaimplementowanie kodów błędów i komunikatów, które ułatwiają klientom określenie, czy powinni ponowić próbę wykonania operacji, które zakończyły się niepowodzeniem. W szczególności wskaż, czy klient powinien ponowić próbę wykonania operacji (na przykład przez zwrócenie wartości isTransient ) i zasugerować odpowiednie opóźnienie przed następną próbą ponawiania próby. Podczas tworzenia usługi internetowej należy rozważyć zwrócenie błędów niestandardowych zdefiniowanych w kontraktach usługowych. Mimo że klienci ogólni mogą nie być w stanie odczytać tych błędów, są one przydatne przy tworzeniu niestandardowych klientów.

Określenie odpowiedniej liczby i interwału ponowień

• Zoptymalizuj liczbę ponowień i interwał dla typu przykładu użycia. Jeśli wykonasz wystarczającej liczby ponowień, aplikacja nie może ukończyć operacji i prawdopodobnie zakończy się niepowodzeniem. Jeśli ponowisz próbę zbyt wiele razy lub z zbyt krótkim interwałem między próbami, aplikacja może przechowywać zasoby, takie jak wątki, połączenia i pamięć przez długi czas, co negatywnie wpływa na kondycję aplikacji.

• Zaadaptuj wartości odstępu czasu i liczbę ponowień prób do typu operacji. Jeśli na przykład operacja jest częścią interakcji z użytkownikiem, interwał powinien być krótki i należy spróbować kilku różnych operacji. Korzystając z tego podejścia, można uniknąć sytuacji, w której użytkownicy muszą czekać na odpowiedź, co utrzymuje otwarte połączenia i może zmniejszać dostępność dla innych użytkowników. Jeśli operacja jest częścią długotrwałego lub krytycznego przepływu pracy, w którym anulowanie i ponowne uruchomienie procesu jest kosztowne lub czasochłonne, należy poczekać dłużej między próbami i ponowić próbę więcej razy.

• Należy pamiętać, że określenie odpowiednich odstępów czasu między poszczególnymi elementami jest trudne w przypadku projektowania pomyślnie udanej strategii. Typowe strategie używają następujących typów interwałów ponawiania:

  • Wykładnicze opóźnienie. Aplikacja oczekuje na krótki czas przed pierwszą ponowną próbą, a następnie zwiększa czas między kolejnymi próbami. Na przykład może ona wykonać operację po 3 sekundach, 12 sekundach i 30 sekundach itp. Aby jeszcze bardziej ulepszyć tę strategię, możesz dodać drgania do opóźnienia wykładniczego. Jitter wprowadza losowe opóźnienie dla każdej próby ponowienia, co pomaga zapobiec jednoczesnemu ponawianiu prób przez wielu klientów i powodowaniu wzrostu obciążenia.

  • Interwały przyrostowe. Aplikacja czeka chwilę przed pierwszą ponowną próbą, a następnie przyrostowo zwiększa czas między kolejnymi ponownymi próbami. Na przykład może ponowić próbę wykonania operacji po 3 sekundach, 7 sekundach, 13 sekundach itd.

  • Interwały regularne. Między każdą próbą aplikacja oczekuje na ten sam okres. Na przykład może ponowić próbę wykonania operacji co 3 sekundy.

  • Natychmiastowe ponawianie próby. Czasami błąd przejściowy jest krótki, prawdopodobnie spowodowany przez zdarzenie, takie jak kolizja pakietów sieciowych lub wzrost składnika sprzętowego. W takim przypadku natychmiastowe ponowienie operacji jest odpowiednie, ponieważ może się to powieść, jeśli błąd zostanie usunięty w czasie, którego aplikacja potrzebuje, aby złożyć i wysłać następne żądanie. Nie należy jednak podejmować więcej niż jednej bezpośredniej ponownej próby. Jeśli natychmiastowe ponowienie nie powiedzie się, należy przełączyć się na alternatywne strategie, takie jak wycofywanie wykładnicze lub działania zapasowe.

  • Randomizacja. Każda z wymienionych wcześniej strategii ponawiania może uwzględniać losowość, aby zapobiec sytuacji, w której wiele instancji klienta wysyła kolejne próby ponowienia w tym samym czasie. Na przykład jedno wystąpienie może ponowić próbę wykonania operacji po 3 sekundach, 11 sekundach, 28 sekundach itd., podczas gdy inne wystąpienie może ponowić próbę wykonania operacji po 4 sekundach, 12 sekundach, 26 sekundach itd. Randomizacja to przydatna technika, którą można połączyć z innymi strategiami.

• Ogólnie rzecz biorąc, należy stosować strategię wykładniczego wycofywania z opóźnieniem z elementem losowym dla operacji w tle, oraz używać strategii regularnych lub natychmiastowych ponowień dla operacji interaktywnych. W obu przypadkach należy wybrać opóźnienie i liczbę ponowień, aby maksymalny limit ponownych prób dla wszystkich prób pozostał w obrębie kompleksowych wymagań dotyczących opóźnienia.

• Uwzględnij kombinację wszystkich czynników, które przyczyniają się do ogólnego maksymalnego limitu czasu dla ponawianej operacji. Czynniki te obejmują czas, jaki zajmuje uzyskanie odpowiedzi po awarii połączenia (zazwyczaj ustawiony czas oczekiwania na odpowiedź w kliencie), opóźnienie między ponownymi próbami i maksymalną liczbę ponownych prób. Suma tych wszystkich czasów może powodować długie ogólne czasy operacji, zwłaszcza gdy jest używana strategia opóźnienia wykładniczego, w której odstęp między kolejnymi operacjami rozwija się szybko po każdej awarii. Jeśli proces musi spełniać określoną umowę na poziomie usługi (SLA), ogólny czas operacji, w tym wszystkie limity czasu i opóźnienia, musi znajdować się w limitach zdefiniowanych w umowie SLA.

• Nie implementuj zbyt agresywnej strategii ponawiania prób. Są to strategie z interwałami, które są zbyt krótkie, lub zbyt częstymi próbami. Mogą one mieć niekorzystny wpływ na docelowe zasoby lub usługi. Takie strategie mogą uniemożliwić zasoby lub usługi do odzyskiwania po przeciążeniu stanu i nadal będą blokować lub odrzucać żądania. W tym scenariuszu powstaje błędne koło, w którym do zasobu lub usługi jest wysyłanych coraz więcej żądań. W konsekwencji możliwość odzyskiwania jest dalej pomniejszana.

• Weź pod uwagę czas oczekiwania operacji przy wyborze interwałów ponownych prób, aby uniknąć natychmiastowego uruchomienia kolejnej próby (na przykład jeśli okres upływu czasu oczekiwania jest podobny do interwału ponowienia). Należy również rozważyć, czy należy zachować łączny możliwy okres (limit czasu oraz interwały ponawiania prób) poniżej określonego łącznego czasu. Jeśli operacja ma wyjątkowo krótki lub długi limit czasu, limit czasu może mieć wpływ na czas oczekiwania i częstotliwość ponawiania próby wykonania operacji.

• Użyj typu wyjątku i wszystkich danych, które zawiera, lub kodów błędów i komunikatów zwróconych z usługi, aby zoptymalizować liczbę ponownych prób i odstępy między nimi. Na przykład niektóre wyjątki lub kody błędów (na przykład kod HTTP 503, Usługa jest niedostępna, z nagłówkiem odpowiedzi Ponów po) może wskazywać czas działania błędu lub niepowodzenie usługi i nie zareagować na kolejne próby.

• Rozważ użycie metody kolejki utraconych komunikatów, aby upewnić się, że wszystkie informacje z przychodzącego wywołania nie zostaną utracone po wyczerpaniu wszystkich ponownych prób.

Unikanie antywzorców

• W większości przypadków należy unikać implementacji, które zawierają zduplikowane warstwy kodu ponawiania. Unikaj projektów, które obejmują kaskadowe mechanizmy ponawiania prób lub które implementują ponawianie na każdym etapie operacji obejmującej hierarchię żądań, chyba że masz określone wymagania, które tego wymagają. W tych wyjątkowo okolicznościach należy stosować zasady, które zapobiegają nadmiernego liczbie zmian i okresów opóźnieniem oraz mają pewność, że rozumieją państwo konsekwencje. Można na przykład jeden składnik zażądać od innego składnika, który następnie uzyskuje dostęp do usługi docelowej. Jeśli zaimplementowano trzy ponowne próby w obydwu wywołaniach, w sumie w przypadku usługi należy wykonać dziewięć ponownych prób. Wiele usług i zasobów implementuje wbudowany mechanizm ponowiania próby. Jeśli konieczne jest wdrożenie aplikacji na wyższym poziomie, należy sprawdzić, w jaki sposób można wyłączyć lub zmodyfikować te mechanizmy.

• Nigdy nie należy implementować mechanizmu nieskończonego ponawiania prób. Prawdopodobnie uniemożliwi to sytuację, w której zasoby lub usługi nie będą mogły odzyskać zasobów i usług w sytuacjach przeciążenia, a problemy z połączeniami będą kontynuowane przez dłuższy czas. Użyj skończonej liczby ponownych prób lub zaimplementuj wzorzec, taki jak Circuit Breaker, aby umożliwić usłudze odzyskiwanie.

• Nigdy nie należy przeprowadzać natychmiastowej ponownej próby więcej niż raz.

• Unikaj regularnego interwału ponawiania prób podczas uzyskiwania dostępu do usług i zasobów na platformie Azure, zwłaszcza w przypadku dużej liczby ponownych prób. Najlepszym podejściem w tym scenariuszu jest strategia wykładniczego wycofywania z możliwością przerywania obwodu.

• Zapobiegaj jednoczesnemu wysyłaniu ponownych prób przez wiele instancji tego samego klienta lub różnych klientów. Jeśli ten scenariusz prawdopodobnie wystąpi, należy wprowadzić losowość do interwałów ponawiania prób.

Testowanie strategii ponawiania prób i implementacji

• Przetestuj swoją strategię ponowione w możliwie najszerszej sytuacji, zwłaszcza gdy zarówno aplikacja, jak i zasoby docelowe i używane przez nie usługi są pod bardzo dużym obciążeniem. Aby sprawdzić zachowanie podczas testowania, można:

  • Uwzględnij przejściowe błędy w praktykach inżynierii chaosu i iniekcji błędów , celowo wprowadzając je do środowiska nieprodukcyjnego i produkcyjnego. Na przykład można wysłać nieprawidłowe żądania lub dodać kod, który wykrywa żądania testowe i odpowiada na różne typy błędów.

  • Utwórz zasoby lub usługi, które zwracają zakres błędów, które może zwrócić usługa rzeczywista. Obejmują wszystkie typy błędów, które ma wykrywać Twoja strategia ponawiania.

  • W przypadku niestandardowych usług, które zostały utworzone i wdrożone, należy wymusić wystąpienie błędów przejściowych przez tymczasowe wyłączenie lub przeciążenie usługi. (Nie należy przeciążać żadnych udostępnionych zasobów ani usług udostępnionych na platformie Azure).

  • Użyj bibliotek lub rozwiązań, które przechwytują i modyfikują ruch sieciowy, aby replikować niekorzystne scenariusze z testów automatycznych. Na przykład testy mogą uwzględniać dodatkowe czasy opóźnień w obie strony, usuwać pakiety, modyfikować nagłówki, a nawet zmieniać zawartość samego żądania. Umożliwia to deterministyczne testowanie podzestawu warunków awarii w przypadku błędów przejściowych i innych typów błędów.

  • Podczas testowania odporności klienckiej aplikacji internetowej na błędy przejściowe należy użyć funkcji narzędzi deweloperskich przeglądarki lub programu testowego w celu pozorowania lub blokowania żądań sieciowych.

  • Przeprowadź testy obciążeniowe i współbieżności, aby upewnić się, że mechanizm i strategia ponawiania prób działają prawidłowo w tych warunkach. Te testy pomagają również zagwarantować, że ponawianie nie wpływa negatywnie na działanie klienta ani nie powoduje wzajemnych błędów między żądaniami.

Zarządzanie konfiguracjami zasad ponawiania

• Zasady ponawiania to kombinacja wszystkich elementów strategii ponownej próby. Definiuje mechanizm wykrywania, który określa, czy błąd może być przejściowy, typ interwału do użycia (na przykład regularne, wykładne wycofywanie i losowość), rzeczywiste wartości interwału i liczba ponownych prób.

• Zaimplementuj ponawianie prób w wielu miejscach, nawet w najprostszej aplikacji i w każdej warstwie bardziej złożonych aplikacji. Zamiast trwale kodować elementy poszczególnych zasad w wielu lokalizacjach, rozważ użycie centralnego punktu do przechowywania wszystkich zasad. Na przykład przechowuj wartości, takie jak interwał i liczba ponownych prób w plikach konfiguracji aplikacji, odczytaj je w czasie wykonywania i programowo buduj zasady ponawiania prób. Ułatwia to zarządzanie ustawieniami oraz modyfikowanie i dostosowywanie wartości w celu reagowania na zmieniające się wymagania i scenariusze. Jednak należy zaprojektować system do przechowywania wartości, a nie ponownego odczytania pliku konfiguracji za każdym razem i użyć odpowiednich wartości domyślnych, jeśli nie można uzyskać wartości z konfiguracji.

• Przechowuj wartości używane do tworzenia zasad ponawiania w czasie wykonywania w systemie konfiguracji aplikacji, aby można je było zmienić bez konieczności ponownego uruchamiania aplikacji.

• Skorzystaj z wbudowanych lub domyślnych strategii ponawiania, które są dostępne w używanych interfejsach API klienta, ale tylko wtedy, gdy są one odpowiednie dla danego scenariusza. Strategie te są zazwyczaj ogólne. W niektórych scenariuszach mogą być one wszystkie potrzebne, ale w innych scenariuszach nie oferują pełnego zakresu opcji dostępnych w celu użycia określonych wymagań. Aby określić najbardziej odpowiednie wartości, należy przetestować, aby sprawdzić, jaki wpływ mają ustawienia na aplikację.

Rejestrowanie i śledzenie błędów przejściowych i nieprzejściowych

• W ramach strategii ponownej próby należy uwzględnić obsługę wyjątków i inną instrumentację, która rejestruje próby ponownego wykonania. Okresowe błędy przejściowe i ponowienia są oczekiwane i nie wskazują na problem. Regularna i zwiększana liczba ponownych prób jest jednak często wskaźnikiem problemu, który może spowodować niepowodzenie lub spowodować spadek wydajności i dostępności aplikacji.

• Rejestruj błędy przejściowe jako wpisy ostrzegawcze, a nie jako wpisy błędów, dzięki czemu systemy monitorowania nie wykryje ich jako błędów aplikacji, które mogą wyzwalać fałszywe alerty.

• Należy rozważyć przechowywanie w wpisach dziennika wartości wskazującej, czy ponowne próby są powodowane przez usługi, czy przez inne typy błędów, np. niepowodzenia połączenia, aby można było je rozróżniać podczas analizy danych. Wzrost liczby błędów ograniczania przepustowości jest często wskaźnikiem wady projektu aplikacji lub konieczności przełączenia się do usługi Premium, która oferuje dedykowany sprzęt.

• Rozważ pomiar i rejestrowanie ogólnych czasów, które upłynęły dla operacji obejmujących mechanizm ponawiania prób. Ta metryka jest dobrym wskaźnikiem ogólnego wpływu przejściowych błędów na czasy odpowiedzi użytkownika, opóźnienie procesu i wydajność przypadków użycia aplikacji. Zarejestruj również liczbę ponownych prób, aby zrozumieć czynniki, które przyczyniają się do czasu odpowiedzi.

• Należy rozważyć wdrożenie systemu telemetrycznego i monitorowania, które może podsyłać alerty w momencie, gdy liczba i wskaźnik awarii, średnia liczba operacji lub ogólny czas wykonania operacji przed wykonaniem operacji zwiększa się.

Zarządzanie operacjami, w których stale występują błędy

• Rozważ sposób obsługi operacji, które nadal są wykonywane z niepowodzeniem przy każdej próbie. Sytuacje, których to dotyczy, są nieuniknione.

  • Chociaż strategia ponawiania prób definiuje maksymalną liczbę ponownych prób wykonania operacji, nie uniemożliwia aplikacji ponownego powtórzenia operacji z taką samą liczbą ponownych prób. Na przykład, jeśli usługa przetwarzania zamówień zakończy się niepowodzeniem z powodu błędu krytycznego, który wyłącza ją z działania na stałe, strategia ponawiania może wykryć przekroczenie limitu czasu połączenia i uznać go za błąd przejściowy. Kod ponawia próbę operacji określoną liczbę razy, a następnie rezygnuje. Jednak gdy inny klient składa zamówienie, operacja jest podejmowana ponownie, mimo że za każdym razem zakończy się niepowodzeniem.

  • Aby zapobiec ciągłym ponawianiu prób dla operacji, które stale kończą się niepowodzeniem, należy rozważyć zaimplementowanie wzorca Circuit Breaker. Jeśli używasz tego wzorca, jeśli liczba niepowodzeń w określonym przedziale czasu przekracza próg, żądania są zwracane do obiektu wywołującego natychmiast jako błędy i nie ma próby uzyskania dostępu do zasobu lub usługi, która zakończyła się niepowodzeniem.

  • Aplikacja może okresowo testować usługę, sporadycznie i w długiej odstępach czasu między żądaniami, aby wykrywać jej dostęp. Odpowiedni interwał zależy od czynników, takich jak krytyczność operacji i charakter usługi. To wszystko może trwać od kilku minut do kilku godzin. Jeśli test zakończy się pomyślnie, aplikacja może wznowić normalne operacje i przekazać żądania do nowo utworzonej usługi.

  • W międzyczasie możesz wrócić do innego wystąpienia usługi (być może w innym centrum danych lub aplikacji), użyć podobnej usługi, która oferuje zgodne (może prostsze) funkcje lub wykonać pewne alternatywne operacje na podstawie nadziei, że usługa będzie dostępna wkrótce. Na przykład może się okazać, że żądania usługi będą przechowywane w kolejce lub w magazynie danych, i można później ponowić próbę. Możesz też przekierować użytkownika do alternatywnego wystąpienia aplikacji, obniżyć wydajność działania aplikacji, ale nadal zapewniać akceptowalną funkcjonalność, lub po prostu przekazać komunikat użytkownikowi, aby wskazać, że aplikacja nie jest obecnie dostępna.

Optymalizowanie implementacji ponawiania prób

• Podczas decydowania o wartościach liczby ponownych prób i długości kolejnych interwałów dla zasad należy określić, czy operacja w ramach usługi lub zasobu jest częścią operacji długotrwałej, czy wieloetapowej. Rekompensata wszystkich pozostałych kroków operacyjnych, które zakończyły się już niepowodzeniem, może być trudna lub kosztowna. W takim przypadku bardzo długi interwał i duża liczba ponownych prób może być akceptowalna, o ile ta strategia nie blokuje innych operacji przez przechowywanie lub blokowanie ograniczonych zasobów.

• Należy rozważyć, czy ponowna próba tej samej operacji może spowodować niespójności w danych. Jeśli niektóre części procesu wieloetapowego zostaną powtórzone i operacje nie będą idempotentne, mogą wystąpić niespójności. Jeśli na przykład operacja, która zwiększa wartość, jest powtarzana, generuje nieprawidłowy wynik. Powtarzanie operacji, która wysyła komunikat do kolejki, może spowodować niespójność w odbiorcy komunikatu, jeśli użytkownik nie może wykryć zduplikowanych komunikatów. Aby zapobiec tym scenariuszom, należy zaprojektować każdy krok jako operację idempotentną. Aby uzyskać więcej informacji, zobacz Wzorce idempotentności.

• Należy wziąć pod uwagę zakres operacji wykonywanych ponownie. Na przykład łatwiej jest zaimplementować ponownie kod na poziomie obejmującym kilka operacji i ponowić wszystkie w razie awarii. Może to jednak powodować problemy z identyfikatorem lub niepotrzebnymi operacjami wycofywania.

• Jeśli wybierzesz zakres ponawiania, który obejmuje kilka operacji, weź pod uwagę całkowite opóźnienie wszystkich z nich podczas określania interwałów ponawiania próby, podczas monitorowania czasu, który upłynął operacji, oraz przed zgłaszaniem alertów dotyczących błędów.

• Zastanów się, jak strategia ponawiania prób może mieć wpływ na sąsiadów i innych dzierżawców w aplikacji udostępnionej oraz w przypadku korzystania z udostępnionych zasobów i usług. Agresywne zasady ponawiania mogą spowodować zwiększenie liczby przejściowych błędów występujących dla innych użytkowników i aplikacji, które współużytkują zasoby i usługi. Podobnie aplikacja może mieć wpływ na zasady ponawiania prób zaimplementowane przez innych użytkowników zasobów i usług. W przypadku aplikacji o znaczeniu krytycznym dla działania firmy możesz chcieć korzystać z usług Premium, które nie są udostępniane. Zapewnia to większą kontrolę nad obciążeniem i ograniczaniem przepustowości tych zasobów i usług, co może pomóc w uzasadnieniu dodatkowych kosztów.

Ułatwienia platformy Azure

Większość usług platformy Azure i zestawów SDK klientów udostępnia mechanizm ponawiania prób. Jednak te mechanizmy różnią się, ponieważ każda usługa ma różne cechy i wymagania, a każdy mechanizm ponawiania prób jest dostrojony do określonej usługi. W tej sekcji przedstawiono podsumowanie funkcji mechanizmu ponawiania dla niektórych powszechnie używanych usług platformy Azure.

Example

Zobacz Niezawodny wzorzec aplikacji internetowej dla platformy .NET , aby zapoznać się z przykładem, który używa wielu wzorców omówionych w tym artykule. Istnieje również implementacja referencyjna w witrynie GitHub.

Powiązane linki

• Wzorzec wyłącznika obwodu
• wzorzec ponawiania prób
• Wzorzec ograniczania przepustowości
• Wzorzec transakcji wyrównywczej
• Wpis w blogu dotyczący wzorców idempotentności
• Odporność połączenia
• Wstrzyknij usługi testowe
• Wzorzec kolejki martwych listów

Lista kontrolna dotycząca niezawodności

Zapoznaj się z pełnym zestawem zaleceń.