谈及微服务保护的问题之前,我们先要明确一下雪崩问题.

在分布式系统中,由于网络原因或自身的原因,服务一般无法保证 100% 可用。如果一个服务出现了问题，调用这个服务就会出现线程阻塞的情况，此时若有大量的请求涌入，就会出现多条线程阻塞等待，进而导致服务瘫痪。

由于服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的 “雪崩效应” 。

雪崩发生的原因多种多样，有不合理的容量设计，或者是高并发下某一个方法响应变慢，亦或是某台机器的资源耗尽。我们无法完全杜绝雪崩源头的发生，只有做好足够的容错，保证在一个服务发生问题，不会影响到其它服务的正常运行。也就是＂雪落而不雪崩＂。

解决雪崩问题的常见方式有四种：

超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待
舱壁模式：限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，因此也叫线程隔离。
熔断降级：由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求
流量控制：限制业务访问的QPS，避免服务因流量的突增而故障

常见的两种服务保护技术的对比:Sentinel对比Hystrix:

一.认识Sentinel

Sentinel是阿里巴巴开源的一款微服务流量控制组件。官网地址：https://sentinelguard.io/zh-cn/index.html
Sentinel 具有以下特征:

丰富的应用场景：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
完备的实时监控：Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。
广泛的开源生态：Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。
完善的 SPI 扩展点：Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。

二.Sentinel控制台的安装

解压后,在文件所在位置用命令窗口输入命令的方式运行该jar包

java -jar + 文件名

默认的端口号为8080,我们可以在其中添加命令来改变端口号

java -Dserver.port=8000 -jar + 文件名

除了修改端口号,还有如下配置可以修改:

启动以后,我们可以在浏览器中输入对应的端口号来进入ui界面:

初始的账号和密码都为:sentinel 我们可以通过在启动时添加配置项的方式修改密码

输入密码以后就会来到这个界面.

三.微服务整合Sentinel

我们可以给需要的微服务中都整合上sentinel,网关服务可以不用加.

1.引入依赖


<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

2.修改 配置文件

在配置文件中配置上控制台的URL地址.

spring.cloud.sentinel.transport.dashboard=localhost:8000

3.重启微服务,查看控制台

.(记得先访问一次才能在控制台中显示)

可以看到我们的微服务已经整合上了sentinel.

四.限流规则

簇点链路

首先我们要了解一下簇点链路.

簇点链路：就是项目内的调用链路，链路中被监控的每个接口就是一个资源。默认情况下sentinel会监控SpringMVC的每一个端点（Endpoint），因此SpringMVC的每一个端点（Endpoint）就是调用链路中的一个资源。
流控、熔断等都是针对簇点链路中的资源来设置的，因此我们可以点击对应资源后面的按钮来设置规则：

1.快速入门

点击资源/product/getById/{id}后面的流控按钮，就可以弹出表单。表单中可以添加流控规则，如下图所示：

做个案例:给 /product/getById/{id}这个资源设置流控规则，QPS不能超过 5。然后利用jemeter测试。

(1)
设置流控规则：

这里可以查看我们的流控规则:

(2)使用Jemeter(压测工具)测试：

理论上来说,我们一秒发送20次请求,会有15个请求会失败,让我们看看结果如何:

虽然结果并不是15个被拦截,但是已经证明我们的流控规则已经生效了,可以看到前五个请求可以正常发出,但是第六个开始就请求失败了,也许这些失败的请求导致Jemeter的并发出现了问题,让这20个请求没有在同一秒内发出,所以并不是理想值.我们可以实验QPS为1然后让每秒发送两个请求:

这次试验结果就符合预想了,所以问题不是我们的sentinel,而是压测工具.

2.流控模式:

在添加限流规则时，点击高级选项，可以选择三种流控模式：

直接：统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认的模式
关联：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流
链路：统计从指定链路访问到本资源的请求，触发阈值时，对指定链路限流

我们上面的入门运用的就是直接模式,下面给大家演示关联模式和链路模式.

2.1流控模式----关联

关联模式：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流
使用场景：比如用户支付时需要修改订单状态，同时用户要查询订单。查询和修改操作会争抢数据库锁，产生竞争。业务需求是有限支付和更新订单的业务，因此当修改订单业务触发阈值时，需要对查询订单业务限流。

满足下面条件可以使用关联模式：

