Udostępnij za pośrednictwem

Obsługa błędów przejściowych

  • Artykuł

Wszystkie aplikacje komunikujące się z usługami zdalnymi i zasobami muszą być wrażliwe na błędy przejściowe. Jest to szczególnie istotne w przypadku aplikacji uruchamianych w chmurze, gdzie ze względu na charakter środowiska i łączności przez Internet ten typ błędu może wystąpić częściej. Przejściowe błędy obejmują chwilową utratę łączności sieciowej ze składnikami i usługami, tymczasową niedostępność usługi i przekroczenia limitu czasu, które występują, gdy usługa jest zajęta. Te błędy są często samonaprawiające, więc jeśli akcja jest powtarzana po odpowiednim opóźnieniu, prawdopodobnie zakończy się powodzeniem.

Ten artykuł zawiera ogólne wskazówki dotyczące obsługi błędów przejściowych.

Dlaczego błędy przejściowe występują w chmurze?

Błędy przejściowe mogą wystąpić w dowolnym środowisku, na dowolnej platformie lub w systemie operacyjnym i w dowolnej 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 nadal mogą wystąpić błędy przejściowe, ponieważ mogą wystąpić awarie spowodowane nieprzewidzianymi zdarzeniami, takimi jak zewnętrzne problemy z zasilaniem lub siecią lub inne scenariusze awarii.

Hosting w chmurze, w tym prywatne systemy chmurowe, może oferować większą ogólną dostępność dzięki wykorzystaniu współużytkowanych zasobów, nadmiarowości, automatycznego przełączania awaryjnego oraz dynamicznej alokacji zasobów w wielu powszechnych 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 przepustowości pomaga zachować jakość usług dla sąsiadów i innych najemców, którzy korzystają z udostępnionego zasobu.

  • Środowiska chmurowe używają dużej liczby standardowych jednostek sprzętowych. Zapewniają one wydajność dzięki dynamicznej dystrybucji obciążenia między wieloma jednostkami obliczeniowymi i składnikami infrastruktury. Zapewniają one niezawodność przez automatyczne odtwarzanie 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ń.

Wyzwania

Błędy przejściowe mogą mieć duży wpływ na postrzeganą dostępność aplikacji, nawet jeśli zostały dokładnie przetestowane we wszystkich przewidywalnych 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, gdy wystąpią, i określić, czy błędy mogą być przejściowe, długotrwałe lub są błędami terminali. Różne zasoby mogą zwracać różne odpowiedzi w przypadku wystąpienia błędu, a odpowiedzi mogą się również różnić w zależności od kontekstu operacji. Na przykład odpowiedź na błąd podczas odczytywania aplikacji z magazynu może różnić się od odpowiedzi na błąd podczas zapisywania w magazynie. 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ść ponawiania próby wykonania operacji, jeśli ustali, że błąd prawdopodobnie będzie przejściowy. Musi również śledzić liczbę ponownych prób wykonania operacji.

  • Aplikacja musi używać odpowiedniej strategii do ponawiania prób. Strategia określa, ile razy aplikacja powinna ponowić próbę, opóźnienie między poszczególnymi próbami i akcje do wykonania po nieudanej próbie. Odpowiednia liczba prób i opóźnienie między nimi są często trudne do określenia. Strategia będzie się różnić w zależności od typu zasobu i bieżących warunków operacyjnych zasobu i aplikacji.

Ogólne wytyczne

Poniższe wskazówki mogą pomóc w projektowaniu odpowiednich mechanizmów obsługi błędów przejściowych dla aplikacji.

Określanie, czy istnieje 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 są zwykle dostosowane do charakteru i wymagań usługi docelowej. Alternatywnie interfejsy REST dla usług mogą zwracać informacje, które mogą pomóc określić, czy ponowienie próby jest odpowiednie i jak długo czekać przed następną próbą ponawiania.

  • Jeśli jest dostępny, należy użyć wbudowanego mechanizmu ponawiania prób, chyba że masz określone i zrozumiałe wymagania, które sprawiają, że inne zachowanie ponawiania prób będzie bardziej odpowiednie.

