spring-cloud - 为什么 ZUUL 强制 SEMAPHORE 隔离来执行其 Hystrix 命令？

Question

我注意到 Spring-Cloud ZUUL 将执行隔离强制为 SEMAPHORE 而不是 THREAD 默认值（如 Netflix 推荐的那样）。

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

我们希望默认为 semaphore-isolation，因为它包含了另外 2 个已经被线程隔离的命令

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

以这种方式配置，Zuul 只能调度负载，但不允许超时并让客户端走开。简而言之，即使 Hystrix 超时设置为 1000 毫秒，客户端也只会在转发到链下服务的调用返回（或由于 ReadTimeout 导致超时）后才被释放。

我试图通过覆盖配置来强制线程隔离（不幸的是，每个服务，因为默认值是在代码中强制执行的）并且一切似乎都按预期工作。但是，如果没有正确理解其中的含义，我并不热衷于这样做——当然是关于代码中的注释和 Zuul 的 Spring Cloud 版本采用的默认值。

有人可以提供更多信息吗？谢谢

score 3 · Accepted Answer

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

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

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

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

score 0 · Accepted Answer

这种模式在 Hystrix 文档中定义

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

我们之所以只使用信号量是因为

我们希望限制对主要和次要（可能更多）组合的请求数量
由于隔离已经通过实际的 hystrix 命令线程池（这个外观代理）实现，我们不需要担心使用线程池在这个级别的隔离（池中的每个线程在资源消耗方面都有固定的开销，不像信号量这只是一个计数器）。所以，轻量级信号量就足够了

2 回答 2