从零开始 Spring Cloud 12：Sentinel

从零开始 Spring Cloud 12：Sentinel

1.初识 Sentinel

1.1雪崩问题

1.1.1什么是雪崩问题

微服务中，服务间调用关系错综复杂，一个微服务往往依赖于多个其它微服务。

如图，如果服务提供者I发生了故障，当前的应用的部分业务因为依赖于服务I，因此也会被阻塞。此时，其它不依赖于服务I的业务似乎不受影响。

但是，依赖服务I的业务请求被阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞：

服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，那么当前服务也就不可用了。

那么，依赖于当前服务的其它服务随着时间的推移，最终也都会变的不可用，形成级联失败，雪崩就发生了：

简单来说，雪崩就是当调用链上的某个微服务出现故障，导致整个调用链上的微服务不可访问。

1.1.2.超时处理

可以在访问服务时设置请求的响应超时时长，超过响应时长的请求中断并返回错误信息，这样可以缓解雪崩发生的概率。

如果请求产生的速度快于响应等待超时并关闭连接的速度，依然会可能发生雪崩。

1.1.3.舱壁模式

仓壁模式来源于船舱的设计：

船舱都会被隔板分离为多个独立空间，当船体破损时，只会导致部分空间进入，将故障控制在一定范围内，避免整个船体都被淹没。

于此类似，我们可以限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，因此也叫线程隔离。

1.1.4.降级熔断

断路器模式：由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。

断路器会统计访问某个服务的请求数量，异常比例：

当发现访问服务D的请求异常比例过高时，认为服务D有导致雪崩的风险，会拦截访问服务D的一切请求，形成熔断：

1.1.5.限流

流量控制：限制业务访问的QPS，避免服务因流量的突增而故障。

限流只能避免因请求过多导致的服务故障以及因此产生的雪崩，但现实中服务产生故障的原因是多种多样的。

1.1.6.总结

限流是对服务的保护，避免因瞬间高并发流量而导致服务故障，进而避免雪崩。是一种预防措施。

超时处理、线程隔离、降级熔断是在部分服务故障时，将故障控制在一定范围，避免雪崩。是一种补救措施。

关于以上内容的详细说明，可以观看这个视频。

1.2.服务保护技术对比

在SpringCloud当中支持多种服务保护技术：

• Netfix Hystrix
• Sentinel
• Resilience4J

早期比较流行的是Hystrix框架，但目前国内实用最广泛的还是阿里巴巴的Sentinel框架，这里我们做下对比：

	Sentinel	Hystrix
隔离策略	信号量隔离	线程池隔离/信号量隔离
熔断降级策略	基于慢调用比例或异常比例	基于失败比率
实时指标实现	滑动窗口	滑动窗口（基于 RxJava）
规则配置	支持多种数据源	支持多种数据源
扩展性	多个扩展点	插件的形式
基于注解的支持	支持	支持
限流	基于 QPS，支持基于调用关系的限流	有限的支持
流量整形	支持慢启动、匀速排队模式	不支持
系统自适应保护	支持	不支持
控制台	开箱即用，可配置规则、查看秒级监控、机器发现等	不完善
常见框架的适配	Servlet、Spring Cloud、Dubbo、gRPC 等	Servlet、Spring Cloud Netflix

1.3.Sentinel 介绍和安装

1.3.1.初识 Sentinel

Sentinel是阿里巴巴开源的一款微服务流量控制组件。

Sentinel 具有以下特征:

•丰富的应用场景：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。

•完备的实时监控：Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。

•广泛的开源生态：Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。

•完善的 SPI 扩展点：Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。

1.3.2.安装

可以从 Github 的 Release 页面下载。

这里提供一个百度云的下载。

程序本体是一个基于 Spring Boot 开发的 jar 包，通过相关 java 命令即可运行：

java -jar sentinel-dashboard-1.8.1.jar

如果要修改Sentinel的默认端口、账户、密码，可以通过下列配置：