Ustal, czy operacja jest odpowiednia do ponawiania próby

  • Wykonaj operacje ponawiania tylko wtedy, gdy błędy są przejściowe (zwykle wskazywane przez charakter błędu) i gdy istnieje co najmniej pewne prawdopodobieństwo, że operacja powiedzie się po ponowieniu próby. 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 wywołujący kod zajmie się ponawianiem prób. Pamiętaj, że błędy zwracane z zasobów i usług spoza kontroli mogą ewoluować wraz z upływem czasu i może być konieczne ponowne przejrzenie logiki wykrywania błędów przejściowych.

  • 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 należy wskazać, czy klient powinien ponowić wykonanie operacji (na przykład przez zwrócenie wartości oznaczającej przejściowość) i zasugerować odpowiednie opóźnienie przed ponowną próbą. Jeśli tworzysz usługę internetową, rozważ zwrócenie błędów niestandardowych zdefiniowanych w kontraktach usług. Mimo że klienci ogólni mogą nie być w stanie odczytać tych błędów, są one przydatne przy tworzeniu niestandardowych klientów.

Określanie odpowiedniej liczby ponownych prób i interwału

  • Zoptymalizuj liczbę ponownych prób i interwał do typu przypadku użycia. Jeśli nie ponawiasz próby wystarczająco dużo razy, 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.

  • Dostosuj wartości interwału czasu i liczbę ponownych prób wykonania operacji. Jeśli na przykład operacja jest częścią interakcji użytkownika, interwał powinien być krótki i należy spróbować wykonać tylko kilka ponownych prób. 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 ograniczyć 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 interwałów między ponownymi próbami jest najtrudniejszą częścią projektowania udanej strategii. Typowe strategie używają następujących typów interwału ponawiania prób:

    • wykładniczy odstęp czasowy. Aplikacja czeka chwilę przed pierwszą ponowną próbą, a następnie wykładniczo zwiększa czas między poszczególnymi kolejnymi ponownymi próbami. Na przykład może ponowić próbę wykonania operacji po 3 sekundach, 12 sekundach, 30 sekundach itd.

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

    • Regularne odstępy. Aplikacja czeka przez ten sam okres między poszczególnymi próbami. 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 próby wykonania operacji jest właściwe, ponieważ może się to powieść, jeśli błąd zostanie wyczyszczony w czasie potrzebnym aplikacji do przygotowania i wysłania następnego żądania. Jednak nigdy nie powinno istnieć więcej niż jedna natychmiastowa próba ponawiania prób. Jeśli natychmiastowe ponowienie nie powiedzie się, należy przełączyć się na alternatywne strategie, takie jak wycofywanie wykładnicze lub rezerwowe akcje.

    • Randomizacja. Każda z wymienionych wcześniej strategii ponawiania może zawierać element losowości, aby zapobiec wysyłaniu przez wiele instancji klienta kolejnych prób 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 użyć strategii opóźnienia wykładniczego dla operacji w tle i używać strategii ponawiania natychmiastowego lub regularnego interwału dla operacji interakcyjnych. W obu przypadkach należy wybrać opóźnienie i liczbę ponownych prób, tak aby maksymalne opóźnienie dla wszystkich ponownych prób mieściło się w wymaganym wymaganiu dotyczącym całkowitego opóźnienia.

  • Uwzględnij kombinację wszystkich czynników, które przyczyniają się do ogólnego maksymalnego limitu czasu dla operacji ponawiania próby. Czynniki te obejmują czas, jaki upływa od awarii połączenia do uzyskania odpowiedzi (zazwyczaj ustawiany przez wartość limitu czasu w kliencie), opóźnienie między kolejnymi próbami ponownego połączenia oraz maksymalną liczbę tych prób. Suma wszystkich tych czasów może spowodować długie ogólne czasy operacji, zwłaszcza w przypadku użycia strategii opóźnienia wykładniczego, w której interwał między ponawianiami szybko rośnie po każdym niepowodzeniu. Jeśli proces musi spełniać określoną umowę dotyczącą poziomu usług (SLA), całkowity czas operacji, w tym wszystkie limity czasu i opóźnienia, musi mieścić się w granicach zdefiniowanych w umowie SLA.

  • Nie implementuj nadmiernie agresywnych strategii ponawiania prób. Są to strategie, które mają zbyt krótkie interwały lub ponowne próby, które są zbyt częste. Mogą one mieć negatywny wpływ na docelowy zasób lub usługę. Te strategie mogą uniemożliwić odzyskanie zasobu lub usługi ze stanu przeciążonego i będzie nadal blokować lub odrzucać żądania. Ten scenariusz powoduje błędne koło, w którym coraz więcej żądań jest wysyłanych do zasobu lub usługi. W związku z tym jego zdolność do regeneracji jest jeszcze bardziej ograniczona.

  • Weź pod uwagę limit czasu operacji przy wybieraniu interwałów powtórzeń, aby uniknąć natychmiastowego rozpoczęcia kolejnej próby (np. jeśli czas przekroczenia limitu jest zbliżony do interwału powtórzeń). 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 danych, które zawiera, lub kodów błędów i komunikatów zwróconych z usługi, aby zoptymalizować ilość ponownych prób oraz odstępy między nimi. Na przykład niektóre wyjątki lub kody błędów (takie jak kod HTTP 503, usługa niedostępna, z nagłówkiem Retry-After w odpowiedzi) mogą wskazywać, jak długo błąd może trwać lub czy usługa zakończyła się niepowodzeniem i nie odpowie na żadną kolejną próbę.

