spring cloud微服务架构(二):雪崩效应与Hystrix基本原理

1 雪崩效应

简单是来说,在分布式系统中,假如有一个请求需要调用A服务,但A服务出现了问题,则这个请求就会阻塞,那么只要调用服务A的请求都会阻塞,当阻塞的请求越来越多,占用的计算机资源就越来越多。进一步来说,就是一个服务出现问题,可能导致所有的请求都不可用,从而导致整个分布式系统都不可用,这就是“雪崩效应”。

如果要是考虑服务与服务之间的依赖关系,则连带作用更强,系统崩坏的速度更快!

举例来说:火车购票系统提供两种服务,查票服务和订票服务

  1. 如果不考虑两个服务之间的依赖关系:查票服务出现问题,则查票的请求全部阻塞,占用大量的系统资源,久而久之,导致整个系统无法响应请求
  2. 如果考虑依赖关系:订票服务依赖查票服务,查票服务出现问题,不仅仅查票的请求会全部阻塞,订票的服务也会阻塞,整个系统迅速崩坏!

2 Hystrix如何去解决雪崩

2.1 隔离技术

例如,货船为了进行防止漏水和火灾的扩散,会将货仓分隔为多个,如下图所示:

  • 线程池隔离

例如,淘宝的一个商品页面至少包含三方面信息,商品基本信息、商品价格、买家评论。一个商品页面的请求依赖于三个服务,基本信息服务A、价格服务B、评论服务C。因为是一个请求(线程)调用三个服务,调用顺序为:A->B->C,如果其中A服务出现问题,则另外两个服务都无法调用;如果B服务出现问题,则C服务无法调用。【横向调用】

线程隔离主要解决的问题就是,A、B、C服务之间无调用顺序的限制,不论哪个服务出现问题,都不会影响其他服务的调用。但是前提是A、B、C服务之间相互独立。基本原理是,为每个服务维护一个线程池,用户的请求将不再直接访问服务,而是通过线程池中的空闲线程来访问服务。【纵向调用】

这里写图片描述

  • 信号量隔离

该隔离技术,是限制某个服务的并发数量,对服务的并发数量设置一个阈值,超过该阈值则服务暂停接受新的请求。

2.2 熔断机制

如果某个目标服务调用慢或者有大量超时,如5秒内20次调用失败,此时,熔断该服务的调用,对于后续调用请求,不在继续调用目标服务,直接返回,快速释放资源。如果目标服务情况好转则恢复调用。熔断机制在Hystrix中,位于隔离技术之前。

1、判断是否进行熔断的依据是:计算错误率,当错误率超过预设的值(默认是50%)且10秒内超过20个请求,则开启熔断。
2、 对于被熔断的请求,并不是永久被切断,而是被暂停一段时间之后,允许部分请求通过,若请求都是健康的,则对请求健康恢复(取消熔断),如果不是健康的,则继续熔断。

2.3 总执行流程

这里写图片描述

  1. 首先判断是否有缓存,如果有则直接返回结果
  2. 无缓存,则判断断路器是否打开,如果打开则执行回退方法,返回结果
  3. 熔断器未打开,则判断线程池/信号量是否到底阈值,如果到达阈值,则执行回退方法,返回结果
  4. 若未达到阈值,则执行命令,如果成功返回结果;失败返回回退方法的执行结果

参考:
[1] Hystrix GitHub官网:https://github.com/Netflix/Hystrix/wiki
[2] 杨恩雄-2017《疯狂Spring Cloud微服务架构实战》

猜你喜欢

转载自blog.csdn.net/disiwei1012/article/details/80189813