彻底理解微服务的雪崩、限流、熔断和降级
彻底理解微服务的雪崩、限流、熔断和降级
在微服务架构中，服务雪崩、限流、熔断和降级是常见的问题。本文通过具体的场景和案例，详细解释了这些概念，并给出了实际的解决方案。
一.服务雪崩
通过下图来对它进行分析：
在一个电商系统中，描述商品、商品详情、购物车服务都会去请求同一个库存服务，最后都会去请求商品服务，此时，有如下流程：
- 秒杀服务请求量比较大，积分服务无法承受这么大的并发量，导致积分服务挂掉；
- 由于积分服务挂掉，导致商品服务请求积分服务的时候得不到相应，大量的线程都堆积在商品服务中，导致商品服务的线程池被打完，间接导致商品服务被拖垮；
- 商品服务被拖垮后，导致订单服务也被拖垮，导致秒杀服务整个链路都不可用。
- 然后在微服务中也存在一些共享的服务，比如库存服务，商品服务不可以这个过程又会逐渐的扩散，导致库存不可用，从而导致整个应用都不可用。
整个过程就是常说的服务雪崩效应：因服务提供者的不可用导致服务调用者的不可用，并将不可用逐渐放大的过程，就叫服务雪崩效应。
解决方式：
- 通过熔断机制：当一个服务挂了，被影响的服务能够及时熔断，使用 Falback 数据保证流程在非关键服务不可用的情况下，仍然可以进行；(积分服务挂掉后，将它熔断隔离，通过降级的方式进行处理)
- 通过线程池和消息队列机制实现异步化：允许服务快速失败，当一个服务因为过慢而阻塞，被影响服务可以在超时后快速失败，不会影响整个调用链路。(使用消息队列的方式，商品服务异步请求积分服务，异步请求出现了异常，我们可以让它快速失败)
总结：
一句话就是一个服务挂掉，导致整个系统不可用。服务雪崩也是微服务架构中最可怕的问题，也是导致微服务架构不可用的最大元凶。
二.服务限流
服务限流就比较好理解了，就好比节假日高峰时期高速路出口，大量车辆排队通过一个道理：
它指的是在高并发请求下，为了保护系统，可以对访问服务的请求进行数量上的限制，从而防止系统不被大量请求压垮，在秒杀、大促、抢购中，限流是非常重要的。在并发量大的时候，不同的场景又不同的限流手段，比如说，系统只能承受100W的并发量，超过这个并发量的请求可以直接让他失败，或者说让他们你匀速排队进来，防止那些激增流量打垮我们的冷系统。
三.服务熔断
再谈熔断和降级前，先举个简单例子：香港的警匪片，在进行非法交易的时候，突然收到信息，“有内鬼，终止交易，执行B计划”，在这条信息中，终止交易指的就是服务熔断，执行B计划指的就是服务降级。
定义：当服务A调用的某个服务B不可用时，上游服务A为了保证自己不受影响，及时切断与服务B的通讯，以防服务雪崩。
四.服务降级
定义：提前预想另一种兜底的措施，可以进行后期补救，知道服务B恢复，再恢复和B服务的正常通信。(因为B服务挂掉，所以当A服务调用B服务不通时，需要提前想好另一个兜底的措施，以警匪片开说，有内鬼不可怕，只要想好备用方案，不能说有内鬼就等警察来抓你，此时应该想好兜底的逃跑路线，等抓到内鬼后，再进行交易)
来个实际的例子：有一个业务流程是先下单，下单成功后进行积分，如果用户下单成功了，但是由于积分服务挂掉导致积分无法入库，此时肯定不能给用户返回当前下单失败或者其他的错误提示，正确的流程还是给用户返回下单成功信息，然后在数据库添加一条积分失败的日志，后续的补救措施可以是通过定时任务去扫描这个积分失败日志表，后续把积分给用户补上，这就是所谓的B计划，这就是一种兜底措施。
本文原文来自CSDN