Resilience4j
Resilience4j — библиотека готовых паттернов отказоустойчивости для микросервисов, легковесная замена устаревшему Hystrix. Circuit Breaker (см. тему «Circuit Breaker») — лишь один из её модулей, есть и другие защитные механизмы.
@Retry(name = "userService", fallbackMethod = "getUserFallback")
@RateLimiter(name = "userService")
@CircuitBreaker(name = "userService", fallbackMethod = "getUserFallback")
User getUser(Long id) {
return restTemplate.getForObject("http://user-service/api/users/" + id, User.class);
}Копнуть глубже
Основные модули Resilience4j, и какую проблему каждый решает:
| Модуль | Защищает от |
|---|---|
| Circuit Breaker | каскадного сбоя при падении зависимого сервиса |
| Retry | временных, кратковременных сбоев (сетевая дрожь) |
| Rate Limiter | перегрузки своего сервиса слишком частыми запросами |
| Bulkhead | исчерпания ресурсов одним “плохим” вызовом, изолирует пул потоков под конкретную зависимость |
| Time Limiter | зависших вызовов — принудительно обрывает по таймауту |
Bulkhead — частично менее известный, но важный паттерн. Название от переборок на корабле — если одна “каюта” затапливается, остальные изолированы и корабль не тонет целиком. На практике это значит: выделить отдельный пул потоков под вызовы к конкретному внешнему сервису, чтобы если этот сервис тормозит и все потоки заняты ожиданием его ответа — это не утащит за собой потоки, обслуживающие другие, никак не связанные запросы.
Комбинация нескольких механизмов — норма, не исключение. Реальный production-код часто оборачивает внешний вызов сразу несколькими защитами (как в примере выше) — каждая защищает от своего класса проблем, и вместе они дают существенно более устойчивую систему, чем любая из них по отдельности.
• идею Bulkhead и почему механизмы часто комбинируют вместе (если дошёл до 2-го слоя).