Почему ZUUL принудительно изолирует SEMAPHORE для выполнения своих команд Hystrix?

Я заметил Spring -Cloud ZUUL принудительно изолирует выполнение SEMAPHORE вместо значений по умолчанию THREAD (как рекомендовано Netflix).

Комментарий в org.springframework.cloud.netflix.zuul.filters.route.RibbonCommand говорит:

мы хотим по умолчанию изолировать семафор, так как это обертывание 2 других команды, которые уже выделены потоком

Но все же я не понимаю:-( Каковы эти две другие команды?

Настроенный таким образом, Zuul может только планировать загрузку, но не позволяет таймингам и позволяет клиенту уйти. Короче говоря, даже если тайм-аут Hystrix установлен на 1000 мс, клиенты будут освобождены только после того, как вызов, перенаправленный службе вниз, вернется в цепочку (или тайм-ауты из-за ReadTimeout, например).

Я попытался изолировать THREAD, переопределив конфигурацию (к сожалению, поскольку служба по умолчанию вынуждена в коде), и все работает так, как ожидалось. Тем не менее, я не заинтересован в этом без правильного понимания последствий - конечно, в отношении комментария, найденного в коде, и значений по умолчанию, принятых облачной версией Zuul Spring.

Может ли кто-нибудь предоставить дополнительную информацию? спасибо

Ответ 1

Документация Hystrix имеет хороший пример того, почему изоляция семафоров подходит при обертке команд, которые изолированы потоком. В частности, он говорит:

Фасад HystrixCommand может использовать семафорную изоляцию, поскольку вся работа, которую он выполняет, проходит через два других HystrixCommands, которые уже выделены потоком. Нет необходимости иметь еще один слой потоковой обработки, если метод run() фасада не выполняет никаких других сетевых вызовов, повторной логики или других вещей, подверженных ошибкам.

Обновление. В вопросе упоминается, что для каждой службы необходимо настроить изоляцию потоков, но я обнаружил, что вы можете контролировать выделение всех команд Hystrix (включая RibbonCommands), задав следующее свойство:

hystrix.command.default.execution.isolation.strategy = THREAD

Ответ 2

Этот шаблон определен в документации Hystrix

Фасад HystrixCommand может использовать семафор-изоляцию, поскольку вся работа, которую он выполняет, проходит две другие HystrixCommand, которые уже изолированы от потоков. Нет необходимости иметь еще один уровень многопоточности, если метод run() фасада не выполняет никаких других сетевых вызовов, логики повторов или других "подверженных ошибкам" вещей.

Причина, по которой мы используем только семафор, заключается в том, что

Мы хотим ограничить количество запросов на основной и дополнительный (может быть больше) вместе взятых
Поскольку изоляция уже достигнута фактическими пулами потоков команд Hystrix (которые использует этот фасад), нам не нужно беспокоиться об изоляции на этом уровне с помощью пулов потоков (каждый поток в пуле имеет фиксированные временные интервалы потребления ресурсов, в отличие от семафора). который просто счетчик). Итак, легкий семафор достаточно хорош

Ссылка: https://github.com/Netflix/Hystrix/wiki/How-To-Use#primary--secondary-with-fallback