Перестаньте Атаковать Проблемную Зависимость: Паттерны Повторных Попыток для Azure Functions + Service Bus

Вот как восстанавливаемая ошибка превращается в отказ в приложении Functions: зависимость начинает давать таймаут, каждый экземпляр Functions немедленно и бесконечно повторяет попытки, зависимость получает сотни одновременных неудавшихся запросов, и то, что началось как временный сбой, превращается в событие противодавления во всей системе.

Вы, вероятно, знаете эту историю. Azure Functions масштабируется быстро — в этом весь смысл. Но “быстро масштабировать” и “немедленно повторять” вместе могут драматически ухудшить сбои.

Два паттерна помогают. Экспоненциальная задержка и автоматический выключатель. Оба теперь нативно поддерживаются для Azure Functions, запускаемых Service Bus.

Два Паттерна, Разные Роли

Эти паттерны дополняют друг друга, а не являются альтернативами:

Экспоненциальная задержка отвечает на вопрос: когда мне следует повторить попытку? Она увеличивает задержку между попытками, чтобы зависимость имела время восстановиться. На уровне сообщений, регулируя тайминг повторных попыток.

Автоматический выключатель отвечает на вопрос: следует ли мне вообще обращаться к этой зависимости прямо сейчас? Он останавливает повторные вызовы к нездоровой зависимости после достижения порогового значения ошибок, а затем осторожно проверяет после периода охлаждения. На системном уровне, предотвращая шторм повторных попыток.

Вам нужны оба. Задержка управляет темпом повторных попыток на уровне сообщений. Автоматический выключатель управляет агрегированными решениями о работоспособности.

Почему Это Особенно Важно для Service Bus

Очередь поглощает пиковый трафик, что хорошо. Но без контролей очередь может расти, пока воркеры продолжают тратить вычислительные ресурсы на вызовы, которые завершатся неудачей. Ядовитые сообщения остаются активными дольше, чем должны. Горячие партиции или ограниченная пропускная способность нижестоящей системы создают каскадные проблемы.

Более безопасный дизайн:

1. Обнаружить временный сбой
2. Задержать следующую попытку с экспоненциальной задержкой
3. Остановить вызовы к зависимости при достижении порогового значения ошибок (цепь разомкнута)
4. Осторожно возобновить после периода охлаждения (зондирование цепи)
5. Переместить невосстанавливаемую работу в dead-letter или путь карантина

Как Выглядит Нативная Поддержка

Новая поддержка интегрируется с существующей моделью хоста Azure Functions — без дополнительных библиотек, без пользовательских реализаций. Конфигурация помещается в ваш host.json:

{
  "extensions": {
    "serviceBus": {
      "messageHandlerOptions": {
        "maxRetryCount": 5,
        "retryPolicy": {
          "mode": "exponentialBackoff",
          "minBackoff": "00:00:02",
          "maxBackoff": "00:05:00",
          "maxRetryCount": 5
        }
      }
    }
  }
}

Конфигурация автоматического выключателя устанавливает порог ошибок и интервал сброса, чтобы нездоровые зависимости не атаковались во время восстановления.

Поддерживаемые Языки

Это не только для .NET. Функция охватывает dotnet, JavaScript, TypeScript и Python — полный набор языков, поддерживаемых триггером Service Bus в Azure Functions.

Заключение

Паттерны повторных попыток не интересно настраивать до первого раза, когда сбой в нижестоящей системе заставляет ваши Functions усугублять проблему вместо плавного ухудшения. Настраивать их проактивно недорого. Реализовывать их во время инцидента — нет.

Оригинальная статья: Exponential backoff and circuit breaker for Service Bus-triggered Azure Functions