Как работает circuit breaker и зачем он нужен в микросервисах

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

Чтобы этого избежать, используют паттерн circuit breaker (предохранитель).

Базовая идея

Circuit breaker работает как электрический предохранитель:

• если всё работает нормально → запросы проходят
• если сервис начинает падать → соединение «размыкается»
• система перестаёт слать запросы в проблемный сервис

Это защищает систему от перегрузки и каскадных отказов.

Состояния circuit breaker

У circuit breaker есть три основных состояния.

1. Closed (закрыт)

• все запросы проходят
• система отслеживает ошибки

Если ошибок становится слишком много → переход в Open.

2. Open (разомкнут)

• запросы к сервису не отправляются
• сразу возвращается ошибка или fallback

Система «даёт сервису отдохнуть».

3. Half-Open (полуоткрыт)

• пропускается небольшое количество запросов
• если они успешны → возвращаемся в Closed
• если нет → снова Open

Это позволяет проверить, восстановился ли сервис.

Как принимается решение

Circuit breaker отслеживает:

• процент ошибок
• количество ошибок подряд
• время ответа

Пример:

• если >50% запросов завершаются ошибкой за последние 10 секунд → Open

Почему это важно

Без circuit breaker:

• сервис A вызывает сервис B
• B тормозит
• A ждёт ответы
• очередь запросов растёт
• A тоже начинает тормозить

В итоге падает вся цепочка.

С circuit breaker:

• A быстро понимает, что B недоступен
• перестаёт слать запросы
• освобождает ресурсы

Fallback (резервный ответ)

Часто вместе с circuit breaker используют fallback.

Примеры:

• вернуть кэшированные данные
• показать «частично доступный» результат
• вернуть дефолтный ответ

Это позволяет системе продолжать работать даже при проблемах.

Таймауты и retry

Circuit breaker работает вместе с:

• timeout — сколько ждать ответа
• retry — сколько раз повторить запрос

Важно:

• слишком большие таймауты усугубляют проблему
• слишком много retry создаёт дополнительную нагрузку

Правильная комбинация критична.

Где используется

Популярные реализации:

• Hystrix (устарел, но популяризировал паттерн)
• Resilience4j (Java)
• Envoy / Istio (на уровне сети)

Практические советы

1. Настраивайте пороги
   • процент ошибок
   • окно времени
2. Используйте fallback
   • без него пользователь увидит ошибки
3. Ограничивайте retry
   • иначе можно усилить нагрузку
4. Следите за метриками
   • количество открытых circuit breaker
   • частота срабатываний

Расширенные сценарии использования

Circuit breaker + bulkhead

Bulkhead — это ограничение ресурсов для отдельных частей системы.

Идея:

• разные сервисы используют отдельные пулы потоков или соединений
• проблема в одном сервисе не влияет на другие

Вместе с circuit breaker это даёт:

• изоляцию отказов
• предсказуемое поведение под нагрузкой

Circuit breaker на уровне сети

В современных системах circuit breaker часто реализуется не в коде, а на уровне инфраструктуры:

• Envoy
• Istio
• API Gateway

Плюсы:

• не нужно дублировать логику в каждом сервисе
• централизованное управление

Ограничение конкурентности

Иногда circuit breaker дополняется ограничением количества одновременных запросов:

• max in-flight requests
• очередь с лимитом

Это помогает избежать перегрузки даже до срабатывания breaker.

Частые ошибки

1. Слишком агрессивные настройки
   • breaker открывается при малейших ошибках
   • приводит к ложным срабатываниям
2. Отсутствие fallback
   • пользователь получает ошибки вместо деградации
3. Чрезмерный retry
   • увеличивает нагрузку на падающий сервис
4. Игнорирование latency
   • ошибки — не единственный сигнал
   • рост времени ответа тоже важен

Метрики для мониторинга

Важно отслеживать:

• количество переходов в Open
• время нахождения в Open
• процент ошибок
• latency зависимого сервиса

Это помогает правильно тюнить параметры.

Итог

Circuit breaker — ключевой паттерн для отказоустойчивости микросервисов.

• предотвращает каскадные сбои
• снижает нагрузку на проблемные сервисы
• улучшает стабильность системы

Если упрощать:

• сервис сломан → перестаём его дергать
• сервис восстановился → аккуратно возвращаем трафик

Это простой механизм, который может спасти систему под нагрузкой.