两个有竞争关系的资源
一个优先级较高，一个优先级较低

案例:当修改的并发请求量大时,限制对查询的请求(我们可以理解为修改的优先级要大于查询的优先级).

(1)在ProductController新建两个端点：/product/query和/product/update,无需实现业务

(2)配置流控规则，当/product/update资源被访问的QPS超过5时，对/product/query请求限流

要明确,对谁限流,就对谁设置,所以我们应该对/product/query进行设置.

(3)在Jemeter中对/peoduct/update进行压测,让他每秒的请求量大于5,然后在浏览器中访问/product/query,查看是否可以访问

可以看到product/query已经无法成功访问,证明关联模式流控规则生效.

2.2流控模式----链路

链路流控模式指的是，当从某个接口过来的资源达到限流条件时，开启限流。它的功能有点类似于针对来源配置项，区别在于：针对来源是针对上级微服务，而链路流控是针对上级接口，也就是说它的粒度更细。

例如有两条请求链路：
/test1 -> /common
/test2 -> /common

如果只希望统计从/test2进入到/common的请求，则可以这样配置：

案例:

(1) 我们在ProductController中还是运用关联模式创建的两个端口,让他们都去访问同一个service方法(getMsg),该service方法不需要实现内容.

这里我们要注意一点,Sentinel默认只会标记Controller中的方法为资源,如果想要将service中的方法标记为资源,则需要在service层对应的方法上加@SentinelResource注解,并且在配置文件中追加配置,关闭context整合,才能使该注解生效:

spring.cloud.sentinel.web-context-unify=false

然后重启该服务.在Sentinel控制台中就可以看到我们新添加的资源:"getMsg".(记得先访问一次才能在控制台中显示)

(2) 我们可以对product/query->getMsg这条链路做流控规则.对该链路访问的QPS限制为2

使用压测工具Jemeter同时对product/query 和 prodcut/update两条链路做压测,让他们2秒内都请求10次.

product/query:

product/update:

理论结果应该是:update中的请求全部成功,query中的请求每秒只允许通过2个.让我们看结果:

product/query:

product/update:

实验结果表示流控规则----链路模式设置成功.

3.流控效果

流控效果是指请求达到流控阈值时应该采取的措施，包括三种：
快速失败：达到阈值后，新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式。
warm up：预热模式，对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化，从一个较小值逐渐增加到最大阈值。
排队等待：让所有的请求按照先后次序排队执行，两个请求的间隔不能小于指定时长

我们上面在测试流控模式的时候,效果运用的都是快速失败,下面主要讲解一下预热效果和排队等待.

3.1流控效果----预热模式

warm up也叫预热模式，是应对服务冷启动的一种方案。请求阈值初始值是 threshold / coldFactor，持续指定时长后，逐渐提高到threshold值。而coldFactor的默认值是3.
例如，我设置QPS的threshold为10，预热时间为5秒，那么初始阈值就是 10 / 3 ，也就是3，然后在5秒后逐渐增长到10.预热模式适合处理激增形式的流量.

案例:

我们给product/query这个资源设置限流，最大QPS为10，利用warm up效果，预热时长为5秒

(1)设置流控规则:

(2)在Jemeter中进行压测该资源,让他每秒发送10次请求,持续7秒:

让我们运行并查看结果:

从图中可以看出,一开始,每秒发送的10次请求只能通过三个,到中间慢慢的每秒通过的请求逐渐增多,到最后每秒发送的10次请求全部通过.这符合我们一开始设置的预热效果.

3.2流控效果----排队等待

当请求超过QPS阈值时，快速失败和warm up 会拒绝新的请求并抛出异常。而排队等待则是让所有请求进入一个队列中，然后按照阈值允许的时间间隔依次执行。后来的请求必须等待前面执行完成，如果请求预期的等待时间超出最大时长，则会被拒绝。
例如：QPS = 5，意味着每200ms处理一个队列中的请求；timeout = 2000，意味着预期等待超过2000ms的请求会被拒绝并抛出异常

排队等待适合处理脉冲型的流量:当流量波形为脉冲形式时(即一阵流量大一阵流量小,形成脉冲的形式),我们可以利用起流量少的时间,作为排队等待时间.让QPS过滤掉的请求在等待时间内去处理,等待时间过了没有处理的请求都让他直接失败.