微服务架构(5)——熔断降级

目录：

1、为什么需要熔断降级
2、熔断降级框架对比选型
3、集成Sentinel
4、Sentinel原理

为什么需要熔断降级

在微服务化的系统中会存在一个比较严重的问题，叫做服务雪崩。服务雪崩是怎么发生的呢？

如上图，假设一个用户进行一个下单操作，商品服务需要调用订单服务添加订单数据，下单成功后，订单服务又需要调用积分服务给下单成功的用户增加一些积分。
要是有一天，积分服务突然挂了。这时一个下单请求过来的话，在订单服务调用积分服务时，因为积分服务挂了。请求一直卡在这里，等到过了设置的超时时间，才返回请求超时的错误，去释放这个连接。
如果之前的请求没有超时，又不断有新的请求进来，新请求又继续卡在这里等待超时，那么请求在订单服务就会堆积的越来越多，导致订单服务线程资源耗尽。
这时商品服务去调用订单服务的请求就会阻塞、等待、超时。导致商品服务请求堆积，商品服务又变的不可用。
这就导致了服务雪崩。

为了解决这个问题，那么就需要对异常的服务进行熔断，防止影响其它的服务。
在下单的这个调用链中，其实积分服务不是必须的。积分没有加上其实影响也不大，要是有用户进行投诉反馈，那么我们手工给他加上就可以。所以积分服务发生异常，我们及时熔断就可以，避免影响其它服务。只要有请求是去调用积分服务的，直接返回调用失败，不需要等到超时时间再返回。

降级就是说，订单服务发现积分服务有明显的延迟或是不可用，那么就不去调用积分服务了，直接走本地降级策略。比如说直接打印一条日志“XX用户下单成功，增加10积分”。后续再通过人工的方式把积分加上。这样的话就没有影响到整个系统的可用性，用户还是可以正常下单。

熔断降级框架对比选型

当下我们用的比较多的熔断降级框架主要就是Sentinel和Hystrix，下面就基于这两种框架来做一个对比。

熔断降级策略

Sentinel 与 Hystrix 都支持基于失败比率（异常比率）的熔断降级，在调用达到一定量级并且失败比率达到设定的阈值时自动进行熔断，此时所有对该资源的调用都会直接被拒绝，直到过了指定的时间窗口后才启发性地恢复。
Sentinel