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

Хорошие новости? Три шаблона устойчивости могут спасти вас от этого кошмара: прерыватели цепи, повторные попытки и тайм-ауты. И в отличие от театральных представлений, которые вы увидите в некоторых учебниках, их реализация проста, если вы понимаете, что на самом деле делает каждый из них.

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

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

Вот что происходит без надлежащей устойчивости:

  1. Сервис A вызывает Сервис B.
  2. Сервис B работает медленно или недоступен.
  3. Сервис A ждёт бесконечно (или имеет длинный тайм-аут).
  4. Потоки накапливаются в Сервисе A.
  5. Сервис A перестаёт отвечать своим собственным клиентам.
  6. Ваш дежурный инженер задаётся вопросом о своём жизненном выборе.

Прерыватели цепи, повторные попытки и тайм-ауты — это ваша защита от этого каскада. Это не ракетостроение — это прагматичные шаблоны, которые нужны каждой производственной системе.

Понимание трёх столпов

Тайм-ауты: нетерпеливый вышибала

Тайм-аут — самый простой из трёх: он говорит: «если эта операция занимает больше X секунд, прекратите ждать и быстро завершите с ошибкой». Без тайм-аутов ваше приложение будет ждать вечно, что ровно настолько полезно, как и шоколадный чайник.

Почему тайм-ауты важны:

  • Предотвращают задержку потоков на неопределённый срок.
  • Позволяют вашему приложению корректно завершать работу и двигаться дальше.
  • Дают вам шанс реализовать резервное поведение.

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

Повторные попытки: оптимистичный hopeful

Повторные попытки предполагают, что временные сбои (сетевые сбои, кратковременные сбои сервисов) могут завершиться успешно при следующей попытке. Это способ вашего приложения сказать: «может быть, вам просто нужно было немного времени».

Критическое правило: повторяйте только идемпотентные операции. Если ваша операция создаёт побочные эффекты (например, списание средств с кредитной карты), повторная попытка означает потенциальное двойное списание. Это не устойчивость — это иск.

Когда повторные попытки работают:

  • Сетевые тайм-ауты (сервис в порядке, просто была задержка в сети).
  • Временные сбои перегруженных сервисов.
  • Операции, которые безопасно повторять.

Когда повторные попытки не помогают:

  • Сервис действительно недоступен.
  • Нарушения ограничений базы данных.
  • Неидемпотентные операции (платежи, переводы средств и т. д.).

Прерыватель цепи: мудрый привратник

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

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

Три состояния:

  1. Закрыто — всё работает. Запросы проходят нормально.
  2. Открыто — обнаружено слишком много сбоев. Запросы отклоняются немедленно, даже не пытаясь обратиться к сервису.
  3. Полуоткрыто — цепь была разомкнута, но мы осторожно проверяем, восстановился ли сервис. Разрешён один запрос. Если он завершится успешно, мы закрываем цепь. Если он потерпит неудачу, мы снова откроем её.

Порядок имеет значение (всерьёз)

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

Вот как это должно работать (от внешнего к внутреннему):

  1. Тайм-аут — устанавливает общий временной лимит.
  2. Прерыватель цепи — предотвращает каскадные сбои.
  3. Повторная попытка — обрабатывает временные сбои.
  4. Фактический вызов — обращение к сервису.

Этот порядок означает:

  • Ваши повторные попытки происходят в пределах окна тайм-аута.
  • Ваш прерыватель цепи предотвращает повторные попытки обращения к неработоспособному сервису.
  • Ваш тайм-аут останавливает всё, что занимает слишком много времени.

Если сделать это наоборот, у вас будут повторные попытки, обходящие прерыватель цепи, или тайм-ауты, применяемые к отдельным попыткам повторного вызова вместо всей операции. Не весело.

Настройка Resilience4j (современный стандарт)

Resilience4j — это популярная библиотека для этого в экосистеме Java. Она лёгкая, компонуемая и не полагается на пулы потоков, как старый Hystrix.

Сначала добавьте зависимость:

<dependency>
    <groupId>io.github.resilience4j</groupId>
    <artifactId>resilience4j-spring-boot3</artifactId>
    <version>2.1.0</version>
</dependency>

Конфигурация: сохраняйте разумность

Вот практическая конфигурация для платёжного сервиса, которая демонстрирует концепции без излишнего параноидального подхода:

resilience4j:
  circuitbreaker:
    instances:
      paymentService:
        failureRateThreshold: 50
        minimumNumberOfCalls: 5
        waitDurationInOpenState: 30s
        permittedNumberOfCallsInHalfOpenState: 3
        automaticTransitionFromOpenToHalfOpenEnabled: true
  retry:
    instances:
      paymentService:
        maxAttempts: 3
        waitDuration: 500ms
        enableExponentialBackoff: true
        exponentialBackoffMultiplier: 2
        retryExceptions:
          - java.io.IOException
          - java.util.concurrent.TimeoutException
  timelimiter:
    instances:
      paymentService:
        timeoutDuration: 2s

Давайте разберём это:

  • failureRateThreshold: 50 — открыть цепь, если 50% вызовов завершаются сбоем.
  • minimumNumberOfCalls: 5 — не принимайте решения на основе крошечных объёмов выборки.
  • waitDurationInOpenState: 30s — после открытия подождите 30 секунд, прежде чем проверять, восстановился ли сервис.
  • maxAttempts: 3 — повторите попытку до трёх раз.
  • waitDuration: 500ms — подождите 500 мс между повторными попытками.
  • enableExponentialBackoff: true — удваивайте время ожидания между повторными попытками (500 мс → 1 с → 2 с).
  • timeoutDuration: 2s — дайте сервису 2 секунды на ответ.

Почему эти числа? Они консервативны и разумны:

  • 50% отказов — это чёткий сигнал, что что-то не так.
  • 5 минимальных вызовов предотвращают слишком быстрое открытие цепи.
  • 30 секунд дают деградировавшему сервису время на восстановление.
  • Экспоненциальный откат не перегружает испытывающий трудности сервис.
  • 2-секундный тайм-аут достаточно короткий, чтобы быстро завершить работу с ошибкой, но достаточно длинный для законных вызовов.

Код: три уровня компонуемости

Уровень 1: аннотации (простейший)

@RestController
@RequestMapping("/api/payments")
public class PaymentController {
    @PostMapping
    @TimeLimiter(name = "paymentService")
    @CircuitBreaker(name = "paymentService", fallbackMethod = "paymentFallback")
    @Retry(name = "paymentService")
    public CompletableFuture<PaymentResponse> processPayment(
            @RequestBody PaymentRequest request) {
        return CompletableFuture.supplyAsync(() -> {
            // Ваша логика обработки платежей здесь
            return paymentService.process(request);
        });
    }
    public CompletableFuture<PaymentResponse> paymentFallback(
            PaymentRequest request, Exception ex) {
        log.warn("Платёжный сервис недоступен, возвращаем резервный ответ", ex);
        return CompletableFuture.completedFuture(
            new PaymentResponse("PENDING", "Сервис временно недоступен. Ваш платёж будет обработан, когда сервис восстановится.")
        );
    }
}

Обратите внимание на порядок декораторов сверху вниз: TimeLimiter → CircuitBreaker → Retry. Resilience4j применяет их в обратном порядке, что означает, что Retry запускается первым, затем CircuitBreaker, затем TimeLimiter. Идеально.

Уровень 2: программная конфигурация (больше контроля)

Если аннотации кажутся слишком магическими:

@Configuration
public class PaymentResilienceConfig {
    @Bean
    public PaymentService paymentService(