# 初识 Sentinel

# 雪崩问题及解决

# 雪崩问题

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

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

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

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

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

# 超时处理

# 介绍

超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待

# 图示

# 仓壁模式

# 介绍

船舱都会被隔板分离为多个独立空间，当船体破损时，只会导致部分空间进入，将故障控制在一定范围内，避免整个船体都被淹没，于此类似，我们可以限定每个业务能使用的线程数，避免耗尽整个 tomcat 的资源，因此也叫线程隔离

# 图示

# 断路器

# 介绍

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

# 图示

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

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

# 限流

# 介绍

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

# 图示

# 服务保护技术对比

# SpringCloud 多种服务保护技术

• Netfix Hystrix
• Sentinel
• Resilience4J

# Sentinel 和 Hystrix 对比

# Sentinel 介绍与安装

# Sentinel 介绍

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

# Sentinel 特征

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

# 安装 Sentinel

# 下载

sentinel 官方提供了 UI 控制台，方便我们对系统做限流设置

# 运行

java -jar sentinel-dashboard-1.8.1.jar

# 配置

例如，修改端口：

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

# 访问

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

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

# 微服务整合 Sentinel

# 引入 sentinel 依赖

<!--sentinel-->

<dependency>

    <groupId>com.alibaba.cloud</groupId> 

    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>

</dependency>

# 配置控制台（修改 yaml 文件）

server:

  port: 8088

spring:

  cloud: 

    sentinel:

      transport:

        dashboard: localhost:8080

# 访问 order-service 任意端点，除法 Sentinel 监控

# 流量控制

# 簇点链路

# 介绍

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

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

# 图示

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

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

# 用法

# 点击资源 /order/{orderId} 后面的流控按钮，就可以弹出表单

# 表单中填写限流规则

其含义是限制 /order/{orderId} 这个资源的单机 QPS 为 1，即每秒只允许 1 次请求，超出的请求会被拦截并报错

# 流控模式

# 三种流控模式

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

# 关联模式

# 配置规则

# 语法说明

当 /write 资源访问量触发阈值时，就会对 /read 资源限流，避免影响 /write 资源

# 使用场景

比如用户支付时需要修改订单状态，同时用户要查询订单。查询和修改操作会争抢数据库锁，产生竞争。业务需求是优先支付和更新订单的业务，因此当修改订单业务触发阈值时，需要对查询订单业务限流

# 代码实现

需求说明

• 在 OrderController 新建两个端点：/order/query 和 /order/update，无需实现业务

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

定义 /order/query 端点，模拟订单查询

@GetMapping("/query")

public String queryOrder() {

    return "查询订单成功";

}

定义 /order/update 端点，模式订单更新

@GetMapping("/update")

public String updateOrder() {

	return "更新订单成功过";

}

重启服务，查看 Sentinel 控制台的簇点链路

配置流控规则

对哪个端点限流，就点击哪个端点后面的按钮，我们是对订单查询 /order/query 限流

在表单中填写流控规则

# 链路模式

# 介绍

只针对从指定链路访问到本资源的请求做统计，判断是否超过阈值

# 需求及步骤

# 需求

有查询订单和创建订单业务，两者都需要查询商品。针对从查询订单进入到查询商品的请求统计，并设置限流

# 步骤

1. 在 OrderService 中添加一个 queryGoods 方法，不用实现业务

2. 在 OrderController 中，改造 /order/query 端点，调用 OrderService 中的 queryGoods 方法

3. 在 OrderController 中添加一个 /order/save 的端点，调用 OrderService 的 queryGoods 方法

4. 给 queryGoods 设置限流规则，从 /order/query 进入 queryGoods 的方法限制 QPS 必须小于 2

# 实现

# 添加查询商品的方法

public void queryGoods() {

    System.out.println("查询商品");

}

# 查询订单时，查询商品

@GetMapping("/query")

public String queryOrder() {

	// 查询商品

    orderService.queryGoods();

    // 查询订单

    System.out.println("查询订单");

    return "查询订单成功";

}

# 新增订单，查询商品

@GetMapping("/save")

public String saveOrder() {

    // 查询商品

    orderService.queryGoods();

    // 查询订单

    System.out.println("新增订单");

    return "新增订单成功";

}

