Azure Fundamentals · Урок

Проверки работоспособности и плавная деградация

«Проверки работоспособности и плавная деградация» — бесплатный урок Azure Fundamentals на CoddyKit. Это урок 4 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения Azure Fundamentals, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс Azure Fundamentals содержит 4 уроков всего.

Почему пробы работоспособности необходимы

Пробы работоспособности — это механизм, с помощью которого балансировщики нагрузки и диспетчеры трафика определяют, способна ли серверная копия обрабатывать запросы. Без проб работоспособности балансировщик нагрузки может продолжать отправлять трафик на неисправный сервер или сервер, который не отвечает, что приводит к ошибкам, видимым пользователям. Правильно настроенные пробы работоспособности обеспечивают автоматическую перенаправление трафика от неисправных копий в течение нескольких секунд после сбоя.

Пробы работоспособности Azure Load Balancer

Azure Load Balancer поддерживает два типа проб работоспособности:

Проба TCP — проверяет, может ли серверная часть принять соединение TCP через указанный порт. Это простой способ проверки, который не проверяет логику приложения.
Проба HTTP/HTTPS — отправляет запрос GET по указанному пути и ожидает ответ 200 OK. Этот способ точнее, поскольку напрямую проверяет конечную точку приложения.

Серверная часть помечается как неисправная, если проба завершается ошибкой заданное число раз подряд.

# 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

Проектирование надёжной конечной точки работоспособности

Хорошо спроектированная конечная точка работоспособности (/health) не просто возвращает 200 OK — она проверяет доступность критически важных зависимостей приложения. Полная проверка работоспособности может включать проверку подключения к базе данных, кэшу и всем последующим API. Если какая-либо зависимость недоступна, конечная точка возвращает код состояния 5xx, сообщая балансировщику нагрузки, что эту копию необходимо исключить из распределения.

# 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

Пробы работоспособности Traffic Manager

Azure Traffic Manager также использует пробы работоспособности, но на уровне региона. Он периодически отправляет запросы GET по HTTP или HTTPS к настроенному URL конечной точки в каждом регионе. Если конечная точка не отвечает в течение интервала ожидания заданное число последовательных интервалов, Traffic Manager помечает её как работающую с ухудшением характеристик и прекращает направлять к ней запросы DNS, перенаправляя пользователей в работоспособный регион.

# 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

Пробы работоспособности Application Gateway

Azure Application Gateway предоставляет более широкие возможности проб работоспособности, чем стандартный Load Balancer. Он поддерживает настраиваемые пробы, в которых можно указать заголовок узла, ожидаемый диапазон кодов состояния (например, 200–399) и строку для сопоставления с содержимым ответа. Application Gateway также поддерживает маршрутизацию по путям, поэтому для разных пулов серверной части можно настроить отдельные пробы работоспособности для разных путей 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

Что такое плавное снижение функциональности

Плавное снижение функциональности — это способность приложения продолжать предоставлять часть функций при отказе одной или нескольких зависимостей. Вместо полного сбоя приложение обнаруживает недоступность некритичной службы и переходит в ограниченный, но всё ещё полезный режим. Например, если служба рекомендаций выйдет из строя, сайт электронной торговли может показать общие рекомендации вместо полного сбоя страницы товара.

Шаблон Circuit Breaker

Шаблон размыкателя цепи предотвращает многократные вызовы приложением неисправной зависимой службы. Когда служба начинает работать с ошибками, размыкатель цепи размыкается и немедленно возвращает ошибку или резервный ответ, не выполняя сетевой вызов. После периода ожидания он переходит в состояние частично разомкнутой цепи и пропускает пробный запрос. Если запрос завершается успешно, цепь замыкается и возобновляется обычная работа.

# 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)

Повторная попытка с Exponential-задержкой

Для временных сбоев (кратковременных перебоев в сети, временной перегрузки службы) подходит стратегия повторной попытки с экспоненциальным увеличением задержки. Приложение повторяет неудачный вызов после задержки, удваивая её после каждой попытки до достижения максимального значения. Добавление jitter (случайного изменения) задержки предотвращает синхронизацию всех повторных попыток и перегрузку восстанавливающейся службы.

# 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

Шаблон изолированных переборок

Шаблон изолированных переборок разделяет разные части приложения на пулы ресурсов, чтобы сбой в одной области не использовал все ресурсы и не вывел из строя всю систему. Название происходит от переборок на кораблях, которые не дают затоплению одного отсека привести к затоплению всего судна. В Azure это может означать использование отдельных пулов потоков или отдельных планов службы приложений для разных служб, чтобы локализовать сбои.

Резервные ответы и кэшированные данные

Распространённый способ плавного ухудшения работы — предоставлять кэшированные или устаревшие данные, когда источник актуальных данных недоступен. Например, страница каталога товаров может показывать вчерашние кэшированные цены из Azure Cache for Redis, вместо того чтобы отображать ошибку при временной недоступности базы данных. Пользователь сталкивается с небольшим неудобством (слегка устаревшими ценами), а не с полным отказом.

Мониторинг и оповещения об ухудшении работы

Плавное ухудшение работы должно быть видимым и измеримым. Используйте Application Insights, чтобы отслеживать в качестве пользовательских метрик частоту размыкания цепи, резервных ответов и повторных попыток. Настройте оповещения при превышении этими метриками пороговых значений, чтобы дежурная команда узнала о работе приложения в ограниченном режиме, даже если пользовательский интерфейс кажется приемлемым.

Быстрая проверка

Проверьте своё понимание концепций Microsoft Azure Fundamentals (AZ-900) из этого урока.

Итоги урока

В этом уроке Вы узнали, что проверки работоспособности позволяют балансировщикам нагрузки обнаруживать неисправные внутренние серверы и автоматически перенаправлять трафик; плавное ухудшение работы сохраняет частичную работоспособность приложений при сбоях зависимостей; а такие шаблоны, как размыкатель цепи, повторная попытка с увеличением задержки и изолированные переборки, обеспечивают устойчивость на уровне приложения. Далее мы рассмотрим концепции аварийного восстановления — определение RTO, RPO и уровней восстановления.

Часто задаваемые вопросы

Урок «Проверки работоспособности и плавная деградация» бесплатный?

Да — полный текст урока «Проверки работоспособности и плавная деградация» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс Azure Fundamentals, подпишись на CoddyKit PRO. Курс Azure Fundamentals содержит 4 уроков всего.

Чему я научусь в уроке «Проверки работоспособности и плавная деградация»?

Настройте проверки работоспособности балансировщика нагрузки и Traffic Manager для быстрого обнаружения сбоев и разработайте шаблоны автоматического размыкателя и плавной деградации для уровня прилож… Ты практикуешь Azure Fundamentals с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.

Нужен ли мне опыт, чтобы начать Azure Fundamentals?

Предыдущий опыт не требуется. Azure Fundamentals на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 4 из 4.

Сколько времени занимает урок «Проверки работоспособности и плавная деградация»?

Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.

Можно ли писать и запускать код в этом уроке Azure Fundamentals?

Да. Каждый урок Azure Fundamentals включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.

Все уроки этого курса

SLA Azure и составные SLA
Наборы доступности и зоны доступности
Мульти региональная активная активная архитектура
Проверки работоспособности и плавная деградация

← Назад к Azure Fundamentals