Ćwiczenie — dodawanie kontroli kondycji aplikacji internetowej

  • 30 min

Firma Contoso Shoes potrzebuje sposobu sprawdzania kondycji aplikacji internetowej na poziomie interfejsu API, a także jej zależności. Chcesz zaimplementować dedykowany punkt końcowy kontroli kondycji w aplikacji, który raportuje stan kondycji interfejsu API w regularnych odstępach czasu.

Bieżący stan i problem

W bieżącym projekcie aplikacja rejestruje błędy, gdy występują problemy ze środowiskiem uruchomieniowym w kodzie interfejsu API lub wywołania usług zależnych kończą się niepowodzeniem, takimi jak nieudane zapytania bazy danych. Takie podejście jest przydatne podczas rozwiązywania problemów po wystąpieniu zdarzenia.

Jednak podejście nie jest proaktywne. aplikacja systemu Azure Service i narzędzia do monitorowania zewnętrznego nie mają możliwości sprawdzenia stanu kondycji samej aplikacji. Ta luka ma wpływ na wiele przypadków użycia, takich jak rozkład obciążenia. Bieżąca implementacja opiera się wyłącznie na najlepszym wysiłku planu usługi App Service w celu równomiernego dystrybuowania ruchu między wystąpieniami bez sprawdzania kondycji aplikacji. W jednym zgłoszonym zdarzeniu ruch był kierowany do wystąpień usługi App Service w złej kondycji, co spowodowało niepowodzenie żądań.

Specyfikacja

Twoim zadaniem jest skompilowanie dedykowanej usługi kondycji jako rozszerzenia do już wdrożonego kodu.

  • Wprowadzenie do interfejsu API sprawdzania kondycji w aplikacji. Interfejs API musi sprawdzić stan kondycji aplikacji i jego zależności oraz zwrócić wskazanie stanu. Na przykład interfejs API okresowo powinien sprawdzać operacje odczytu i zapisu w usłudze Azure Cosmos DB. Zaimplementuj te funkcje jako oddzielne sondy, aby operacje odczytu i zapisu były sprawdzane niezależnie.

    Napiwek

    Rozszerz kontrolę kondycji na usługi niefunkcjonalne, takie jak Azure Key Vault i Azure Container Registry. Ten krok jest ważny, ponieważ w przypadku wystąpienia awarii tych usług może wystąpić wpływ na możliwość skalowania w poziomie lub wytrzymania ponownego uruchomienia wystąpienia usługi App Service.

  • Punkt końcowy interfejsu API sprawdzania kondycji jest często wywoływany przez wiele źródeł i nie powinien obniżać wydajności interfejsu API. Na przykład plan usługi aplikacja systemu Azure service musi wysyłać żądania do punktu końcowego dwa razy na minutę i podejmować świadome decyzje dotyczące tego, do których wystąpień usługi App Service dystrybuować ruch.

  • Zoptymalizuj wydajność interfejsu API sprawdzania kondycji, buforując wyniki w pamięci przez 10 sekund. Nie każde zapytanie do punktu końcowego sprawdzania kondycji powinno spowodować wywołanie zaplecza. Niektóre z tych odpowiedzi można obsłużyć z pamięci podręcznej.

  • Udostępnianie danych kontroli kondycji w usłudze Azure Monitor na potrzeby przyszłej analizy.

Aby rozpocząć projektowanie, zalecamy następujące podejście:

1 — Kontrole kondycji

Wszystkie zapytania wysyłane przez interfejs API sprawdzania kondycji muszą być wykonywane asynchronicznie i równolegle. Projektowanie kontroli kondycji pod kątem krytycznych składników, takich jak baza danych. Interfejs API powinien okresowo sprawdzać operacje odczytu i zapisu. Zaimplementuj te funkcje jako oddzielne sondy, aby operacje odczytu i zapisu były sprawdzane niezależnie.

Używaj żądań, które naśladują rzeczywiste zachowanie aplikacji bez zbyt dużego obciążenia usług tylko z sond kondycji. Aby również przetestować żądania zapisu, należy zaprojektować sposób efektywnego usuwania danych testowych, aby nie mieszać się z rzeczywistymi danymi użytkownika.

Wzorzec buforowania 2

Aby uniknąć przeciążenia usług podrzędnych za pomocą kontroli kondycji, interfejs API sprawdzania kondycji powinien buforować wyniki dla konfigurowalnej liczby sekund. Pomyśl o możliwych sposobach osiągnięcia tego celu.

Sprawdź swoją pracę

Oto przykład Usługa kondycji aplikacji. Czy wszystkie aspekty zostały omówione w projekcie?

  • Czy punkt końcowy kontroli kondycji jest zgodny z funkcją sprawdzania kondycji usługi aplikacja systemu Azure?
  • Czy zostały uwzględnione testy zależności środowiska uruchomieniowego? Czego użyto jako serwera proxy/testu?
    • Odczyt/zapis w usłudze Cosmos DB
    • Interfejs API innej firmy
  • Czy buforujesz wyniki sprawdzania kondycji w celu zmniejszenia obciążenia związanego z wydajnością?
  • Czy zdarzenia zostały rejestrowane w kontrolach kondycji? Zanotuj sukcesy i porażki?
  • Czy zastosowano próbkowanie dzienników aplikacja systemu Azure Insights do dzienników kontroli kondycji?