# 给查询商品添加资源标记

默认情况下，OrderService 中的方法是不被 Sentinel 监控的，需要我们自己通过注解来标记要监控的方法

@SentinelResource("goods")

public void queryGoods() {

    System.out.println("查询商品");

}

链路模式中，是对不同来源的两个链路做监控。但是 sentinel 默认会给进入 SpringMVC 的所有请求设置同一个 root 资源，会导致链路模式失效

我们需要关闭这种对 SpringMVC 的资源聚合，修改 order-service 服务的 application.yml 文件：

spring:

  cloud:

    sentinel:

      web-context-unify: false # 关闭 context 整合

重启服务，访问 /order/query 和 /order/save，可以查看到 sentinel 的簇点链路规则中，出现了新的资源：

# 添加流控规则

点击 goods 资源后面的流控按钮

# 流控效果

# 流控效果分类

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

# warm up

# 介绍

阈值一般是一个微服务能承担的最大 QPS，但是一个服务刚刚启动时，一切资源尚未初始化，如果直接将 QPS 跑到最大值，可能导致服务瞬间宕机

warm up 也叫预热模式，是应对服务冷启动的一种方案，请求阈值初始值是 maxThreshold / coldFactor ，持续指定时长后，逐渐提高到 maxThreshold 值，而 coldFactor 的默认值是 3

例如：设置 QPS 的 maxThreshold 为 10，预热时间为 5 秒，那么初始阈值就是 10 / 3，也就是 3，然后 5 秒后逐渐增长到 10

# 配置流控规则

# 排队等待

# 介绍

当请求超过 QPS 阈值时，快速失败和 warm up 会拒绝新的请求并抛出异常

而排队等待则是让所有请求进入一个队列中，然后按照阈值允许的时间间隔依次执行，后来的请求必须等待前面的执行完成，如果请求预期的等待时间超过最大时长，则会被拒绝

# 添加流控规则

# 热点参数限流

# 介绍

之前的限流是统计访问某个资源的所有请求，判断是否超过 QPS 阈值，而热点参数限流是分别统计参数值相同的请求，判断是否超过 QPS 阈值

# 全局参数限流

访问 /goods/{id} 的请求中，id 参数值会有变化，热点参数限流会根据参数值分别统计 QPS，统计结果

当 id=1 的请求触发阈值被限流时，id 值不为 1 的请求不受影响

配置实例：

# 热点参数限流

实际开发中，可能部分商品是热点商品，例如秒杀，我们希望这部分商品的 QPS 限制与其它商品不一样，高一些，那就需要配置热点参数的高级选项了

# 案例

# 标记资源

给 order-service 中的 OrderController 中的 /order/{orderId} 资源添加注解

@RequestMapping("/order")

public class OrderController {

    @Autowired

    private OrderService orderService;

    @SentinelResource("hot")

    @GetMapping("{orderId}")

    public Order queryOrderByUserId(@PathVariable("orderId") Long orderId) {

        // 根据 id 查询订单并返回

        return orderService.queryOrderById(orderId);

    }

}

# 热点参数限流

访问该接口，我们可以看到标记的 hot 资源出现

点击最左边的热点规则菜单

点击新增，填写表单

# 隔离和降级

# 介绍

限流是一种预防措施，虽然限流可以尽量避免因高并发引起的服务故障，但服务还会因为其它原因而故障

而瑶将这些故障控制在一定范围，避免雪崩，就要靠线程隔离和熔断降级

线程隔离：调用者在调用服务提供者时，给每个调用的请求分配独立线程池，出现故障时，最多消耗这个线程池内资源，避免把调用者的所有资源耗尽

熔断降级：是在调用方这边加入断路器，统计对服务提供者的调用，如果调用的失败比例过高，则熔断该业务，不允许访问服务的提供者了

# FeignClient 整合 Sentinel

# 修改配置，开启 Sentinel 功能

修改 OrderService 的 application.yaml 文件，开启 Feign 的 Sentinel 功能

feign:

  sentinel:

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

# 编写失败降级逻辑

# 步骤一

在 feign-api 中定义类，实现 FallbackFactory