Unikaj antywzorców

  • W większości przypadków unikaj implementacji zawierających zduplikowane warstwy kodu ponawiania prób. 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 takich wyjątkowych okolicznościach należy używać zasad, które uniemożliwiają nadmierną liczbę ponownych prób i okresów opóźnień, i upewnij się, że rozumiesz konsekwencje. Załóżmy na przykład, że jeden składnik wysyła żądanie do innej, która następnie uzyskuje dostęp do usługi docelowej. Jeśli zastosujesz ponawianie trzy razy dla obu wywołań, w sumie będzie dziewięć prób ponownych względem usługi. Wiele usług i zasobów implementuje wbudowany mechanizm ponawiania prób. Należy zbadać, jak można wyłączyć lub zmodyfikować te mechanizmy, jeśli konieczne jest zaimplementowanie ponownych prób na wyższym poziomie.

  • Nigdy nie implementuj niekończącego się mechanizmu ponawiania prób. Może to zapobiec odzyskiwaniu zasobów lub usługi w sytuacjach przeciążenia oraz powodować ograniczanie przepustowości i odrzucanie połączeń przez dłuższy czas. Użyj skończonej liczby ponownych prób lub zaimplementuj wzorzec, taki jak wyłącznik, aby umożliwić usłudze powrót do działania.

  • Nigdy nie wykonuj natychmiastowych ponownych prób 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.

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

Testowanie strategii i implementacji ponawiania prób

  • W pełni przetestuj strategię ponawiania prób w możliwie najszerszym zakresie, szczególnie wtedy, gdy zarówno aplikacja, jak i docelowe zasoby lub usługi, których używa, są pod skrajnym obciążeniem. Aby sprawdzić zachowanie podczas testowania, możesz:

    • Wstrzykuj błędy przejściowe i nietransientne do usługi. Na przykład, wyślij nieprawidłowe żądania lub dodaj kod, który wykrywa żądania testowe i odpowiada różnymi typami błędów. Aby zapoznać się z przykładami korzystającymi z interfejsu TestApi, zobacz testowanie iniekcji błędów za pomocą TestApi i Introduction to TestApi — Part 5: Managed Code Fault Injection APIs.

    • Utwórz makietę zasobu lub usługi, która zwraca zakres błędów, które może zwrócić rzeczywista usługa. Uwzględnij wszystkie typy błędów, które strategia ponawiania prób została zaprojektowana do wykrywania.

    • Aby wymusić wystąpienie błędów przejściowych w tworzonych i wdrażanych usługach niestandardowych, tymczasowo wyłącz lub przeciąż usługę. (Nie próbuj przeciążać żadnych zasobów udostępnionych ani usług udostępnionych na platformie Azure).

    • W przypadku interfejsów API opartych na protokole HTTP rozważ użycie biblioteki w testach automatycznych, aby zmienić wynik żądań HTTP, dodając dodatkowe opóźnienia lub zmieniając odpowiedź (na przykład kod stanu HTTP, nagłówki, treść lub inne czynniki). Umożliwia to deterministyczne testowanie podzestawu warunków awarii w przypadku błędów przejściowych i innych typów błędów.

    • Przeprowadź testy współbieżności i wysokiego współczynnika obciążenia, aby upewnić się, że mechanizm ponawiania i strategia działają prawidłowo w takich warunkach. Te testy pomogą również zapewnić, że ponawianie próby nie ma negatywnego wpływu na działanie klienta ani nie powoduje zakłóceń między żądaniami.

