服务容错及解决方案

背景

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

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钟之后，重新检测该触发条件，判断是否把熔断器关闭，或者继续打开。

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

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

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

其实应该要这么理解:

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

我撇开框架，以最简单的代码来说明！上游代码如下

try{
    //调用下游的helloWorld服务
    xxRpc.helloWorld();
}catch(Exception e){
    //因为熔断，所以调不通
    doSomething();
}

注意看，下游的helloWorld服务因为熔断而调不通。此时上游服务就会进入catch里头的代码块，那么catch里头执行的逻辑，你就可以理解为降级逻辑!
什么，你跟我说你不捕捉异常，直接丢页面？
OK，那我甘拜下风，当我理解错误!

服务降级大多是属于一种业务级别的处理。当然，我这里要讲的是另一种降级方式，也就是开关降级!这也是我们生产上常用的另一种降级方式！

做法很简单，做个开关，然后将开关放配置中心！在配置中心更改开关，决定哪些服务进行降级。至于配置变动后，应用怎么监控到配置发生了变动，这就不是本文该讨论的范围。
那么，在应用程序中部下开关的这个过程，业内也有一个名词，称为埋点！

那接下来最关键的一个问题，哪些业务需要埋点？
一般有以下方法
(1)简化执行流程
自己梳理出核心业务流程和非核心业务流程。然后在非核心业务流程上加上开关，一旦发现系统扛不住，关掉开关，结束这些次要流程。

(2)关闭次要功能
一个微服务下肯定有很多功能，那自己区分出主要功能和次要功能。然后次要功能加上开关，需要降级的时候，把次要功能关了吧！

(3)降低一致性
假设，你在业务上发现执行流程没法简化了，愁啊！也没啥次要功能可以关了，桑心啊！那只能降低一致性了，即将核心业务流程的同步改异步，将强一致性改最终一致性！

可是这些都是手动降级，有办法自动降级么？
这里我摸着良心说，我们在生产上没弄自动降级！因为一般需要降级的场景，都是可以预见的，例如某某活动。假设，平时真的有突发事件，流量异常，也有监控系统发邮件通知，提醒我们去降级！
当然，这并不代表自动降级不能做，因此以下内容可以认为我在胡说八道，因为我在生产上没实践过，只是头脑大概想了下，如果让我来做自动降级我会怎么实现：

(1)自己设一个阈值，例如几秒内失败多少次，就启动降级
(2)自己做接口监控(有兴趣的可以了解一下Rxjava)，达到阈值就走推送逻辑。怎么推呢？比如你配置是放在git上，就用jgit去改配置中心的配置。如果配置放数据库，就用jdbc去改。
(3)改完配置中心的配置后，应用就可以自动检测到配置的变化，进行降级！(这句不了解的，了解一下配置中心的热刷新功能)

限流熔断降级

1. 熔断

1.1 熔断来源
我们家用电闸上都有保险丝模块，当电压出现短路问题时，自动跳闸，此刻电路主动断开，我们的电器就会收到保护。否则，不能断开，后果不堪设想。

保险丝就是一个自我保护装置，保护整个电路。

1.2 分布式系统中的熔断
在分布式系统中，我们往往需要依赖下游服务，不管是内部系统还是第三方服务，如果下游出现问题，我们还是盲目地去请求，及时失败了多次，还是傻傻的去请求，去等待。

这样，
一是增加了整个链路的请求时间
第二，下游系统本身就出现了问题，不断的请求又把系统问题加重了，恢复困难。

1.3 熔断的作用
熔断模式可以防止应用程序不断地尝试可能超时和失败的服务，能达到应用程序执行而不必等待下游服务修正错误服务。

熔断器模式最牛的是能让应用程序自我诊断下游系统的错误是否已经修正，如果没有，不放量去请求，如果请求成功了，慢慢的增加请求，再次尝试调用。