@Slf4j

public class UserClientFallbackFactory implements FallbackFactory<UserClient> {

    @Override

    public UserClient create(Throwable throwable) {

        return new UserClient() {

            @Override

            public Usre findById(Long id) {

                log.error("查询用户异常", throwable);

                return new User();

            }

        }

    }

}

# 步骤二

在 feign-api 项目中的 DefaultFeignConfiguration 类中将 UserClientFallbackFactory 注册为一个 Bean

@Bean

public UserClientFallbackFactory userClientFallbackFactory() {

    return new UserClientFallbackFactory();

}

# 步骤三

在 feign-api 项目中 UserClient 接口中使用 UserClientFallbackFactory

@FeignClient(value = "userservice", fallbackFactory = UserClientFallbackFactory.class)

public interface UserClient {

    GetMapping("/user/{id}")

    User findById(@PathVariable("id") Long id);

}

重启后，访问订单查询业务，然后查看 Sentinel 控制台

# 线程隔离（舱壁模式）

# 线程隔离实现方式

• 线程池隔离
• 信号量隔离（Sentinel 默认采用）

线程池隔离：给每个服务调用业务分配一个线程池，利用线程池本身实现隔离效果

信号量隔离：不创建线程池，而是计数器模式，记录业务使用的线程数量，达到信号量上限时，禁止新的请求

# Sentinel 的线程隔离

# 用法说明

在添加限流规则时，可以选择两种阈值类型：

• QPS：就是每秒的请求数
• 线程数：是该资源能使用的 tomcat 线程的最大值，也就是通过限制线程数量，实现线程隔离

# 案例

选择 feign 接口后面的流控接口

填写表单

# 熔断降级

# 介绍

熔断降级是解决雪崩问题的重要手段。其思路是由断路器统计服务调用的异常比例、慢请求比例，如果超出阈值则会熔断该服务。即拦截访问该服务的一切请求；而当服务恢复时，断路器会放行访问该服务的请求

断路器控制熔断和放行是通过状态机来完成的：

状态机包括的三个状态：

• closed：关闭状态，断路器放行所有请求，并开始统计异常比例、慢请求比例，超过阈值则切换到 open 版本
• open：打开状态，，服务调用被熔断，访问被熔断服务的请求会被拒绝，快速失败，直接走降级逻辑，Open 状态 5 秒后，进入 half-open 状态
• half-open：半开状态，放行一次请求，根据执行的结果来判断接下来的操作
  • 请求成功：切换到 closed 状态
  • 请求失败：切换到 open 状态

断路器熔断策略：慢调用、异常比例、异常数

# 慢调用

# 介绍

业务的响应时长（RT）大于指定时长的请求认定为慢调用请求。在指定时间内，如果请求数量超过设定的最小数量，慢调用比例大于设定的阈值，则触发熔断

# 实例

解读：RT 超过 500ms 的调用是慢调用，统计最近 10000ms 内的请求，如果请求量超过 10 次，并且慢调用比例不低于 0.5，则触发熔断，熔断时长为 5 秒。然后进入 half-open 状态，放行一次请求做测试

# 代码

修改 user-service 中的 /user/{id} 这个接口的业务。通过休眠模拟一个延迟时间：

@GetMapping("/{id}")

public User queryById(@PathVariable("id") Long id) throws InterruptedException {

    if (id == 1) {

        Thread.sleep(60);

    }

    return userService.queryById(id);

}

此时，orderId=101 的订单，关联的是 id 为 1 的用户，调用时长为 60ms：

orderId=102 的订单，关联的是 id 为 2 的用户，调用时长为非常短；

# 设置熔断规则

# 异常比例、异常数

# 介绍

统计指定时间内的调用，如果调用次数超过指定请求数，并且出现异常的比例达到设定的比例阈值（或超过指定异常数），则触发熔断

# 实例

# 代码

首先，修改 user-service 中的 /user/{id} 这个接口的业务。手动抛出异常，以触发异常比例的熔断：

@GetMapping("/{id}")