配置项	默认值	说明
server.port	8080	服务端口
sentinel.dashboard.auth.username	sentinel	默认用户名
sentinel.dashboard.auth.password	sentinel	默认密码

例如，修改端口：

java -Dserver.port=8090 -jar sentinel-dashboard-1.8.1.jar

启动后访问对应的端口就能看到 Sentinel 的控制台（我这里是 http://localhost:8080/），默认账户和密码都是sentinel。

1.4.微服务整合 Sentinel

这里我们使用之前学习创建的示例项目 cloud-demo 进行学习和演示。

加载项目并运行。

• 可能需要修改项目关联的 MySQL 信息以及 Nacos 信息。
• 该项目使用 Nacos 用于服务发现，需要提前运行 Nacos。

启动项目中的两个微服务 order-service 和 user-service，成功启动后访问接口 http://localhost:8088/order/101，会看到返回内容。

为需要整合 Sentinel 的微服务（这里是 order-service）添加依赖：

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

在微服务的配置文件中添加 Sentinel 控制台的相关配置信息：

spring:
  cloud:
    sentinel:
      transport:
        dashboard: localhost:8080

添加好后重启微服务。

再次请求微服务的接口（这里是 http://localhost:8088/order/101），然后观察 Sentinel 的控制台：

可以看到微服务接口的访问状况。

2.流量控制

可以通过控制对微服务的访问流量来预防雪崩的发生。

2.1.簇点链路

当请求进入微服务时，首先会访问DispatcherServlet，然后进入Controller、Service、Mapper，这样的一个调用链就叫做簇点链路。簇点链路中被监控的每一个接口就是一个资源。

默认情况下sentinel会监控SpringMVC的每一个端点（Endpoint，也就是controller中的方法），因此SpringMVC的每一个端点（Endpoint）就是调用链路中的一个资源。

如果要对簇点链路上的其它节点进行监控，就需要使用 Sentinel 的注解。

例如，我们刚才访问的order-service中的OrderController中的端点：/order/{orderId}

流控、熔断等都是针对簇点链路中的资源来设置的，因此我们可以点击对应资源后面的按钮来设置规则：

• 流控：流量控制
• 降级：降级熔断
• 热点：热点参数限流，是限流的一种
• 授权：请求的权限控制

2.2.1.示例

这里通过示例说明如何用 Sentinel 对微服务接口实现限流。

首先对要限流的接口对应的资源设置流控规则：

针对来源default说明对任意来源施加限制，阈值设置为QPS=5说明对接口施加的限制是每秒访问次数不能超过5次。

可以使用测试工具 Jmeter 模拟对接口的访问。

打开 Jmeter，加载测试样例：

选择流控入门，这个方案在2秒内会请求接口20次，即QPS=10。右键启动以执行该测试方案。

可以在结果中看到对接口请求5次成功后出现5次失败。

对示例步骤有疑惑的可以查看这个视频

2.2.流控模式

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

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

之前演示的就是直接模式。

2.2.1.关联模式

关联模式：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流

关联模式的应用场景是，如果有2个资源存在竞争关系，其中一个存在大量请求时会影响另一个的性能，且这两个资源有优先级区别，我们需要在某一个高优先级的资源存在大量访问时确保其不会请求失败，此时就可以创建一个关联模式，在高优先级资源的 QPS 超过某个阈值时通过限制另一个关联资源的访问来确保高优先级资源的可用性。

下面用具体案例来说明。

假设项目中存在两个接口，一个用于更新订单，另一个用于查询订单。显然这两个接口都会访问数据库中的订单表，如果访问的是同一个订单数据，就会触发表级锁，对数据的修改会影响到数据的读取，反之亦然。

显然这两个接口存在优先级关系，相比之下我们要尽可能让更新订单的接口不要失败。因此在这里可以使用关联模式对读取订单的接口进行限制。

先创建两个用于模拟的接口：

// ...
@RestController
@RequestMapping("order")
public class OrderController {
   
	// ...
    @GetMapping("/query")
    public String getOrderInfo(){
   
        return "订单内容";
    }

    @GetMapping("/update