1.4 像不像代理模式？
熔断器模式像那些，容易导致错误操作的，一种代理
这种代理能够记录调用发生的错误次数，并根据次数，自我决定是否继续调用还是立刻返回错误。

比如说A服务调用B服务，B服务是下游的服务提供，或者是第三方服务，容易发生问题。这样既能防止不断的调用，是下游服务更坏，保护了下游方，还能降低自己的执行成本，快速的响应，减少延迟，增加吞吐量。

业内目前流行的熔断器很多，例如阿里出的Sentinel,以及最多人使用的Hystrix。

2. 降级

2.1 降级的本质
降级就是为了解决资源不足和访问量增加的矛盾

在有限的资源情况下，为了能抗住大量的请求，就需要对系统做出一些牺牲，有点“弃卒保帅”的意思。放弃一些功能，保证整个系统能平稳运行

2.2 降级牺牲的是什么？

强强一致性变成最终一致性
大多数的系统是不需要强一致性的。
强一致性就要求多种资源的占用，减少强一致性就能释放更多资源
这也是我们一般利用消息中间件来削峰填谷，变强一致性为最终一致性，也能达到效果

干掉一些次要功能
停止访问不重要的功能，从而释放出更多的资源
举例来说，比如电商网站，评论功能流量大的时候就能停掉，当然能不直接干掉就别直接，最好能简化流程或者限流最好

简化功能流程。把一些功能简化掉

2.3 降级的注意点

对业务进行仔细的梳理和分析
哪些是核心流程必须保证的，哪些是可以牺牲的

什么指标下能进行降级

吞吐量、响应时间、失败次数等达到一个阈值才进行降级处理

如何降级
降级最简单的就是在业务代码中配置一个开关或者做成配置中心模式，直接在配置中心上更改配置，推送到相应的服务。

3. 限流

3.1 限流的目的

通过对并发访问进行限速。

3.2 限流有哪些行为

拒绝服务

最简单的方式，把多余的请求直接拒绝掉

做的高大上一些，可以根据一定的用户规则进行拒绝策略。

服务降级

降级甚至关掉后台的某些服务。

特权请求

在多租户或者对用户进行分级时，可以考虑让一些特殊的用户有限处理，其他的可以考虑干掉

延时处理

可以利用队列把请求缓存住。削峰填谷。

3.3 限流的实现方式

计数器

最简单的实现方式 ，维护一个计数器，来一个请求计数加一，达到阈值时，直接拒绝请求。

一般实践中用 ngnix + lua + redis 这种方式，redis 存计数值

漏斗模式

流量就像进入漏斗中的水一样，而出去的水和我们系统处理的请求一样，当流量大于漏斗的流出速度，就会出现积水，水对了会溢出。

漏斗很多是用一个队列实现的，当流量过多时，队列会出现积压，队列满了，则开始拒绝请求。

令牌桶

看图例，令牌通和漏斗模式很像，主要的区别是增加了一个中间人，这个中间人按照一定的速率放入一些token，然后，处理请求时，需要先拿到token才能处理，如果桶里没有token可以获取，则不进行处理。

3.4 限流的一些注意点

限流越早设计约好，架构成型后，不容易加入

限流模块不要成为系统的瓶颈，性能要求高

最好有个开关，可以直接介入

限流发生时，能及时发出通知事件

限流发生时，给用户提供友好的提示 。

4. 三者的关系

熔断强调的是服务之间的调用能实现自我恢复的状态；

限流是从系统的流量入口考虑，从进入的流量上进行限制，达到保护系统的作用；

降级，是从系统内部的平级服务或者业务的维度考虑，流量大了，可以干掉一些，保护其他正常使用；

熔断是降级方式的一种；

降级又是限流的一种方式；

三者都是为了通过一定的方式去保护流量过大时，保护系统的手

sentinel概念

Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

