Obsługa błędu przejściowego

  • Artykuł

Wszystkie aplikacje, które komunikują się ze zdalnymi usługami 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. Aby uzyskać informacje na temat obsługi błędów przejściowych podczas korzystania z usług platformy Azure, zobacz Wskazówki dotyczące ponawiania prób dla usług platformy Azure.

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

Błędy przejściowe mogą występować w każdym środowisku, na każdej platformie, w każdym systemie operacyjnym i w każdego rodzaju 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 systemy chmury prywatnej, może oferować większą ogólną dostępność przy użyciu zasobów udostępnionych, nadmiarowości, automatycznego trybu failover i dynamicznej alokacji zasobów w wielu towarów węzłach obliczeniowych. Jednak ze względu na charakter środowisk w chmurze błędy przejściowe są bardziej prawdopodobne. Wynika to z kilku przyczyn:

  • 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 dzierżaw, które korzystają z udostępnionego zasobu.

  • Środowiska w chmurze używają dużej liczby towarów 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 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 powodować dalsze opóźnienia 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 wskazówki

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 oferuje zestaw SDK lub bibliotekę klienta z mechanizmem obsługi błędów przejściowych. Używane zasady ponawiania są zwykle dostosowane do charakteru oraz wymagań docelowej usługi. 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łanie kodu implementuje ponawianie 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 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. Jeśli tworzysz usługę internetową, rozważ zwrócenie błędów niestandardowych zdefiniowanych w kontraktach usług. Mimo że klienci ogólną mogą nie być w stanie odczytać tych błędów, są one przydatne podczas tworzenia 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ąć oczekiwania użytkowników na odpowiedź, która przechowuje otwarte połączenia i może zmniejszyć 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 wykorzystują następujące rodzaje interwałów ponawiania prób:

    • Wycofywanie wykładnicze. 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.

    • Interwały regularne. Aplikacja oczekuje stały odstęp czasu między kolejnymi próbami. Na przykład może ponowić próbę wykonania operacji co 3 sekundy.

    • Natychmiastowe ponowienie 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 ponawianie próby wykonania operacji natychmiast jest odpowiednie, ponieważ może się to powieść, jeśli błąd zostanie wyczyszczone w czasie potrzebnym aplikacji do złożenia 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.

    • Generowanie losowe. Każda z wymienionych wcześniej strategii ponawiania może zawierać losowe generowanie, aby zapobiec wysyłaniu kolejnych prób przez klienta w tym samym czasie wielu wystąpień. 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 wycofywania wykładniczego dla operacji w tle i używać strategii ponawiania natychmiastowego lub regularnego interwału dla operacji interakcyjnych. W obydwu przypadkach należy wybrać opóźnienie i liczbę ponownych prób, tak aby wartość maksymalnego oczekiwania dla wszystkich ponawianych prób kształtowała się w zakresie wymagań dotyczących opóźnień dla połączeń typu end-to-end.

  • 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 potrzebny na utworzenie odpowiedzi (zazwyczaj przez wartość limitu czasu w kliencie), opóźnienie między ponownymi próbami i maksymalną liczbą ponownych 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 odzyskania jest jeszcze bardziej ograniczona.

  • Weź pod uwagę limit czasu operacji po wybraniu interwałów ponawiania prób, aby uniknąć natychmiastowego uruchomienia kolejnej próby (na przykład jeśli okres przekroczenia limitu czasu jest podobny do interwału ponawiania). 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 interwał między nimi. Na przykład niektóre wyjątki lub kody błędów (na przykład kod HTTP 503, usługa niedostępna z nagłówkiem Po ponowieniu próby w odpowiedzi) mogą wskazywać, jak długo błąd może trwać lub czy usługa nie odpowie na kolejną próbę.

Unikaj antywłaściwych wzorcó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 tego typu wyjątkowych okolicznościach używaj zasad, które uniemożliwiają stosowanie nadmiernej liczby ponownych prób i zbyt długich czasów opóźnienia oraz 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. W przypadku implementacji ponawiania próby z liczbą trzech dla obu wywołań istnieje dziewięć prób ponawiania próby w sumie 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 mechanizmu nieskończonego 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 odzyskiwanie.

  • Nigdy nie przeprowadzaj natychmiastowego ponawiania 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 wysyłaniu ponownych prób jednocześnie przez wiele wystąpień tego samego klienta lub wielu wystąpień 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 w trakcie testów:

    • Wstrzykuj błędy przejściowe i nietransientne do usługi. Na przykład wyślij nieprawidłowe żądania lub dodaj kod, który wykryje testowe żądania i odpowie za pomocą różnego typu błędów. Aby zapoznać się z przykładami korzystającymi z interfejsu TestApi, zobacz Testowanie iniekcji błędów za pomocą interfejsu TestApi i Wprowadzenie do interfejsu TestApi — część 5: interfejsy API iniekcji błędów zarządzanych.

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

    • W przypadku usług niestandardowych tworzonych i wdrażanych wymuś błędy przejściowe, tymczasowo wyłączając lub przeciążając 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 dodatkowy czas rundy 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 o wysokim obciążeniu i współbieżnych, aby upewnić się, że mechanizm ponawiania i strategia działają prawidłowo w tych warunkach. Testy te pomogą również zapewnić, że ponawianie próby nie ma negatywnego wpływu na działanie klienta lub spowoduje skażenie krzyżowe między żądaniami.

Zarządzanie konfiguracjami zasad ponawiania prób

  • Zasady ponawiania prób to kombinacja wszystkich elementów strategii ponawiania prób. 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, odczytują je w czasie wykonywania i programowo kompilują 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 dostępności stanowi często wskaźnik wad projektowych aplikacji lub potrzeby przejścia na usługę premium oferującą 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. Jeśli na przykład usługa przetwarzania zamówień zakończy się niepowodzeniem z powodu błędu krytycznego, który trwale nie działa, strategia ponawiania prób może wykryć przekroczenie limitu czasu połączenia i rozważyć, że jest to 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 wyłącznika. 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, obniżyć wydajność aplikacji, ale nadal oferować akceptowalne funkcje lub po prostu zwrócić komunikat do użytkownika, aby wskazać, że aplikacja nie jest obecnie dostępna.

Inne uwagi

  • Podczas podejmowania decyzji o wartościach liczby ponownych prób i interwałów ponawiania prób dla zasad należy wziąć pod uwagę, czy operacja na usłudze lub zasobie jest częścią długotrwałej lub wieloetapowej operacji. 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 spowodować problemy z idempotencją lub niepotrzebne operacje 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 prób mogą powodować wzrost liczby błędów przejściowych dla tych innych użytkowników oraz dla 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.