0Pricing
Cloud & IT Cert Prep · Lekcja

Sondy kondycji i kontrolowana degradacja

Proszę skonfigurować sondy kondycji modułu równoważenia obciążenia i Traffic Managera, aby szybko wykrywać awarie, oraz zaprojektować wzorce circuit breaker i kontrolowanej degradacji dla warstwy aplikacji.

Sondy kondycji i kontrolowana degradacja to bezpłatna lekcja Cloud & IT Cert Prep na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Cloud & IT Cert Prep, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Cloud & IT Cert Prep zawiera 4 lekcji w sumie.

Dlaczego sondy kondycji są niezbędne

Sondy kondycji to mechanizm, za pomocą którego moduły równoważenia obciążenia i menedżery ruchu wykrywają, czy instancja zaplecza może obsługiwać żądania. Bez sond kondycji moduł równoważenia obciążenia może nadal wysyłać ruch do uszkodzonego lub nieodpowiadającego serwera, powodując błędy widoczne dla użytkowników. Prawidłowo skonfigurowane sondy kondycji umożliwiają automatyczne przekierowanie ruchu z dala od niesprawnych instancji w ciągu kilku sekund od wystąpienia awarii.

Sondy kondycji Azure Load Balancer

Azure Load Balancer obsługuje dwa typy sond kondycji:

  • Sonda TCP — sprawdza, czy zaplecze może zaakceptować połączenie TCP na określonym porcie. Jest prosta, ale nie weryfikuje logiki aplikacji.
  • Sonda HTTP/HTTPS — wysyła żądanie GET do określonej ścieżki i oczekuje odpowiedzi 200 OK. Jest dokładniejsza, ponieważ bezpośrednio testuje punkt końcowy aplikacji.

Zaplecze jest oznaczane jako niesprawne, jeśli sonda zakończy się niepowodzeniem określoną konfigurowalną liczbę razy z rzędu.

# Create an HTTP health probe for an Azure Load Balancer:
az network lb probe create \
  --resource-group myRG \
  --lb-name myLoadBalancer \
  --name httpHealthProbe \
  --protocol Http \
  --port 80 \
  --path /health \
  --interval 15 \
  --threshold 2

Projektowanie niezawodnego punktu końcowego kondycji

Dobrze zaprojektowany punkt końcowy kondycji (/health) robi więcej niż tylko zwraca 200 OK — sprawdza, czy można uzyskać dostęp do krytycznych zależności aplikacji. Kompleksowa kontrola kondycji może testować połączenie z bazą danych, pamięcią podręczną i dowolnymi interfejsami API usług podrzędnych. Jeśli dowolna zależność jest niedostępna, punkt końcowy zwraca kod stanu 5xx, sygnalizując modułowi równoważenia obciążenia, aby usunął tę instancję z puli.

# Example health endpoint response (JSON):
# GET /health
# {
#   'status': 'healthy',
#   'checks': {
#     'database': 'ok',
#     'cache': 'ok',
#     'externalApi': 'ok'
#   }
# }
# If database check fails, return HTTP 503 instead of 200

Sondy kondycji Traffic Manager

Azure Traffic Manager również używa sond kondycji, ale na poziomie regionu. Wysyła okresowe żądania GET HTTP lub HTTPS do skonfigurowanego adresu URL punktu końcowego w każdym regionie. Jeśli punkt końcowy nie odpowie w wyznaczonym oknie limitu czasu przez określoną liczbę kolejnych interwałów, Traffic Manager oznacza go jako zdegradowany i przestaje kierować do niego zapytania DNS, przekierowując użytkowników do sprawnego regionu.

# Configure Traffic Manager health probe settings:
az network traffic-manager profile update \
  --resource-group myRG \
  --name myTMProfile \
  --monitor-protocol HTTPS \
  --monitor-port 443 \
  --monitor-path /health \
  --monitor-interval 30 \
  --monitor-timeout 10 \
  --monitor-tolerated-failures 3

Sondy kondycji Application Gateway

Azure Application Gateway oferuje bardziej zaawansowane możliwości sond kondycji niż standardowy moduł Load Balancer. Obsługuje sondy niestandardowe, w których można określić nagłówek hosta, oczekiwany zakres kodów stanu (np. 200-399) oraz ciąg znaków do dopasowania w treści. Application Gateway obsługuje także routing według ścieżki, dzięki czemu różne pule zaplecza mogą mieć różne konfiguracje sond kondycji dla różnych ścieżek URL.

# Create a custom probe for Application Gateway:
az network application-gateway probe create \
  --gateway-name myAppGateway \
  --resource-group myRG \
  --name customProbe \
  --protocol Http \
  --host-name-from-http-settings true \
  --path /api/health \
  --interval 20 \
  --timeout 10 \
  --threshold 3

Czym jest kontrolowane ograniczanie funkcjonalności

Kontrolowane ograniczanie funkcjonalności to zdolność aplikacji do dalszego udostępniania części funkcji, gdy jedna lub więcej jej zależności ulegnie awarii. Zamiast całkowicie się zawiesić, aplikacja wykrywa niedostępność niekrytycznej usługi i przechodzi do ograniczonego, ale nadal użytecznego trybu działania. Jeśli na przykład usługa rekomendacji ulegnie awarii, witryna e-commerce może wyświetlić ogólne sugestie zamiast powodować awarię całej strony produktu.

Wzorzec circuit breaker