sentinel控制台的概念
Sentinel控制台(sentinel-dashboard)是流量控制、熔断降级规则统一配置和管理的入口，它为用户提供了机器自发现、簇点链路自发现、监控、规则配置等功能。在 Sentinel 控制台上，我们可以配置规则并实时查看流量控制效果。

sentinel-dashboard控制台的下载和安装

注意点
sentinel-dashboard控制台只能进行单机部署。但是阿里巴巴同时提供了AHAS Sentinel企业级的控制台实现高可用，同时提供更加详细的数据展示和告警措施，这里不再详述，有意者自己去学习。
启动 Sentinel 控制台需要 JDK 版本为 1.8 及以上版本
若您的应用为 Spring Boot 或 Spring Cloud 应用，您可以通过 Spring 配置文件来指定配置
依赖引用
注意：依赖引入事一定要注意和自己使用的springboot版本的对应，否者很可能无法正常使用

在父级模块进行管理alibaba的依赖

<dependencyManagement>
   <dependencies>
     <dependency>
                <groupId>com.alibaba.cloud</groupId>
                <artifactId>spring-cloud-alibaba-dependencies</artifactId>
                <version>2.1.0.RELEASE</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
      </dependencies>
</dependencyManagement>
在相应的业务模块引入sentinel模块的依赖
<dependency>
   <groupId>com.alibaba.cloud</groupId>
   <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
      <exclusions>
         <exclusion>
            <groupId>com.fasterxml.jackson.dataformat</groupId>
            <artifactId>jackson-dataformat-xml</artifactId>
         </exclusion>
      </exclusions>
</dependency>

与springboot整合配置
　　我使用的springboott项目版本为2.2.6.RELEASE，但我的项目只是一个简单的springboot项目并非springcloud和dubbo项目，如果想在springcloud或者dubbo集群项目中使用，还需要因为引入相应的适配器模块，具体的可以参看GitHub中相关文档，文章最后会附上链接。

其实sentinel和springboot的整合非常简单，只需要几个基本的配置即可，更多的配置github文档中有详细的介绍。

注解解读
@SentinelResource 注解
　　Sentinel 提供了 @SentinelResource 注解用于定义资源，并提供了 AspectJ 的扩展用于自动定义资源、处理 BlockException等。使用 Sentinel Annotation AspectJ Extension 的时候需要引入以下依赖：

com.alibaba.csp sentinel-annotation-aspectj x.y.z 注解中的配置项解读：

value：资源名称，必需项（不能为空）
entryType：entry 类型，可选项（默认为 EntryType.OUT）
blockHandler / blockHandlerClass: blockHandler 对应处理 BlockException 的函数名称，可选项。blockHandler 函数访问范围需要是 public，返回类型需要与原方法相匹配，参数类型需要和原方法相匹配并且最后加一个额外的参数，类型为 BlockException。blockHandler 函数默认需要和原方法在同一个类中。若希望使用其他类的函数，则可以指定 blockHandlerClass 为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则无法解析。
fallback / fallbackClass：fallback 函数名称，可选项，用于在抛出异常的时候提供 fallback 处理逻辑。fallback 函数可以针对所有类型的异常（除了 exceptionsToIgnore 里面排除掉的异常类型）进行处理。fallback 函数签名和位置要求：
返回值类型必须与原函数返回值类型一致；
方法参数列表需要和原函数一致，或者可以额外多一个 Throwable 类型的参数用于接收对应的异常。
fallback 函数默认需要和原方法在同一个类中。若希望使用其他类的函数，则可以指定 fallbackClass 为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则无法解析。
defaultFallback（since 1.6.0）：默认的 fallback 函数名称，可选项，通常用于通用的 fallback 逻辑（即可以用于很多服务或方法）。默认 fallback 函数可以针对所有类型的异常（除了 exceptionsToIgnore 里面排除掉的异常类型）进行处理。若同时配置了 fallback 和 defaultFallback，则只有 fallback 会生效。defaultFallback 函数签名要求：exceptionsToIgnore（since 1.6.0）：用于指定哪些异常被排除掉，不会计入异常统计中，也不会进入 fallback 逻辑中，而是会原样抛出。
返回值类型必须与原函数返回值类型一致；
方法参数列表需要为空，或者可以额外多一个 Throwable 类型的参数用于接收对应的异常。
defaultFallback 函数默认需要和原方法在同一个类中。若希望使用其他类的函数，则可以指定 fallbackClass 为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则无法解析。
　　特别地，若 blockHandler 和 fallback 都进行了配置，则被限流降级而抛出 BlockException 时只会进入 blockHandler 处理逻辑。若未配置 blockHandler、fallback 和 defaultFallback，则被限流降级时会将 BlockException 直接抛出（若方法本身未定义 throws BlockException 则会被 JVM 包装一层 UndeclaredThrowableException）。

