hystrix隔离策略对比

太过爱你忘了你带给我的痛 2021-12-18 21:53 259阅读 0赞

##### hystrix隔离策略 #####

zuul的隔离实现是基于hystrix实现的，hystrix支持线程池隔离和信号量的隔离

###### \# 信号量隔离： ######

*  it executes on the calling thread and concurrent requests are limited by the semaphore count --引自官网
 *  单每次调用线程，当前请求通过技术信号量进行限制，当信号量大于了最大请求数（maxConcurrentRequest）时候，触发限制，调用fallback接口快速返回。

![img][]

此处可能出现的问题在于：信号量的调用是同步的，也就是说，每次调用都会阻塞调用方的线程，一直到结果返回，这样就导致了无法对访问做超时（只能依靠调用协议超时，无法主动释放）

*  官网对信号量隔离的描述：
    
     *  Generally the only time you should use semaphore isolation for `HystrixCommand`s is when the call is so high volume (hundreds per second, per instance) that the overhead of separate threads is too high; this typically only applies to non-network calls.
 *  两点：
    
     *  隔离的粒度太细，数百个实例需要隔离，此时用线程池做隔离开销过大
     *  通常这种都是非网络调用的情况下

###### \# 线程池隔离 ######

*  it executes on a separate thread and concurrent requests are limited by the number of threads in the thread-pool -引自官网

通过每次都开启一个单独线程运行，他的隔离是通过线程池，即每个隔离粒度都是线程池，互不干扰。

*  Commands executed in threads have an extra layer of protection against latencies beyond what network timeouts can offer.

线程池隔离方式，等于多了一层保护措施，可以通过hystryx直接设置超时时间，超时后直接返回

![img][img 1]

对比表格‘：

<table> 
 <thead> 
  <tr> 
   <th>隔离方式</th> 
   <th>是否支持超时</th> 
   <th>是否支持熔断</th> 
   <th>隔离原理</th> 
   <th>是否异步调用</th> 
   <th>资源消耗</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>线程池隔离</td> 
   <td>支持，可以直接返回</td> 
   <td>支持，当线程池达到maxsize后，再请求会出发fallback熔断</td> 
   <td>每个服务单独用线程池</td> 
   <td>可以是异步，也可以是同步。看调用的方法</td> 
   <td>消耗大，大量线程的上下文切花，容易造成机器负载过高</td> 
  </tr> 
  <tr> 
   <td>信号量隔离</td> 
   <td>不支持，如果阻塞，只能通过调用协议比如socket超时返回</td> 
   <td>支持，当信号量达到maxConcurrentRequests后，再请求会触发fallback熔断</td> 
   <td>通过信号量计数器</td> 
   <td>同步调用，不支持异步</td> 
   <td>消耗小，只是一个计数器</td> 
  </tr> 
 </tbody> 
</table>

*  zuul网关如果使用线程池隔离是属于异步调用，其实查看源码如下：

![img][img 2]

调用的是hystrix command 的excute方法，hytrix的官网原文说明如下：

*  [`execute()`][execute] — blocks, then returns the single response received from the dependency (or throws an exception in case of an error)

execute是一个阻塞方法，也就是说，如果不合理的设置线程池的大小，和超时时间，还是有可能把zuul的线程消耗完。从而失去对服务的保护作用

[img]: /images/20211219/73ded8bd824b4a269c22609e808ab8bc.png
[img 1]: /images/20211219/c5bcd7e48a0c42179ac5d3f0dbfa82bc.png
[img 2]: /images/20211219/d639dfc3b22f4c93a4cd7da7f95f5513.png
[execute]: http://netflix.github.io/Hystrix/javadoc/com/netflix/hystrix/HystrixCommand.html#execute%28%29