Zarządzanie konfiguracjami zasad ponawiania prób

  • Polityka ponawiania to połączenie wszystkich elementów twojej strategii ponawiania. 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 konfiguracyjnych aplikacji. Odczytaj je w czasie wykonywania i zbuduj programowo 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.

  • W aplikacji azure Cloud Services rozważ przechowywanie wartości używanych do tworzenia zasad ponawiania w czasie wykonywania w pliku konfiguracji usługi, 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. Te strategie są zazwyczaj ogólne. W niektórych scenariuszach mogą one być potrzebne, ale w innych scenariuszach nie oferują one pełnego zakresu opcji odpowiadających konkretnym wymaganiom. Aby określić najbardziej odpowiednie wartości, należy przeprowadzić testowanie, aby zrozumieć, jak ustawienia wpływają na aplikację.

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

  • W ramach strategii ponawiania prób dołącz obsługę wyjątków i inną instrumentację, która rejestruje próby ponawiania prób. Sporadyczny błąd przejściowy i ponowienie próby są oczekiwane i nie wskazują problemu. Regularna i rosnąca liczba ponownych prób często jest jednak wskaźnikiem problemu, który może spowodować awarię lub obniżyć wydajność i dostępność aplikacji.

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

  • Rozważ zapisanie wartości w wpisach dziennika, które wskazują, czy ponawianie prób jest spowodowane ograniczaniem przepustowości w usłudze lub przez inne typy błędów, takich jak błędy połączeń, dzięki czemu można je rozróżnić 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.

  • Rozważ zaimplementowanie systemu telemetrii i monitorowania, który może zgłaszać alerty, gdy liczba i szybkość niepowodzeń, średnia liczba ponownych prób lub ogólny czas, który upłynął, zanim operacja zakończy się powodzeniem, rośnie.

Zarządzanie operacjami, które stale kończą się niepowodzeniem

  • Zastanów się, jak będziesz obsługiwać operacje, które nadal kończą się niepowodzeniem przy każdej próbie. Takie sytuacje 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ą trwale, strategia ponawiania prób może wykryć przekroczenie limitu czasu połączenia i uznać to 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 z długimi interwałami między żądaniami, aby wykryć, kiedy stanie się dostępna. Odpowiedni interwał zależy od czynników, takich jak krytyczność operacji i charakter usługi. Może to być coś od kilku minut do kilku godzin. Po pomyślnym zakończeniu testu aplikacja może wznowić normalne operacje i przekazać żądania do nowo odzyskanej 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 być odpowiednie przechowywanie żądań usługi w kolejce lub magazynie danych i ponawianie ich później. Możesz też przekierować użytkownika do alternatywnego wystąpienia aplikacji, zmniejszyć wydajność aplikacji, ale nadal zapewnić akceptowalną funkcjonalność, lub po prostu przekazać użytkownikowi komunikat, że aplikacja nie jest obecnie dostępna.

Inne zagadnienia

  • Podczas podejmowania decyzji o wartościach liczby ponownych prób oraz odstępów między nimi w ramach polityki, należy wziąć pod uwagę, czy operacja na usłudze lub zasobie stanowi część operacji długotrwałej lub 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.

  • Zastanów się, czy ponawianie próby wykonania tej samej operacji może spowodować niespójności w danych. Jeśli niektóre części procesu wieloetapowego są powtarzane, a operacje nie są 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.

  • Rozważ zakres operacji, które są ponawiane. Na przykład może być łatwiej zaimplementować kod ponawiania na poziomie obejmującym kilka operacji i ponowić próbę ich wszystkich, jeśli jeden zakończy się niepowodzeniem. Może to jednak prowadzić do problemów ze spójnością działań (idempotencji) lub niepotrzebnych operacji 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ółdzielą 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.