Wzorzec circuit breaker zapobiega wielokrotnemu wywoływaniu przez aplikację usługi zależnej, która uległa awarii. Gdy usługa zaczyna zawodzić, circuit breaker otwiera się i natychmiast zwraca błąd lub odpowiedź zastępczą, nie wykonując wywołania sieciowego. Po upływie czasu oczekiwania przechodzi do stanu połowicznego otwarcia i zezwala na próbne żądanie. Jeśli zakończy się ono powodzeniem, obwód zostaje zamknięty, a normalne działanie wznowione.

# Circuit breaker states:
# CLOSED: normal operation, calls pass through
# OPEN:   service failing, calls immediately return error/fallback
# HALF-OPEN: cool-down expired, try one request:
#           success -> CLOSED
#           failure -> OPEN (reset timer)

# Libraries: Polly (.NET), Resilience4j (Java), polly-js (JS)

Ponawianie prób z wykładniczym zwiększaniem opóźnienia

W przypadku przejściowych awarii (krótkotrwałych problemów z siecią lub tymczasowego przeciążenia usługi) odpowiednią strategią jest ponawianie prób z wykładniczym zwiększaniem opóźnienia. Aplikacja ponawia nieudane wywołanie po opóźnieniu, które przy każdej kolejnej próbie jest dwukrotnie większe, aż do osiągnięcia maksimum. Dodanie do opóźnienia elementu jitter (losowej zmienności) zapobiega synchronizacji wszystkich prób i przeciążeniu odzyskującej sprawność usługi.

# Exponential backoff with jitter (pseudocode):
# attempt 1: wait 1s  + random(0-500ms)
# attempt 2: wait 2s  + random(0-500ms)
# attempt 3: wait 4s  + random(0-500ms)
# attempt 4: wait 8s  + random(0-500ms)
# max retries: 4
# max wait: 30s (cap)
# After max retries: return error to caller

Wzorzec bulkhead

Wzorzec bulkhead izoluje różne części aplikacji w oddzielnych pulach zasobów, dzięki czemu awaria w jednym obszarze nie zużywa wszystkich zasobów i nie powoduje awarii całego systemu. Nazwa pochodzi od grodzi na statkach, które zapobiegają zatonięciu całej jednostki po zalaniu jednego przedziału. Na platformie Azure może to oznaczać użycie oddzielnych puli wątków lub oddzielnych planów App Service dla różnych usług, aby ograniczyć skutki awarii.

Odpowiedzi zastępcze i dane w pamięci podręcznej

Typową techniką płynnego obniżania funkcjonalności jest udostępnianie danych z pamięci podręcznej lub nieaktualnych danych, gdy źródło danych na żywo jest niedostępne. Na przykład strona katalogu produktów może wyświetlić wczorajsze ceny z pamięci podręcznej Azure Cache for Redis, zamiast pokazywać błąd, jeśli baza danych jest tymczasowo nieosiągalna. Użytkownik doświadcza niewielkiej niedogodności (nieco nieaktualnych cen), a nie całkowitej awarii.

Monitorowanie i alerty dotyczące obniżenia funkcjonalności

Płynne obniżanie funkcjonalności powinno być widoczne i mierzalne. Użyj usługi Application Insights, aby śledzić jako metryki niestandardowe częstotliwość otwierania circuit breakerów, odpowiedzi zastępczych i ponawiania prób. Skonfiguruj alerty, gdy te metryki przekroczą wartości progowe, aby zespół dyżurny otrzymał powiadomienie, że aplikacja działa w trybie ograniczonej funkcjonalności, nawet jeśli działanie widoczne dla użytkownika wydaje się prawidłowe.

Szybki test

Sprawdź swoją wiedzę na temat zagadnień Microsoft Azure Fundamentals (AZ-900) omówionych w tej lekcji.

Podsumowanie lekcji

W tej lekcji poznali Państwo następujące zagadnienia: sondy kondycji pozwalają modułom równoważenia obciążenia wykrywać uszkodzone backendy i automatycznie przekierowywać ruch; płynne obniżanie funkcjonalności pozwala aplikacjom zachować częściową funkcjonalność w przypadku awarii zależności; a wzorce takie jak circuit breaker, ponawianie prób z opóźnieniem i bulkhead zapewniają odporność na poziomie aplikacji. W następnej części omówimy zagadnienia odzyskiwania po awarii — definiowanie RTO, RPO i poziomów odzyskiwania.

Często zadawane pytania

Czy lekcja „Sondy kondycji i kontrolowana degradacja” jest bezpłatna?

Tak — pełny tekst „Sondy kondycji i kontrolowana degradacja” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Cloud & IT Cert Prep, przejdź na CoddyKit PRO. Kurs Cloud & IT Cert Prep zawiera 4 lekcji w sumie.

Co nauczysz się w „Sondy kondycji i kontrolowana degradacja”?

Proszę skonfigurować sondy kondycji modułu równoważenia obciążenia i Traffic Managera, aby szybko wykrywać awarie, oraz zaprojektować wzorce circuit breaker i kontrolowanej degradacji dla warstwy apl… Ćwiczysz Cloud & IT Cert Prep z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Cloud & IT Cert Prep?

Nie wymagamy żadnego doświadczenia. Cloud & IT Cert Prep w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.

Ile czasu zajmuje lekcja „Sondy kondycji i kontrolowana degradacja”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Cloud & IT Cert Prep?

Tak. Każda lekcja Cloud & IT Cert Prep zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Umowy SLA Azure i złożone umowy SLA
  2. Zestawy dostępności i strefy dostępności
  3. Architektura active-active w wielu regionach
  4. Sondy kondycji i kontrolowana degradacja
← Powrót do Cloud & IT Cert Prep