public User queryById(@PathVariable("id") Long id) throws InterruptedException {

    if (id == 1) {

        Thread.sleep(60);

    } else if(id == 2) {

        throw new RuntimeException("故意抛出异常，触发异常比例熔断");

    }

    return userService.queryById(id);

}

# 设置熔断规则

# 授权规则

# 授权规则

# 基本规则

授权规则可以对调用方的来源做控制，有白名单和黑名单两种方式

• 白名单：来源（origin）在白名单内的调用者允许访问
• 黑名单：来源（origin）在黑名单内的调用者不允许访问

点击左侧菜单的授权，可以看到权限规则：

• 资源名：就是保护的资源
• 流控应用：用来源者的名单

我们允许请求从 gateway 到 order-service，不允许浏览器访问 order-service，那么白名单中就要填写网关的来源名称（origin）

# 如何获取 orign

Sentinel 是通过 RequestOriginParser 这个接口的 parseOrigin 来获取请求的来源的

public interface RequestOrignParser {

    /**

     * 从请求request对象中获取orign，获取方式自定义

     */

    String parseOrign(HttpServletRequest request);

}

定义一个 RequestOriginParser 的实现类：

@Compoment

public class HeaderOrignParser implements RequestOrignParser {

    @Override

    public String parseOrign(HttpServletRequest request) {

        // 1. 获取请求头

        String origin = request.getHeader("origin");

        // 2. 非空判断

        if (StringUtils.isEmpty(origin)) {

            origin = "blank";

        }

        return origin;

    }

}

# 给网关添加请求头

既然获取请求 origin 的方式是从 reques-header 中获取 origin 值，我们必须让所有从 gateway 路由到微服务的请求都带上 origin 头

这个需要利用之前学习的一个 GatewayFilter 来实现，AddRequestHeaderGatewayFilter。

修改 gateway 服务中的 application.yml，添加一个 defaultFilter：

spring:

  cloud:

    gateway:

      default-filters:

        - AddRequestHeader=origin,gateway

      routes:

       # ... 略

# 配置授权规则

# 自定义异常结果

# 介绍

默认情况下，发生限流、降级、授权拦截时，都会抛出异常到调用方。异常结果都是 flow limmiting（限流）。这样不够友好，无法得知是限流还是降级还是授权拦截

# 异常类型

如果要自定义异常时的返回结果，需要实现 BlockExceptionHandler 接口：

public interface BlockExceptionHandler {

    /**

     * 处理请求被限流、降级、授权拦截时抛出的异常：BlockException

     */

    void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception;

}

• HttpServletRequest request：request 对象
• HttpServletResponse response：response 对象
• BlockException e：被 sentinel 拦截时抛出的异常

这里 BlockException 包含多个不同的子类

# 自定义异常处理

@Component

public class SentinelExceptionHandle implements BlockExceptionHandler {

    @Override

    public void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception {

        String msg = "未知异常";

        int status = 429;

        if (e instanceof FlowException) {

            msg = "请求被限流了";

        } else if (e instanceof ParamFlowException) {

            msg = "请求被热点参数限流";

        } else if (e instanceof DegradeException) {

            msg = "请求被降级了";

        } else if (e instanceof AuthorityException) {

            msg = "没有权限访问";

            status = 401;

        }

        response.setContentType("application/json;charset=utf-8");

        response.setStatus(status);

        response.getWriter().println("{\"msg\": " + msg + ", \"status\": " + status + "}");

    }

}

# 规则持久化

# 介绍

现在，sentinel 的所有规则都是内存存储，重启后所有规则都会丢失。在生产环境下，我们必须确保这些规则的持久化，避免丢失

# 规则管理模式

规则是否能持久化，取决于规则管理模式，sentinel 支持三种规则管理模式：

• 原始模式：Sentinel 的默认模式，将规则保存在内存，重启服务会丢失。
• pull 模式
• push 模式

# pull 模式

pull 模式：控制台将配置的规则推送到 Sentinel 客户端，而客户端会将配置规则保存在本地文件或数据库中。以后会定时去本地文件或数据库中查询，更新本地规则。

# push 模式

push 模式：控制台将配置规则推送到远程配置中心，例如 Nacos。Sentinel 客户端监听 Nacos，获取配置变更的推送消息，完成本地配置更新。