Гайды
Circuit breaker и retry: устойчивость сервисов
Идемпотентность и backoff, состояния breaker, таймауты, mesh и gateway, метрики и хаос-инжиниринг.
~8 мин чтения
Circuit breaker и retry: устойчивость сервисов
Retry повторяет неудачный вызов (сетевой сбой); circuit breaker «размыкает» цепь к зависимости при серии ошибок, чтобы дать ей восстановиться и не каскадировать нагрузку. Часть bulkhead, timeout, rate limit — общий набор resilience patterns. Ошибки в очередях — Dead Letter Queue и Kafka.
1. Retry: правила
- Только для идемпотентных операций или с идемпотентным ключом.
- Exponential backoff + jitter — не бить синхронно в упавший сервис.
- Max attempts и total deadline.
Учитывайте заголовок Retry-After от upstream (429/503) — слепой exponential backoff может конфликтовать с явной рекомендацией сервера.
2. Circuit breaker: состояния
| Состояние | Поведение |
|---|---|
| Closed | Запросы идут; считаем ошибки |
| Open | Быстрый fail без вызова; cooldown |
| Half-open | Пробный запрос; успех → closed, fail → open |
Пороги: failure rate, slow call rate, minimum throughput (Polly, resilience4j, go-kit).
3. Timeout обязателен
Retry без timeout на каждый вызов и на весь cascade — риск удерживать потоки бесконечно.
4. Где применять
Клиенты к внешним API, между микросервисами, в worker'ах. На границе БД осторожно: транзакции и блокировки.
5. Инфраструктурный CB
Service mesh (Istio outlierDetection), API Gateway — политики на уровне платформы, едино для всех сервисов.
6. Bulkhead
Ограничьте пул потоков/соединений к отдельной зависимости, чтобы её падение не съело все ресурсы сервиса. В HTTP-клиентах — MaxConnsPerHost; в БД — отдельный пул для тяжёлых отчётов.
7. Идемпотентность и дедупликация
Повтор после timeout может дублировать side effect; используйте idempotency keys, unique constraints, outbox pattern для событий. В очередях — DLQ.
8. Готовые библиотеки (ориентиры)
| Стек | Примеры |
|---|---|
| Python | tenacity (retry/backoff), обёртки над pybreaker; в HTTP — политики httpx / urllib3 |
| JVM | resilience4j, Failsafe |
| Go | gobreaker, обёртки в go-kit |
Задайте отдельно: сколько ошибок открывает breaker, сколько успехов в half-open возвращает в closed, сколько параллельных пробных запросов допустимо в half-open (часто 1).
9. Чек-лист
- Метрики: состояние breaker, retry count, latency.
- Fallback (кэш, degraded read) где бизнес допускает.
- Тесты хаоса / fault injection на staging.
- Логировать причину открытия breaker (коды ошибок upstream).
- Согласовать политику retry между клиентом и брокером (не умножать ретраи бесконтрольно).
Дальше: HAProxy vs Nginx