Projektowanie pod kątem odporności
 Obciążenie musi nadal działać z pełną lub ograniczoną funkcjonalnością. |
|---|
Należy oczekiwać awarii składników, awarii platformy, obniżenia wydajności i innych błędów. Tworzenie odporności w systemie w taki sposób, aby była odporna na uszkodzenia i mogła bezpiecznie ulec pogorszeniu.
Przykładowy scenariusz
Contoso Air to komercyjna linia lotnicza, która ma dział rozwoju wewnętrznego. Główną aplikacją LOB jest rozwiązanie rezerwacji, które umożliwia klientom rezerwację lotów bezpośrednio z firmą Contoso Air. Aplikacja jest wbudowana na platformie Azure i korzysta z usług aplikacja systemu Azure Service, Cosmos DB, Azure Functions, Azure Logic Apps i Azure Service Bus.
Określanie ryzyka awarii.
Zidentyfikuj potencjalne punkty awarii w systemie, szczególnie w przypadku składników krytycznych, i określ wpływ na przepływy użytkowników i systemu.
Przeanalizuj przypadek awarii, promień wybuchu i intensywność błędu dla każdego potencjalnego punktu awarii. Przypadki awarii i ich intensywność mogą wahać się od stosunkowo niskich scenariuszy, takich jak tymczasowa utrata procesu zaplecza do w pełni skalowanych awarii wynikających z awarii. Wykonanie tej analizy ułatwia określenie projektu możliwości obsługi błędów na poziomie składnika.
Wyzwanie firmy Contoso
- Aplikacja LOB udostępnia wiele kluczowych funkcji, od marketingu przez handel. Przepływ użytkownika zakupu biletu został zidentyfikowany jako najbardziej krytyczny przepływ. Zespół ds. obciążeń ustalił, że należy zaimplementować więcej miar niezawodności w celu zapewnienia, że przepływ jest zoptymalizowany pod kątem odporności.
- Zespół ma czas przeznaczony na ulepszenia, takie jak oddzielenie składników i przeprojektowanie przepływów, ale chce mieć pewność, że używają tego czasu, aby skupić się na najwyższych ulepszeniach wartości.
Stosowanie podejścia i wyników
- Zespół identyfikuje zewnętrzną bramę płatności jako potencjalny punkt awarii. Brama jest wysoce dostępna, ale istnieje możliwość, że użytkownicy napotykają sporadyczne błędy przejściowe wynikające z problemów z siecią lub wybuchy bardzo wysokich żądań. Brama może odrzucać niektóre żądania, gdy jest przeciążona przez wiele równoczesnych żądań wysyłanych.
- Zespół określa, że użytkownicy muszą ponownie przesyłać żądania, gdy ich początkowe żądania są odrzucane przez bramę, co powoduje negatywne środowisko użytkownika.
Implementowanie mechanizmów samozachowawczych
Twórz możliwości samodzielnego zachowywania przy użyciu wzorców projektowych poprawnie i modułowo, aby odizolować błędy.
Tworząc możliwości samodzielnego zachowywania w systemie, będzie można zapobiec problemowi wpływającemu na składniki podrzędne. System będzie mógł ograniczyć przejściowe i trwałe awarie, wąskie gardła wydajności i inne problemy, które mogą mieć wpływ na niezawodność. Będzie można również zminimalizować promień wybuchu.
Wyzwanie firmy Contoso
- Zespół chce zminimalizować ryzyko przejściowych niepowodzeń powodujących odrzucenie żądań użytkowników przez bramę płatności. Ze względu na przejściowy charakter niektórych warunków błędu istnieje duże prawdopodobieństwo, że to samo żądanie powiedzie się po ponownym przesłaniu.
Stosowanie podejścia i wyników
- Zespół opracowuje niestandardową logikę w przepływie, aby ponowić próbę transakcji po krótkim opóźnieniu, gdy zostanie wykryta awaria, którą można ponowić.
- Projekt rozwiązania zostanie zmodyfikowany w celu włączenia wzorca ponawiania prób, nieznacznie zwiększając czas oczekiwania między ponownymi próbami do momentu pomyślnego przetworzenia żądania lub osiągnięcia maksymalnej liczby niepowodzeń.
- Zespół decyduje się również na oddzielenie interakcji użytkownika i funkcji przetwarzania płatności zaplecza tego przepływu przy użyciu podejścia opartego na zdarzeniach w usłudze Azure Service Bus. W przypadku wystąpienia nieodwracalnych awarii podczas przetwarzania komunikatu (po maksymalnej liczbie ponownych prób) procesor zaplecza porzuca przetwarzanie tego żądania, pozostawiając komunikat w kolejce, aby można było go ponownie przetworzyć w późniejszym czasie.
Tworzenie kompleksowej nadmiarowości i odporności
Tworzenie nadmiarowości w warstwach i odporności na różnych warstwach aplikacji.
Celem jest nadmiarowość w narzędziach fizycznych i natychmiastowej replikacji danych. Celem jest również nadmiarowość w warstwie funkcjonalnej, która obejmuje usługi, operacje i personel. Nadmiarowość pomaga zminimalizować pojedyncze punkty awarii. Jeśli na przykład wystąpi awaria wpływająca na co najmniej jeden składnik, strefę dostępności lub cały region, nadmiarowe (aktywne lub aktywne-pasywne) wdrożenie umożliwia spełnienie celów czasu pracy.
Dodawanie pośredników uniemożliwia bezpośrednią zależność między składnikami i poprawia buforowanie. Obie te korzyści wzmacniają odporność systemu.
Wyzwanie firmy Contoso
- Zaimplementowanie ponownych prób i oddzielenie wywołań bramy płatności z interfejsu użytkownika przy użyciu usługi Service Bus znacznie zwiększyło niezawodność tego przepływu, ale uczestnicy projektu biznesowego nadal martwią się o utratę danych, która może wystąpić z powodu katastrofalnej awarii w regionie podstawowym.
Stosowanie podejścia i wyników
- Zespół decyduje się na uaktualnienie do warstwy Premium usługi Service Bus. Dzięki temu mogą korzystać z funkcji obsługi Strefy dostępności tej warstwy. Dzięki tej funkcji wiele kopii danych jest przechowywanych w trzech fizycznie oddzielonych obiektach (strefach dostępności), a usługa ma wystarczającą ilość rezerw pojemności, aby natychmiast poradzić sobie z pełną, katastrofalną utratą centrum danych.
- Ponadto zespół konfiguruje odzyskiwanie geograficzne usługi Azure Service Bus po awarii, aby stale replikować dane do regionu pomocniczego, który będzie używany w mało prawdopodobnym przypadku całkowitej awarii regionu podstawowego.