Небольшой опыт отката встроенного в Sentinel вызова Feign.

Смотрел Sentinel (трафик защитник распределенных систем) два дня назад. Всякие рекламщики в интернете говорят, что это просто и нестандартно. Затем изучите его, ну... он работает прямо из коробки, и его легко начать. Тогда мне нечего сказать, я сразу настроил набор окружений и интегрировал Nacos и Feign, чтобы сделать это! Но посередине все еще есть некоторые проблемы. Позвольте мне сначала рассказать о моей подробной сцене:

1. Я определяю провайдера и предоставляю клиентские вызовы Feign.

2. Исключение возникло в классе реализации клиента Feign для сервисного предохранителя. Как показано ниже:

   Интерфейс клиента Feign:

   

   Класс реализации Feign (пользовательская резервная функция):

   

3. Я настроил глобальный обработчик исключений на стороне потребителя, а затем вызвал интерфейс Feign на стороне сервера. Но когда сервис перегорел, то есть сервер упал, мой потребитель меня не поймает.Настройте это исключение ServiceExceptionаномальный.

   Взгляните на мой глобальный обработчик исключений

   

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

1. Старайтесь избегать создания исключений в пользовательской резервной функции вызывающего объекта интерфейса Feign.

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

1. Когда возникает исключение при использовании интерфейса Fegin для удаленного вызова сервера, будет выполняться логика резервного варианта.

2. Мы симулируем машину с выключенным сервером. :

   1. Давайте взглянемSentinelInvocationHandlerЭтот код для этого класса.

      

      Если наш сервер не отвечает, задержка в сети или другая неизвестная ситуация приводит к тому, что метод methodHandler.invoker() не возвращается правильно, будет выдано исключение. То есть во время вызова FeignClient возникло исключение. Если мы настроим резервный метод сервисного предохранителя, наш резервный метод будет выполнен.

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

      

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

      

      На этом этапе, если в резервной копии все еще создается исключение.SentinelInvocationHandlerЭтот класс выдаст это исключение как ошибку.

      На данный момент мой глобальный обработчик исключений не может обрабатывать это исключение какНаше пользовательское исключение ServiceExceptionВместо этого рассматривайте его как Throwable.Это заставит нас смотреть в неправильном направлении при устранении неполадок, потому что я явно выбрасываю ServiceException, как оно, наконец, стало Throwable?

      

Суммировать:

1. Когда Sentinel интегрирует вызовы Feign, старайтесь избегать генерации исключений в аварийном режиме сервисного предохранителя, и, наконец, он будет рассматриваться Sentinel как Throwable. Лучше всего вернуть результат, который мы можем правильно идентифицировать, и указать, что вызов является ненормальным в возвращаемом результате.
2. Написать демо с Sentinel легко. Однако для использования Sentinel на предприятии все же необходимо внести некоторые коррективы в исходный код.
   1. Например, при интеграции Nacos для достижения постоянства. Здесь также есть яма, которая может быть ошибкой Sentinel. Проще говоря, при добавлении правила управления потоком в консоли Sentinel и сохранении его в Nacos можно добавить только один ресурс, а при повторном добавлении ресурса предыдущий будет перезаписан. Собираюсь упомянуть об этом в вопросах
3. Если я хочу использовать Sentinel на предприятии, я чувствую, что должен получить исходный код и запустить его.