Ответ.

Circuit Breaker — это архитектурный паттерн для предотвращения лавинообразных ошибок и деградации распределённых систем. Его суть: компонент, отвечающий за вызовы к внешней системе, проверяет успешность операций. Если неудачных попыток становится слишком много, Circuit Breaker автоматически «размыкается» и дальнейшие вызовы не проходят, пока система не начнёт восстанавливаться.

Пример: если микросервис Auth перестал отвечать, сервис Order, используя Circuit Breaker, временно не отправляет запросы, а сразу отдаёт ошибку, предотвращая высокую нагрузку на зависимую систему.

Пример кода на Python (используя библиотеку pybreaker):

import pybreaker
import requests

breaker = pybreaker.CircuitBreaker(fail_max=3, reset_timeout=30)

@breaker
def call_service():
    return requests.get("https://api.service.com/data")

try:
    response = call_service()
except pybreaker.CircuitBreakerError:
    print("Service temporarily unavailable. Please try later.")

Ключевые особенности:

• Ограничивает распространение сбоев и ускоряет восстановление системы.
• Позволяет gracefully degrade: предупреждать пользователей, а не обрушивать приложение.
• Актуален для интеграций с ненадёжными или перегруженными системами.

Вопросы с подвохом.

Circuit Breaker — это тоже самое, что Retry?

Нет. Retry — повторяет неудавшиеся операции, Circuit Breaker разрывает цепочку вызовов при большом числе сбоев, давая системе отдохнуть. Чаще всего эти паттерны комбинируют: retry внутри, circuit breaker снаружи.

Нужно ли внедрять Circuit Breaker между собственными микросервисами, которые раскатываются одновременно?

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

Circuit Breaker нужен только на внешних API-интеграциях?

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