从 1.4.0 版本开始，注解方式定义资源支持自动统计业务异常，无需手动调用 Tracer.trace(ex) 来记录业务异常。Sentinel 1.4.0 以前的版本需要自行调用 Tracer.trace(ex) 来记录业务异常。

注意点：

注解方式埋点不支持 private 方法
1.6.0 之前的版本 fallback 函数只针对降级异常（DegradeException）进行处理，不能针对业务异常进行处理
一般推荐将 @SentinelResource 注解加到服务实现上，而在 Web 层直接使用 Spring Cloud Alibaba 自带的 Web 埋点适配。

@SentinelRestTemplate注解

持久化
sentinel本身支持多种规则配置方式：

sentinel-dashboard控制台直接配置
　　这种方式配置的规则只保存在内存中，在控制台重启的时候就会丢失所有配置的规则，这在生产环境肯定是不可取的，所以我们要把配置的规则持久化下来，这样可以保证重启服务后我们的配置规则不丢失，这也是我们会着重讲的方式。

通过Sentinel提供的SPI可扩展机制（这里不在详述）
　　这种方式可以保证我们每次启动客户端时或者控制台时都可以展示出来我们的配置规则，但是这种方式有个很大额弊端就是每次修改规则都要重新部署客户端代码。这在实际生产中肯定不行，于是有了动态配置的方式。

通过动态的配置
　　这种方式能够根据我们的需要动态的调整规则。但是这种方式同样有弊端，就是sentinel-dashboard本身无法单独完成需要外部的配置中心来配合管理规则的创建和修改，同时需要外部数据库来保证规则的持久化。具体分为两种模式：pull模式和push模式。

推送模式分为下面三种：

推送模式

说明

优点

缺点

原始模式

API 将规则推送至客户端并直接更新到内存中，扩展写数据源（WritableDataSource）

简单，无任何依赖

不保证一致性；规则保存在内存中，重启即消失。严重不建议用于生产环境

Pull 模式

扩展写数据源（WritableDataSource）， 客户端主动向某个规则管理中心定期轮询拉取规则，这个规则中心可以是 RDBMS、文件 等

简单，无任何依赖；规则持久化

不保证一致性；实时性不保证，拉取过于频繁也可能会有性能问题。

Push 模式

扩展读数据源（ReadableDataSource），规则中心统一推送，客户端通过注册监听器的方式时刻监听变化，比如使用 Nacos、Zookeeper 等配置中心。这种方式有更好的实时性和一致性保证。生产环境下一般采用 push 模式的数据源。

规则持久化；一致性；快速

引入第三方依赖

我们这里只讲解Push模式的实现。由于Nacos优秀的通信协议性能以及本身既可当规则配置中心又可作为服务注册发现中心的优势，就连springcloud目前都开放弃本身的服务注册发现中心（erruke和consule）和配置中心（springcloud config），我们有什么理由不使用它呢！并且Nacos的另个优势在于在部署集群时要比另一个著名的配置中心Appolo（携程开源的配置中心）简单的多。当然，如果各位有兴趣完全可以使用其他的配置中心，毕竟每个技术都有自己独特的优势。