微服务篇-微服务保护：使用 Sentinel 来实现请求限流、线程隔离、服务熔断和 Fallback 备用方案的使用

🔥博客主页： 【小扳_-CSDN博客】
❤感谢大家点赞👍收藏⭐评论✍

文章目录

        1.0 微服务保护

        1.1 请求限流方案

        1.2 线程隔离方案

        1.3 服务熔断方案

        2.0 Sentinel

        2.1 Sentinel 安装

        2.2 微服务整合

        3.0 Sentinel-请求限流

        4.0 Sentinel-线程隔离

        4.1 OpenFeign 整合 Sentinel

        4.2 配置线程隔离

        5.0 Sentinel-Fallback

        6.0 Sentinel-服务熔断

        6.1 配置熔断策略

---

        1.0 微服务保护

        保证服务运行的健壮性，避免级联失败导致的雪崩问题，就属于微服务保护。

        微服务保护的方案有很多，比如：

                - 请求限流

                - 线程隔离

                - 服务熔断

        这些方案或多或少都会导致服务的体验上略有下降，比如请求限流，降低了并发上限；线程

隔离，降低了可用资源数量；服务熔断，降低了服务的完整度，部分服务变的不可用或弱可用。因

此这些方案都属于服务降级的方案。但通过这些方案，服务的健壮性得到了提升。

        1.1 请求限流方案

        服务故障最重要原因，就是并发太高！解决了这个问题，就能避免大部分故障。当然，接口

的并发不是一直很高，而是突发的。因此请求限流，就是限制或控制接口访问的并发流量，避免服

务因流量激增而出现故障。

        简单来说，请求限流往往会有一个限流器，数量高低起伏的并发请求曲线，经过限流器就变

的非常平稳。这就像是水电站的大坝，起到蓄水的作用，可以通过开关控制水流出的大小，让下游

水流始终维持在一个平稳的量。

        PS：QPS 指的是服务器每秒可以处理的请求数量。

        1.2 线程隔离方案

        当一个业务接口响应时间长，而且并发高时，就可能耗尽服务器的线程资源，导致服务内的

其它接口受到影响。所以我们必须把这种影响降低，或者缩减影响的范围。线程隔离正是解决这个

问题的好办法。

线程隔离的思想来自轮船的舱壁模式：

        简单来说，就是限制不正常的接口的线程数量，防止线程资源都用到阻塞的接口从而影响其

他正常接口提供服务。

举个例子：

        给查询购物车业务限定可用线程数量上限为 20，这样即便查询购物车的请求因为查询商品服

务而出现故障，也不会导致服务器的线程资源被耗尽，不会影响到其它接口。

        1.3 服务熔断方案

        线程隔离虽然避免了雪崩问题，但故障服务（商品服务）依然会拖慢购物车服务（服务调用

方）的接口响应速度。而且商品查询的故障依然会导致查询购物车功能出现故障，购物车业务也变

的不可用了。

        因此可以使用熔断结合 Fallback 机制来解决：

        1）编写服务降级逻辑：就是服务调用失败后的处理逻辑，根据业务场景，可以抛出异常，也

可以返回友好提示或默认数据。

        2）异常统计和熔断：统计服务提供方的异常比例，当比例过高表明该接口会影响到其它服

务，应该拒绝调用该接口，而是直接走降级逻辑。

        当发现异常超过一定的数量或者慢调用到达一定的数量之后，那么就不会选择继续调用该接

口，而是走 Fallback 降级逻辑路线了。

        2.0 Sentinel

        Sentinel 是阿里巴巴开源的一款服务保护框架，目前已经加入 SpringCloudAlibaba 中。官

方网站：home | Sentinel

Sentinel 的使用可以分为两个部分:

        1）核心库（Jar包）：不依赖任何框架/库，能够运行于 Java 8 及以上的版本的运行时环

境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持。在项目中引入依赖即可实现服务限

