微服务的熔断降级限流通俗易懂

1、引言

在微服务架构中，根据业务来拆分成一个个的服务，服务与服务之间可以相互调用（RPC）。为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这种现象就是“服务雪崩”。

1.png

如上图图所示：A作为服务提供者，B为A的服务消费者，C和D是B的服务消费者。A不可用引起了B的不可用，并将不可用像滚雪球一样放大到C和D时，雪崩效应就形成了。

另外，在大中型分布式系统中，通常系统很多依赖(HTTP,hession,Netty,Dubbo等)，如下图：

2.png

在高并发访问下，这些依赖的稳定性与否对系统的影响非常大，但是依赖有很多不可控问题：如网络连接缓慢，资源繁忙，暂时不可用，服务脱机等。

如下图：QPS为50的依赖 I 出现不可用，但是其他依赖仍然可用：

3.png

当依赖I 阻塞时，大多数服务器的线程池就出现阻塞，影响整个线上服务的稳定性。如下图:

4.png

在复杂的分布式架构的应用程序有很多的依赖，都会不可避免地在某些时候失败。高并发的依赖失败时如果没有隔离措施，当前应用服务就有被拖垮的风险。

很多服务框架会提供服务重试机制，在很大程度上解决了由于网络瞬时不可达的问题。但是在很多的情况下造成服务雪崩的元凶正是服务重试机制。

某个服务本来就已经出现问题了，造成资源占用无法释放、请求延时等问题。这时在请求失败之后又不断的发送重试请求，在原本就无法释放的资源基础上继续膨胀式占用，导致整个系统资源耗尽。导致服务雪崩。

要防止系统发生雪崩，就必须要有容错设计。如果遇到突增流量，一般的做法是对非核心业务功能采用熔断和降级的措施来保护核心业务功能正常服务，而对于核心功能服务，则需要采用限流的措施。

2、熔断

熔断来自英文短语circuit breaker，circuit breaker在电工学里就是断路器的意思。它就相当于一个开关，打开后可以阻止流量通过。比如保险丝，当电流过大时，就会熔断，从而避免元器件损坏。

服务熔断是指调用方访问服务时通过断路器做代理进行访问，断路器会持续观察服务返回的成功、失败的状态，当失败超过设置的阈值时断路器打开，请求就不能真正地访问到服务了。

5.jpeg

一般而言，熔断状态不会一直持续，而是有一个时间范围，时间过了以后再去尝试请求服务提供者，一旦服务提供者的服务能力恢复，请求将继续可以调用服务提供者。

断路器的状态转换图如下：

6.png

• 断路器默认处于“关闭”状态，当服务提供者的错误率到达阈值，就会触发断路器“开启”。
• 断路器开启后进入熔断时间，到达熔断时间终点后重置熔断时间，进入“半开启”状态
• 在半开启状态下，如果服务提供者的服务能力恢复，则断路器关闭熔断状态。进而进入正常的服务状态。
• 在半开启状态下，如果服务提供者的服务能力未能恢复，则断路器再次触发服务熔断，进入熔断时间。

3、降级

服务熔断通常适与服务降级配合使用。在服务发生熔断后，一般会让请求走事先配置的处理方法，这个处理方法就是一个降级逻辑。

简言之，服务降级是一种兜底的服务策略，体现了一种“实在不行就怎么这么样”的思想。想去北京买不到飞机票，实在不行就坐高铁去吧；感冒了想去看病挂不上号，实在不行就先回家吃点药睡一觉吧；实在不行之后的处理方法，被称为fallback方法。

当服务提供者故障触发调用者服务的熔断机制，服务调用者就不再调用远程服务方法，而是调用本地的fallback方法。此时你需要预先提供一个处理方法，作为服务降级之后的执行方法，fallback返回值一般是设置的默认值或者来自缓存。

7.png

除了可以在服务调用端实现服务降级，还可以在服务提供端实现服务降级。

8.png

实际上在大型的微服务系统中，服务提供者和服务消费者并没有严格的区分，很多的服务既是提供者，也是消费者。

4、限流

4.1 为什么需要限流

举一个我们生活中的例子：一些热门的旅游景点，往往会对每日的旅游参观人数有严格的限制，比如厦门的鼓浪屿、北京的故宫等，每天只会卖出固定数目的门票，如果你去的晚了，可能当天的票就已经卖完了，当天就无法进去游玩了。

为什么旅游景点要做这样的限制呢？多卖一些门票多赚一些钱岂不是更好？

原因在于景点的服务资源是有限的，每日能服务的人数是有限的，一旦放开限制了，景点的工作人员就会不够用，卫生情况也得不到保障，安全也有隐患，超密集的人群也会严重的影响游客的体验。 但由于景区名气大，来游玩的旅客络绎不绝，远超出了景区的承载能力，因此景区只好做出限制每日人员流量的举措。

同理，在IT软件行业中，系统服务也是这样的。

服务限流是指当系统资源不够，不足以应对大量请求，即系统资源与访问量出现矛盾的时候，我们为了保证有限的资源能够正常服务，因此对系统按照预设的规则进行流量限制或功能限制的一种方法。

如果你的系统理论是时间单位内可服务100W用户，但是今天却突然来了300W用户，由于用户流量的随机性，如果不加以限流，很有可能这300W用户一下子就压垮了系统，导致所有人都得不到服务。

因此为了保证系统至少还能为100W用户提供正常服务，我们需要对系统进行限流设计。

有的人可能会想，既然会有300W用户来访问，那为啥系统不干脆设计成能足以支撑这么大量用户的集群呢？

这是个好问题。如果系统是长期有300W的用户来访问，肯定是要做上述升级的，但是常常面临的情况是，系统的日常访问量就是100W，只不过偶尔有一些不可预知的特定原因导致的短时间的流量激增，这个时候，公司往往出于节约成本的考虑，不会为了一个不常见的尖峰来把我们的系统扩容到最大的尺寸。

转载自
作者：冰河winner
链接：https://www.jianshu.com/p/5d2b7cea1f11
来源：简书