Spring Cloud系列（5）：Spring Cloud Hystrix

spring cloud hystrix 熔断器

在上一篇中，我们提到，每个微服务架构，暴露给第三方的都是一个统一个网关，通过zuul这个网关来进行分发。比如有两个提供鉴权的服务A、B、根据一定的策略，比如轮询策略，第一次访问到了服务A，第二次就是访问服务B。但如果服务A断掉了，连不上，还是有百分之五十的请求都被分发到A服务上去的话，就会造成资源阻塞，最后撑爆服务器。

hystrix是熔断器，它的作用就像保险丝一样，在多次请求连接不上的时候，就认为它断开了，不会一直向它发送请求。在达到某个时间阈值后，再将一两条请求分发到这个服务，如果恢复正常了，请求也恢复到正常的轮训机制。如果还是异常状态，则继续之前的策略，不分发到这个应用服务。

---

转自：https://huan1993.iteye.com/blog/2424363

随着服务的拆分，各个服务有着明确的职责，服务之间通过轻量级的协议进行通讯。但有时候我们完成一个功能需要同时调用多个微服务，比如完成订单的创建，那么获取用户信息需要调用用户微服务，获取商品信息需要调用商品微服务，给用户增加积分需要调用积分微服务。假如用户微服务调用此时响应慢，就会导致调用线程（tomcat线程或jetty线程等）被占用，降低系统的处理能力。如果用户微服务被隔离了，使用是自己的线程，那么就不会占用调用线程，系统的处理能力就会提高。 

下面是官网隔离的图。

从上面可以看到，隔离机制分成2种，左侧是线程池隔离，右侧是信号量隔离。

上方蓝色的线是调用线程(tomcat线程...),黄色的线是hystrixCommand线程

线程池隔离：
      1、调用线程和hystrixCommand线程不是同一个线程，并发请求数受到线程池（不是容器tomcat的线程池，而是hystrixCommand所属于线程组的线程池）中的线程数限制，默认是10。
      2、这个是默认的隔离机制
      3、hystrixCommand线程无法获取到调用线程中的ThreadLocal中的值
  

信号量隔离：
      1、调用线程和hystrixCommand线程是同一个线程，默认最大并发请求数是10
      2、调用数度快，开销小，由于和调用线程是处于同一个线程，所以必须确保调用的微服务可用性足够高并且返回快才用

推荐：

详解Hystrix资源隔离