Spring-cloud学习笔记—Hystrix熔断器之微服务架构雪崩效应及解决方案
1. 雪崩效应场景
扇⼊
:代表着该微服务被调⽤的次数,扇⼊⼤,说明该模块复⽤性好扇出
:该微服务调⽤其他微服务的个数,扇出⼤,说明业务逻辑复杂扇⼊
⼤是⼀个好事,扇出
⼤不⼀定是好事- 在微服务架构中,⼀个应⽤可能会有多个微服务组成,微服务之间的数据交互通过远程过程调⽤完成。
- 这就带来⼀个问题,假设微服务A调⽤微服务B和微服务C,微服务B和微服务C⼜调⽤其它的微服务,这就是所谓的
扇出
。 - 如果扇出的链路上某个微服务的调⽤响应时间过⻓或者不可⽤,对微服务A的调⽤就会占⽤越来越多的系统资源,进⽽引起系统崩溃,所谓的
雪崩效应
。
如图中所示,最下游简历微服务响应时间过⻓,⼤量请求阻塞,⼤量线程不会释放,会导致服务器资源耗尽,最终导致上游服务甚⾄整个系统瘫痪。
2. 雪崩效应解决方案
- 从可⽤性可靠性着想,为防⽌系统的整体缓慢甚⾄崩溃,采⽤的技术⼿段;
- 以下三种技术⼿段应对微服务中的雪崩效应,这三种⼿段都是从系统可⽤性、可靠性⻆度出发,尽量防⽌系统整体缓慢甚⾄瘫痪。
2-1. 服务熔断
- 熔断机制是应对雪崩效应的⼀种微服务链路保护机制。我们在各种场景下都会接触到熔断这两个字。
- ⾼压电路中,如果某个地⽅的电压过⾼,熔断器就会熔断,对电路进⾏保护。
- 股票交易中,如果股票指数过⾼,也会采⽤熔断机制,暂停股票的交易。
- 同样,在微服务架构中,熔断机制也是起着类似的作⽤。
- 当扇出链路的某个微服务不可⽤或者响应时间太⻓时,熔断该节点微服务的调⽤,进⾏服务的降级,快速返回错误的响应信息。
- 当检测到该节点微服务调⽤响应正常后,恢复调⽤链路。
注意
:
- 服务熔断重点在“断”,切断对下游服务的调⽤
- 服务熔断和服务降级往往是⼀起使⽤的,Hystrix就是这样。
2-2.服务降级
- 通俗讲就是整体资源不够⽤了,先将⼀些不关紧的服务停掉
(调⽤我的时候,给你返回⼀个预留的值,也叫做兜底数据)
,待渡过难关⾼峰过去,再把那些服务打开。 - 服务降级⼀般是从整体考虑,就是当某个服务熔断之后,服务器将不再被调⽤,此刻客户端可以⾃⼰准备⼀个本地的fallback回调,返回⼀个缺省值,这样做,虽然服务⽔平下降,但好⽍可⽤,⽐直接挂掉要强。
2-3.服务限流
- 服务降级是当服务出问题或者影响到核⼼流程的性能时,暂时将服务屏蔽掉,待⾼峰或者问题解决后再打开;
- 但是有些场景并不能⽤服务降级来解决,⽐如秒杀业务这样的核⼼功能,这个时候可以结合服务限流来限制这些场景的并发/请求量限流措施也很多,⽐如:
- 限制总并发数(⽐如数据库连接池、线程池)
- 限制瞬时并发数(如nginx限制瞬时并发连接数)
- 限制时间窗⼝内的平均速率(如Guava的RateLimiter、nginx的limit_req模块,限制每秒的平均速率)
- 限制远程接⼝调⽤速率、限制MQ的消费速率等