流、隔离、熔断等功能。

        2）控制台（Dashboard）：Dashboard 主要负责管理推送规则、监控、管理机器信息等。

        2.1 Sentinel 安装

        1）下载 jar 包:Releases · alibaba/Sentinel · GitHub

        2）将 jar 包放在任意非中文、不包含特殊字符的目录下，重命名为 sentinel-

dashboard.jar，然后运行如下命令启动控制台：

java -Dserver.port=8090 -Dcsp.sentinel.dashboard.server=localhost:8090 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard.jar

        3）访问 http://localhost:8090 页面，就可以看到 sentinel 的控制台了：

需要输入账号和密码，默认都是：sentinel

        登录后，即可看到控制台，默认会监控 sentinel-dashboard 服务本身： 

        2.2 微服务整合

        连接 sentinel-dashboard 控制台，步骤如下：

        1）引入 sentinel 依赖：

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

        2）配置控制台：

        修改 application.yaml 文件，添加下面内容：

spring:cloud: sentinel:transport:dashboard: localhost:8090

        3）访问任意相关的接口：

        重启之后，然后访问查询购物车接口，sentinel 的客户端就会将服务访问的信息提交到

sentinel-dashboard 控制台。并展示出统计信息：

点击簇点链路菜单，会看到下面的页面：

        所谓簇点链路，就是单机调用链路，是一次请求进入服务后经过的每一个被 Sentinel 监控的

资源。默认情况下，Sentinel 会监控 SpringMVC 的每一个 Endpoint（接口）。

        因此，我们看到 /carts 这个接口路径就是其中一个簇点，我们可以对其进行限流、熔断、隔

离等保护措施。
 

        打开 Sentinel 的请求方式前缀，把请求方式 + 请求路径作为簇点资源名：

        添加以下配置：

spring:cloud:sentinel:transport:dashboard: localhost:8090http-method-specify: true # 开启请求方式前缀

        然后，重启服务，通过页面访问购物车的相关接口，可以看到 sentinel 控制台的簇点链路发

生了变化：

        3.0 Sentinel-请求限流

        在簇点链路后面点击流控按钮，即可对其做限流配置：

在弹出的菜单中这样填写：

        这样就把查询购物车列表这个簇点资源的流量限制在了每秒 6 个，也就是最大 QPS 为 6 。

利用 Jemeter 做限流测试，我们每秒发出 10 个请求：

最终监控结果如下：

        这个接口的通过 QPS 稳定在 6 附近，而拒绝的 QPS 在 4 附近，符合我们的预期。

        4.0 Sentinel-线程隔离

        限流可以降低服务器压力，尽量减少因并发流量引起的服务故障的概率，但并不能完全避免

服务故障。一旦某个服务出现故障，我们必须隔离对这个服务的调用，避免发生雪崩。

        比如，查询购物车的时候需要查询商品，为了避免因商品服务出现故障导致购物车服务级联

失败，我们可以把购物车业务中查询商品的部分隔离起来，限制可用的线程资源：

        这样，即便商品服务出现故障，最多导致查询购物车业务故障，并且可用的线程资源也被限

定在一定范围，不会导致整个购物车服务崩溃。

        4.1 OpenFeign 整合 Sentinel

        修改 application.yml 文件，开启 Feign 的 sentinel 功能：

feign:sentinel:enabled: true # 开启feign对sentinel的支持

        需要注意的是，默认情况下 SpringBoot 项目的 tomcat 最大线程数是 200，允许的最大连接

是 8492，单机测试很难打满。

        所以需要配置 application.yml文件，修改 tomcat 连接：

server:port: 8082tomcat:threads:max: 50 # 允许的最大线程数accept-count: 50 # 最大排队等待数量max-connections: 100 # 允许的最大连接

        再次查看购物车的查询接口情况：

        可以看到查询商品的 FeignClient 自动变成了一个簇点资源。

         4.2 配置线程隔离

        接下来，点击查询商品的 FeignClient 对应的簇点资源后端的流控按钮：

在弹出的表单中填写下面内容：

