服务容错及解决方案

背景

随着美团点评服务框架和服务治理体系的逐步成熟，服务化已成为公司内部系统设计的趋势。本着大系统小做、职责单一的原则，我们度假技术团队对业务系统进行了不少服务化拆分工作。随着业务复杂度的增加，依赖的服务也逐步增加，出现了不少由于服务调用出现异常问题而导致的重大事故，如：

1）系统依赖的某个服务发生延迟或者故障，数秒内导致所有应用资源（线程，队列等）被耗尽，造成所谓的雪崩效应 (Cascading Failure)，导致整个系统拒绝对外提供服务。

2）系统遭受恶意爬虫袭击，在放大效应下没有对下游依赖服务做好限速处理，最终导致下游服务崩溃。

容错是一个很大的话题，受篇幅所限，本文将介绍仅限定在服务调用间常用的一些容错模式。

设计原则

服务容错的设计有个基本原则，就是“Design for Failure”。为了避免出现“千里之堤溃于蚁穴”这种情况，在设计上需要考虑到各种边界场景和对于服务间调用出现的异常或延迟情况，同时在设计和编程时也要考虑周到。这一切都是为了达到以下目标：

1）一个依赖服务的故障不会严重破坏用户的体验。

2）系统能自动或半自动处理故障，具备自我恢复能力。

基于这个原则和目标，衍生出下文将要介绍的一些模式，能够解决分布式服务调用中的一些问题，提高系统在故障发生时的存活能力。

一些经典的容错模式
所谓模式，其实就是某种场景下一类问题及其解决方案的总结归纳，往往可以重用。模式可以指导我们完成任务，作出合理的系统设计方案，达到事半功倍的效果。而在服务容错这个方向，行业内已经有了不少实践总结出来的解决方案。

超时与重试

（Timeout and Retry）
超时模式，是一种最常见的容错模式，在美团点评的工程实践中大量存在。常见的有设置网络连接超时时间，一次RPC的响应超时时间等。在分布式服务调用的场景中，它主要解决了当依赖服务出现建立网络连接或响应延迟，不用无限等待的问题，调用方可以根据事先设计的超时时间中断调用，及时释放关键资源，如Web容器的连接数，数据库连接数等，避免整个系统资源耗尽出现拒绝对外提供服务这种情况。

重试模式

，一般和超时模式结合使用，适用于对于下游服务的数据强依赖的场景（不强依赖的场景不建议使用！），通过重试来保证数据的可靠性或一致性，常用于因网络抖动等导致服务调用出现超时的场景。与超时时间设置结合使用后，需要考虑接口的响应时间分布情况，超时时间可以设置为依赖服务接口99.5%响应时间的值，重试次数一般1-2次为宜，否则会导致请求响应时间延长，拖累到整个系统。

服务雪崩

而此时，Service A的流量波动很大，流量经常会突然性增加！那么在这种情况下，就算Service A能扛得住请求，Service B和Service C未必能扛得住这突发的请求。
此时，如果Service C因为抗不住请求，变得不可用。那么Service B的请求也会阻塞，慢慢耗尽Service B的线程资源，Service B就会变得不可用。紧接着，Service A也会不可用，这一过程如下图所示

如上图所示，一个服务失败，导致整条链路的服务都失败的情形，我们称之为服务雪崩。

ps：谁发明的这个词，真是面试装13必备！

那么，服务熔断和服务降级就可以视为解决服务雪崩的手段之一。

服务熔断
那么，什么是服务熔断呢？
服务熔断：当下游的服务因为某种原因突然变得不可用或响应过慢，上游服务为了保证自己整体服务的可用性，不再继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。
需要说明的是熔断其实是一个框架级的处理，那么这套熔断机制的设计，基本上业内用的是断路器模式，如Martin Fowler提供的状态转换图如下所示

最开始处于closed状态，一旦检测到错误到达一定阈值，便转为open状态；
这时候会有个 reset timeout，到了这个时间了，会转移到half open状态；
尝试放行一部分请求到后端，一旦检测成功便回归到closed状态，即恢复服务；
业内目前流行的熔断器很多，例如阿里出的Sentinel,以及最多人使用的Hystrix
在Hystrix中，对应配置如下

//滑动窗口的大小，默认为20
circuitBreaker.requestVolumeThreshold 
//过多长时间，熔断器再次检测是否开启，默认为5000，即5s钟
circuitBreaker.sleepWindowInMilliseconds 
//错误率，默认50%
circuitBreaker.errorThresholdPercentage

每当20个请求中，有50%失败时，熔断器就会打开，此时再调用此服务，将会直接返回失败，不再调远程服务。直到5s钟之后，重新检测该触发条件，判断是否把熔断器关闭，或者继续打开。

这些属于框架层级的实现，我们只要实现对应接口就好！

服务降级
那么，什么是服务降级呢？
这里有两种场景:

当下游的服务因为某种原因响应过慢，下游服务主动停掉一些不太重要的业务，释放出服务器资源，增加响应速度！
当下游的服务因为某种原因不可用，上游主动调用本地的一些降级逻辑，避免卡顿，迅速返回给用户！
其实乍看之下，很多人还是不懂熔断和降级的区别!

其实应该要这么理解:

服务降级有很多种降级方式！如开关降级、限流降级、熔断降级!
服务熔断属于降级方式的一种！
可能有的人不服，觉得熔断是熔断、降级是降级，分明是两回事啊！其实不然，因为从实现上来说，熔断和降级必定是一起出现。因为当发生下游服务不可用的情况，这个时候为了对最终用户负责，就需要进入上游的降级逻辑了。因此，将熔断降级视为降级方式的一种，也是可以说的通的！</