为什么ZUUL要强制信号量隔离来执行它的Hystrix命令？

Question

我注意到Spring强制执行隔离，而不是默认线程(如Netflix所建议的)。

org.springframework.cloud.netflix.zuul.filters.route.RibbonCommand上的一条评论说：

我们希望默认为信号量隔离，因为这包装了另外两个已经被线程隔离的命令。

但我还是不明白:-(这两个命令是什么？)

以这种方式配置，Zuul只能调度加载，但不允许超时，并允许客户端离开。简而言之，即使Hystrix超时设置为1000 is，客户端也只能在转发给向下链服务的调用返回(例如，由于ReadTimeout而导致的超时)之后才释放。

我试图通过覆盖配置来强制线程隔离(不幸的是，每个服务都是强制的，因为默认是在代码中强制的)，而且一切似乎都像预期的那样正常工作。但是，如果不正确理解其含义，我就不会热衷于这样做--当然是在代码中找到的注释和Spring版本Zuul采用的缺省值方面。

有人能提供更多的信息吗？Thx

Answer 1

Hystrix文档有一个很好的例子，说明为什么在包装线程隔离的命令时，信号量隔离是合适的。具体来说，它说：

fa可以使用信号量隔离，因为它正在做的所有工作都经过另外两个已经是线程隔离的HystrixCommands。只要fa的run()方法不执行任何其他网络调用、重试逻辑或其他“容易出错”的事情，就没有必要再进行另一层线程处理。

更新:问题提到必须为每个服务配置线程隔离，但我发现可以通过设置以下属性来控制所有Hystrix命令(包括RibbonCommands)的隔离：

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

Answer 2

此模式在Hystrix文档中定义。

fa可以使用信号量隔离，因为它正在做的所有工作都经过另外两个已经是线程隔离的HystrixCommands。只要fa的run()方法不执行任何其他网络调用、重试逻辑或其他“容易出错”的事情，就没有必要再进行另一层线程处理。

我们只使用信号量的原因是

1. 我们希望将请求的数量控制到主请求和次请求(可能更多)合并。
2. 由于隔离已经由实际的hystrix命令线程池(这个外观代理)实现，所以我们不需要担心在这个级别使用线程池(池中的每个线程都有固定开销的资源消耗区间，而信号量只是一个计数器)。所以，轻量级信号量就足够了。

参考资料：https://github.com/Netflix/Hystrix/wiki/How-To-Use#primary--secondary-with-fallback