在查询商品的业务上手动添加阻塞时间从而来模拟阻塞状态：

        这里勾选的是并发线程数限制，也就是说这个查询功能最多使用 5 个线程，而不是 5 QPS。

如果查询商品的接口每秒处理 2 个请求，则 5 个线程的实际 QPS 在 10 左右，而超出的请求自然

会被拒绝。

        接着测试一下：

利用 Jemeter 测试，每秒发送 100 个请求：

测试结果：

        进入查询购物车的请求每秒大概在 100，而在查询商品时却只剩下每秒 10 左右，符合我们的

预期。

        当访问其他正常的接口的时候，响应时间非常短，这就证明线程隔离起到了作用，尽管查询

购物车这个接口并发很高，但是它能使用的线程资源被限制了，因此不会影响到其它接口。

        5.0 Sentinel-Fallback

        触发限流或熔断后的请求不一定要直接报错，也可以返回一些默认数据或者友好提示，用户

体验会更好。

给 FeignClient 编写失败后的降级逻辑有两种方式：

        方式一：FallbackClass，无法对远程调用的异常做处理

        方式二：FallbackFactory，可以对远程调用的异常做处理，一般选择这种方式。

演示方式二的失败降级处理：

        1）在模块中给 ItemClient 定义降级处理类，实现 FallbackFactory：

代码如下：

@Slf4j
public class ItemFallback implements FallbackFactory<ItemClient> {@Overridepublic ItemClient create(Throwable cause) {return new ItemClient() {@Overridepublic List<ItemDTO> queryItemByIds(Collection<Long> ids) {log.error("远程调用ItemClient#queryItemByIds方法出现异常，参数：{}", ids, cause);// 查询购物车允许失败，查询失败，返回空集合return CollUtils.emptyList();}@Overridepublic void deductStock(Collection<OrderDetailDTO> items) {// 库存扣减业务需要触发事务回滚，查询失败，抛出异常throw new BizIllegalException(cause);}};}
}

        2）ItemFallback 注册为 Bean 对象：

        3）在模块中的 ItemClient 接口中声明使用：

重启后，再次测试，发现被限流的请求不再报错，走了降级逻辑：

        不会直接报异常错误，而是走 Fallback 逻辑：

        当请求被拒绝之后会来到 Fallback 逻辑，我们写的 Fallback 逻辑就是打印日志：

        6.0 Sentinel-服务熔断

        Sentinel 中的断路器不仅可以统计某个接口的慢请求比例，还可以统计异常请求比例。当这

些比例超出阈值时，就会熔断该接口，即拦截访问该接口的一切请求，降级处理；当该接口恢复正

常时，再放行对于该接口的请求。

        断路器的工作状态切换有一个状态机来控制：

状态机包括三个状态：

        1）closed：关闭状态，断路器放行所有请求，并开始统计异常比例、慢请求比例。超过阈值

则切换到 open 状态。

        2）open：打开状态，服务调用被熔断，访问被熔断服务的请求会被拒绝，快速失败，直接

走降级逻辑。Open 状态持续一段时间后会进入 half-open 状态。

        3）half-open：半开状态，放行一次请求，根据执行结果来判断接下来的操作。 

        请求成功：则切换到 closed 状态

        请求失败：则切换到 open 状态

        6.1 配置熔断策略

        可以在控制台通过点击簇点后的熔断按钮来配置熔断策略：

        1）点击熔断：

        2）配置：

这种是按照慢调用比例来做熔断，上述配置的含义是：

        1）RT 超过 200 毫秒的请求调用就是慢调用。

        2）统计最近 1000ms 内的最少 5 次请求，如果慢调用比例不低于 0.5，则触发熔断。

        3）熔断持续时长 20 s 。

配置完成后，再次利用 Jemeter 测试，可以发现：

        在一开始一段时间是允许访问的，后来触发熔断后，查询商品服务的接口通过 QPS 直接为

0，所有请求都被熔断了。而查询购物车的本身并没有受到影响。

此时整个购物车查询服务的平均 RT 影响不大：

        希望可以帮助到你！