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、调用数度快,开销小,由于和调用线程是处于同一个线程,所以必须确保调用的微服务可用性足够高并且返回快才用
推荐: