Обработка ошибок HTTP-клиента с помощью Feign и Hystrix

Как сочетание Feign и Hystrix предоставит вам полный контроль над возвращаемыми ошибками

«Все, что может пойти не так, пойдет не так» - Закон Мерфи

Я думаю, что это одна из лучших особенностей Feign. Точно так же, как мы можем определить Encoder, Decoder, Logger, нам разрешено устанавливать наши резервные стратегии на случай, если сервер вернет некоторую ошибку. Это очень распространенный сценарий в распределенных приложениях.

Помните аннотацию @FeignClient? У него есть два настраиваемых параметра для резервных стратегий:

• Резервный: класс, реализующий наши методы интерфейса, вызываемый на случай, если что-то пойдет не так (возможно, вернет некоторые данные по умолчанию).
• FallbackFactory: класс, реализующий интерфейс FallbackFactory, для обработки текущего исключения и определения более настраиваемого поведения.

Но откат не включен по умолчанию. Если у вас есть опыт работы с облаком Spring, вы, должно быть, думаете в данный момент о Hystrix, и да, мы будем его использовать. Так же, как и при включении клиентов Feign, нам нужно включить шаблон автоматического выключателя в нашем классе приложения (или в любом классе, помеченном @Configuration):

В этом примере мы будем использовать резервный фабричный класс, который будет вызывать наш резервный класс с информацией об исключении, например:

Обратите внимание, как перезаписанный метод create() позволяет нам определить, какой резервный класс возвращается в зависимости от сгенерированного исключения. В этом случае у нас есть только один резервный класс, но это мощная функция интерфейса FallbackFactory.

Теперь наш чистый резервный класс:

О некоторых вещах, которые вы должны помнить при реализации резервных вариантов:

• Должны быть помечены как @Component, они уникальны для всего приложения.
• Резервный компонент должен иметь область видимости прототипа, потому что мы хотим, чтобы для каждого исключения создавался новый компонент.
• Используйте внедрение конструктора в целях тестирования.

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

Настраиваемые политики обработки ошибок и повторных попыток

Мы знаем, как поступать с неожиданными ошибками, возвращаемыми с сервера, Hystrix позаботится об этом и позволяет нам выбирать, какой резервный класс возвращает. Это единственный способ справиться с ошибками? Рассмотрим особый сценарий:

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

• Если код состояния ответа - 4XX, мы должны вернуть пользователю сообщение об ошибке.
• В случае статуса 5XX мы должны повторить запрос максимум 5 раз.

Hystrix и резервные классы полезны для работы с ошибками, в случае, если мы хотим создать политики повторных попыток, возможно, нам потребуется настроить аннотацию Spring Retry в самом методе службы в зависимости от типа ошибки и оценить код ошибки, возвращаемый сервером. в каждом методе… так много абстракции. Это также относится к сообщению об исключении, во многих случаях нам нужно вызвать BusinessException, чтобы иметь дело с конкретной ошибкой, которую мы хотим выбросить, обработать и зарегистрировать, но проблема в том, что Hystrix оборачивает все исключения в HystrixRuntimeException.

Аналогично интерфейсам Encoder и Decoder, Feign предоставляет интерфейс ErrorDecoder. Угадайте, что, его можно настроить, чтобы настроить обработку ошибок. В большинстве случаев использование настраиваемых исключений зависит от кода состояния запроса. Приведем пример:

И объявите это в своем классе конфигурации клиента:

Декодер ошибки активируется, когда мы получаем ответ от сервера. Если текущий сервер недоступен или просто не существует, декодер ошибок не вызывается. Это означает, что ErrorDecoder во всех случаях требует ответа 4XX или 5XX.

И чтобы включить повторную попытку, мы должны иметь в виду две основные концепции:

• Повторная попытка активируется только при подаче сигнала RetryableException.
• Retryer bean настроен в вашем классе конфигурации.

Итак, добавив больше логики к классу MyErrorDecoder, синтаксис должен быть примерно таким:

И в bean-компоненте конфигурации:

И, конечно же, разрешена настройка Retryer:

Наконец, наш bean-компонент Retryer будет таким:

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

Мои последние мысли после использования Feign в течение некоторого времени

• Легко перейти с разных остальных клиентов на Feign. Фактически, Feign полностью независим и не мешает другим.
• Позволяет мне избежать большого количества шаблонного кода в случае обработки исключений.
• Легко понять и поддерживать, Feign абстрагирует реализацию того, как выполняются запросы, и вам просто нужно позаботиться о конфигурации.
• В этой статье не рассматриваются очень продвинутые функции, такие как сохранение токена аутентификации, установка настраиваемых заголовков и т. Д.

В завершение, вот несколько статей с дополнительной информацией о Feign:

Увидимся в следующей статье;)