从零开始 Spring Cloud 12：Sentinel

1.初识 Sentinel

1.1雪崩问题

1.1.1什么是雪崩问题

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

1533829099748

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

1533829198240

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

1533829307389

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

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

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

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")
    public String updateOrder(){
        return "订单已修改";
    }
}

重启微服务 order-service。

访问新添加的两个接口以使 Sentinel 有相应的资源信息：

为资源/order/query添加流控规则：

这里添加的规则，意味着如果每秒内访问/order/update接口的次数超过5，/order/query接口就无法被访问。

可以用导入的测试案例中的 流控模式-关联 进行测试，该测试会在100秒内请求/order/update接口1000次，即每秒10次。理论上因为关联模式的限制，在这10秒内/order/query接口会不可用。

实际执行后和理论结果相符，在执行测试案例的过程中，请求/order/query接口会返回Blocked by Sentinel (flow limiting)。

2.2.2.链路模式

链路模式：只针对从指定链路访问到本资源的请求做统计，判断是否超过阈值。如果超过，对请求来源限制访问。

下面用实际案例进行说明。

假设有两个接口，查询订单和创建订单，它们都需要调用查询商品的 Service 方法。

// ...
public class OrderService {
	// ...
    @SentinelResource("/service/order/query-goods")
    public String queryGoods(){
        return "商品信息";
    }
}

// ...
public class OrderController {
	// ...
    @GetMapping("/query")
    public String getOrderInfo(){
        orderService.queryGoods();
        return "订单内容";
    }
	// ...
    @GetMapping("/save")
    public String saveOrder(){
        orderService.queryGoods();
        return "订单已保存";
    }
}

注意，默认情况下 Sentinel 只会监控 Controller 中的资源，所以 Service 中的方法是不会出现在簇点链路中的资源列表里的。要将 Service 中的方法注册为资源，需要使用@SentinelResource注解。

只这样做还不够，默认情况下 Sentinel 会自动将资源整合到sentinel_spring_web_context这个默认链路下，在这里我们需要创建两个链路，并对其中的一个进行限制，所以必须关闭这种默认行为。

修改配置：

spring:
  cloud:
    sentinel:
      web-context-unify: false # 关闭context整合

重启子模块并访问两个接口。

Sentinel 控制台已经可以看到两个链路：

/order/save -> /service/order/query-goods
/order/query -> /service/order/query-goods

选择任意一个/service/order/query-goods资源添加规则：

现在 Sentinel 会统计从 /order/query 到 /service/order/query-goods 的这条链路，如果其 QPS 大于2，就会限制对/order/query的请求。

执行测试案例中的 流控模式-链路 进行验证，这个案例会分别对两个接口请求，QPS 都是 4，可以看到其中对/order/query的请求在每秒中只有2次成功，另外2次会失败，说明链路模式生效。而对/order/save的请求则都成功。

2.3.流控效果

在流控的高级选项中，还有一个流控效果选项：

流控效果是指请求达到流控阈值时应该采取的措施，包括三种：

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

2.3.1.warm up

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

下面用实际案例说明。

需求：给/order/{orderId}这个资源设置限流，最大QPS为10，利用warm up效果，预热时长为5秒。

流控规则设置如下：

运行测试案例 流控效果，warm up，该测试的 QPS 是10，执行时长是20秒。可以看到一开始每秒只有3条请求成功，随着时间推移成功的请求会主逐渐增多。

查看 Sentinel 的实时监控，会看到类似下面的图形：

可以看到通过的 QPS 主键增多，直到最大值（10），而被拒绝的 QPS 逐渐减少。

使用 warm up 这种流控效果，可以让服务器的负载逐渐上升，起到一个“预热"的效果，以避免突然的高负载导致服务器宕机。

2.3.2.排队等待

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

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

工作原理

例如：QPS = 5，意味着每200ms处理一个队列中的请求；timeout = 2000，意味着预期等待时长超过2000ms的请求会被拒绝并抛出异常。

那什么叫做预期等待时长呢？

比如现在一下子来了12 个请求，因为每200ms执行一个请求，那么：

第6个请求的预期等待时长 = 200 * （6 - 1） = 1000ms
第12个请求的预期等待时长 = 200 * （12-1） = 2200ms

现在，第1秒同时接收到10个请求，但第2秒只有1个请求，此时QPS的曲线这样的：

如果使用队列模式做流控，所有进入的请求都要排队，以固定的200ms的间隔执行，QPS会变的很平滑：

这种流控效果可以起到”流量整形“的效果，即将一个波动的 QPS 曲线整形成平滑的 QPS 曲线。而平滑的QPS曲线，对于服务器来说是更友好的。

下面用实际案例说明。

需求：给/order/{orderId}这个资源设置限流，最大QPS为10，利用排队的流控效果，超时时长设置为5s。

编辑流控规则：

启动测试案例 流控效果，队列 进行测试，这个测试的 QPS 是15，持续20秒，可以看到实时监控图形如下：

可以看到，一开始的几秒内是没有请求失败的 QPS 的，因为接口会处理 QPS=10 的请求，并将多余的请求放入队列，只有队列被填满（预期处理时长超过5秒），新的请求才会被丢弃（即出现请求失败的 QPS）。

2.4.热点参数限流

如果需要对同一个资源的不同参数进行限流，就需要使用热点参数限流。

比如对/goods/{id}接口的请求按照不同的参数进行 QPS 统计：

我们就可以根据不同 id 值的 QPS 进行分别统计和限流。

下面用实际案例说明。

案例需求：给/order/{orderId}这个资源添加热点参数限流，规则如下：

•默认的热点参数规则是每1秒请求量不超过2

•给102这个参数设置例外：每1秒请求量不超过4

•给103这个参数设置例外：每1秒请求量不超过10

需要注意的是，Sentinel 的热点参数限流对默认添加的 SpringMVC 资源无效，所以这里需要先对资源使用@SentinelResource注解，以添加 Sentinel 资源：

// ...
public class OrderController {
	// ...
    @SentinelResource("hot")
    @GetMapping("{orderId}")
    public Order queryOrderByUserId(@PathVariable("orderId") Long orderId) {
        // 根据id查询订单并返回
        return orderService.queryOrderById(orderId);
    }
    // ...
}

重启微服务。

请求接口（http://localhost:8088/order/101）让资源注册。

在 热点规则 菜单页面中新增 热点规则限流：

这里的参数索引指所要添加限制的参数位于接口路径上的参数位置（从0开始）。单机阈值设置为2，统计窗口时长设置为1，实际上就是 QPS=2。

这里为资源 hot 设置的默认参数限流的 QPS 是2，另外添加了2个参数例外，其中参数值是 102 时 QPS 上限是4，参数值是 103 时 QPS 上限是10。

从簇点链路菜单页面添加热点规则无法使用高级选项（参数例外）。

执行测试案例中的 热点参数限流 QPS1 进行测试。该案例的 QPS=5，且使用不同的参数值分别请求接口：

/order/101
/order/102
/order/103

参数值是101时，受热点规则中的默认设置限制，即最大QPS 是2，所以每秒只有2个请求成功。参数值是102时，受例外规则限制，最大QPS是4，所以每秒有4个请求成功。参数值是103时，最大 QPS 是10，所以所有请求都成功。

3.隔离和降级

可以用 Sentinel 对分布式架构中接口的调用方进行保护，具体包含两种方式：

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

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

3.1.FeignClient 整合 Sentinel

因为目前我们 Spring Cloud 中微服务之间的远程调用都是用 Feign 实现的，所以要想实现上边的功能，就必须在服务调用方的 Feign 客户端中整合 Sentinel。

下面具体说明如何实现 Feign 客户端和 Sentinel 的整合。

3.1.1.开启 Sentinel 功能

首先需要修改配置，以启用 Feign 对 Sentinel 的支持：

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

这里的示例中我们需要保护的是微服务 order-service，它的订单信息接口会远程调用 user-service，所以对 order-service 中的 Feign 客户端整合 Sentinel，也就是要修改 order-service 的配置文件。

实际上完成上边的步骤后 Sentinel 已经会将通过 Feign 进行的远程调用纳入资源监控，可以在 Sentinel 控制台看到相应的资源：

但如果直接设置降级熔断或者隔离，触发限制后远程调用会直接报错，这样对调用方的感知不会太好，因此一般我们需要添加失败降级后的处理逻辑。

3.1.2.添加失败降级逻辑

可以利用两个接口实现 Feign 客户端调用失败后的降级逻辑：

FallbackClass，无法对远程调用的异常做处理
FallbackFactory，可以对远程调用的异常做处理，我们选择这种

一般使用 FallbackFactory。

package cn.itcast.feign.clients.fallbackfactory;
// ...
@Log4j2
public class UserClientFallbackFactory implements FallbackFactory<UserClient> {

    @Override
    public UserClient create(Throwable throwable) {
        return new UserClient() {
            @Override
            public User findById(Long id) {
                //将错误信息打印到日志
                log.error("Feign 远程调用出错", throwable);
                //远程调用失败时返回一个空的用户对象
                return new User();
            }
        };
    }
}

FallbackFactory要写在 FeignClient 定义的地方，在这个示例项目中，就是子模块 feign-api。

FallbackFactory是一个泛型接口，在实现时，泛型参数应当指定为要定义错误处理的 FeignClient。

FallbackFactory的实现类必须定义为 Spring Bean：

package cn.itcast.feign.config;
// ...
public class DefaultFeignConfiguration {
	// ...
    @Bean
    public UserClientFallbackFactory userClientFallbackFactory(){
        return new UserClientFallbackFactory();
    }
}

feign-api 只是一个用于定义 Feign 客户端的子模块，并不会真正运行。所以要让配置类DefaultFeignConfiguration生效，还需要在使用 feign-api 的微服务中添加：

package cn.itcast.order;
// ...
@SpringBootApplication
@EnableFeignClients(clients = UserClient.class,defaultConfiguration = DefaultFeignConfiguration.class)
public class OrderApplication {
	// ...
}

要让定义的FallbackFactory生效，还需要在@FeignClient注解中添加fallbackFactory属性：

@FeignClient(value = "userservice", fallbackFactory = UserClientFallbackFactory.class)
public interface UserClient {
	// ...
}

在实际使用中，失败降级逻辑通常可以用两种思路实现以保证用户友好：

返回特定的错误信息。
返回特定的业务数据，比如一些特定的商品信息等。

3.2.线程隔离

3.2.1.线程隔离的实现方式

线程隔离有两种方式实现：

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

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

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

两者的优缺点：

3.2.2.Sentinel 的线程隔离

这里用示例进行说明如何用 Sentinel 实现线程隔离。

为资源GET:http://userservice/user/{id}添加线程隔离：

现在/order/{orderId} -> /userservice/user/{id} 这个调用链被设置了信号量隔离，阈值为2。也就是说同时只能有2个并发的线程被允许访问接口/userservice/user/{id}，其它的并发线程会被拒绝（执行定义好的失败降级逻辑，如果有的话）。

可以执行 JMeter 中的 阈值类型-线程数<2 来进行测试。该测试会模拟同时请求10次接口。

可以观察到虽然10次请求都成功了，但有8次返回的结果中用户信息是null，这符合我们实现的失败处理逻辑。

3.3.熔断降级

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

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

状态机包括三个状态：

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

关于断路器状态的详细讲解，可以观看这个视频（相关内容位于 24:00）

3.3.1.慢调用

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

例如：

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

下面用实际示例进行说明。

需求：给 UserClient的查询用户接口设置降级规则，慢调用的RT阈值为50ms，统计时间为1秒，最小请求数量为5，失败阈值比例为0.4，熔断时长为5

为了模拟接口调用超过 50ms，在接口中添加休眠代码：

package cn.itcast.user.web;
// ...
public class UserController {
	// ...
    @GetMapping("/{id}")
    public User queryById(@PathVariable("id") Long id,
                          @RequestHeader(value = "Truth", required = false) String truth) throws InterruptedException {
        if (id.equals(1L)) {
            Thread.sleep(60);
        }
        return userService.queryById(id);
    }
}

给资源GET:http://userservice/user/{id}添加降级规则：

也就是说，上面配置的规则只要在1秒内有至少5次请求发生，且其中2次以上调用时长超过50ms，就会熔断5s。

请求接口 http://localhost:8088/order/101 5次后，发生熔断：

{
    "id": 101,
    "price": 699900,
    "name": "Apple 苹果 iPhone 12 ",
    "num": 1,
    "userId": 1,
    "user": {
        "id": null,
        "username": null,
        "address": null
    }
}

此时请求接口 http://localhost:8088/order/102 同样无法获取正确的用户信息：

{
    "id": 102,
    "price": 209900,
    "name": "雅迪 yadea 新国标电动车",
    "num": 1,
    "userId": 2,
    "user": {
        "id": null,
        "username": null,
        "address": null
    }
}

等待5秒后两个接口都恢复为正常访问。

如果熔断降级规则配置后进行测试发现没有生效，可以等一会，实际测试发现规则没有立即生效。
可以手动刷新浏览器进行测试，也可以选择使用 JMeter。

3.3.2.异常比例、异常数

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

例如，一个异常比例设置：

解读：统计最近1000ms内的请求，如果请求量超过10次，并且异常比例不低于0.4，则触发熔断。

一个异常数设置：

解读：统计最近1000ms内的请求，如果请求量超过10次，并且异常比例不低于2次，则触发熔断。

这里同样用实际示例进行说明。

目标：给 UserClient的查询用户接口设置降级规则，统计时间为1秒，最小请求数量为5，失败阈值比例为0.4，熔断时长为5s。

为了模拟接口调用出现异常，在接口中抛出一个异常：

@GetMapping("/{id}")
public User queryById(@PathVariable("id") Long id,
                      @RequestHeader(value = "Truth", required = false) String truth) throws InterruptedException {
    if (id.equals(1L)) {
        System.out.println("程序休眠，以满足降级要求");
        Thread.sleep(60);
    }
    else if (id.equals(2L)){
        throw new RuntimeException("模拟调用出现异常");
    }
    return userService.queryById(id);
}

重启微服务。

修改之前添加的降级熔断规则：

和之前类似，只要在1s内至少请求5次，且其中有2个异常请求出现异常，就会触发熔断。

测试过程与之前类似，不再赘述。

除了按照异常比例熔断以外，还可以按照异常数进行统计和熔断，比如：

这个设置和上边的设置效果是类似的。

4.授权规则

授权规则可以对请求方来源做判断和控制。

4.1.授权规则

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

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

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

资源名：就是受保护的资源，例如/order/{orderId}
流控应用：是来源者的名单，
- 如果是勾选白名单，则名单中的来源被许可访问。
- 如果是勾选黑名单，则名单中的来源被禁止访问。

比如：

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

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

public interface RequestOriginParser {
    /**
     * 从请求request对象中获取origin，获取方式自定义
     */
    String parseOrigin(HttpServletRequest request);
}

这个方法的作用就是从request对象中，获取请求者的origin值并返回。

默认情况下，sentinel不管请求者从哪里来，返回值永远是default，也就是说一切请求的来源都被认为是一样的值default。

换言之，我们需要添加一个自定义 bean 并实现该接口，来定义一个我们自己的区分 origin 的规则。

作为示例，我们这里定义一个 HTTP 请求头 origin 来进行区分：

package cn.itcast.order.sentinel;
// ...
@Component
public class HeaderOriginParser implements RequestOriginParser {
    @Override
    public String parseOrigin(HttpServletRequest httpServletRequest) {
        String origin = httpServletRequest.getHeader("origin");
        if (StringUtils.isEmpty(origin)) {
            origin = "blank";
        }
        return origin;
    }
}

修改 gateway 中的配置，让所有经过 gateway 过来的 HTTP 请求都添加一个 origin 请求头：

spring:
  cloud:
    gateway:
      default-filters:
        - AddRequestHeader=origin,gateway

重启 gateway 和 order-service。

新增一个授权规则：

现在直接请求接口 http://localhost:8088/order/101 会返回：

Blocked by Sentinel (flow limiting)

但经过 gateway 进行请求：http://localhost:10010/order/101?authorization=admin，可以成功返回：

{
    "id": 101,
    "price": 699900,
    "name": "Apple 苹果 iPhone 12 ",
    "num": 1,
    "userId": 1,
    "user": {
        "id": 1,
        "username": "柳岩",
        "address": "湖南省衡阳市"
    }
}

4.2.自定义异常结果

上面的示例存在一个问题，虽然触发的是授权规则进行的熔断，但实际上返回的错误信息却是限流（Flow Limiting）。实际上默认情况下，Sentinel 发生限流、降级、授权拦截时，都会抛出异常（BlockException）到调用方。异常结果都是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拦截时抛出的异常

可以在实现方法中根据 Sentinel 抛出异常的具体类型来分别处理（通常是在 Response 中返回不同的错误提示）。

BlockException的子类有：

异常	说明
FlowException	限流异常
ParamFlowException	热点参数限流的异常
DegradeException	降级异常
AuthorityException	授权规则异常
SystemBlockException	系统规则异常

下面是一个 BlockExceptionHandler 的实现示例：

package cn.itcast.order.sentinel;
// ...
@Component
public class MyBlockExceptionHandler implements BlockExceptionHandler {
    @Override
    public void handle(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, 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;
        }

        httpServletResponse.setContentType("application/json;charset=utf-8");
        httpServletResponse.setStatus(status);
        httpServletResponse.getWriter().println("{\"msg\": " + msg + ", \"status\": " + status + "}");

    }
}

重启微服务后添加限流规则并访问接口（比如 http://localhost:8088/order/101），将会显示自定义的错误信息：

{"msg": 请求被限流了, "status": 429}

5.规则持久化

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

5.1.规则管理模式

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

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

5.1.1.pull模式

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

5.1.2.push模式

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

5.2.实现push模式

Sentinel 可以借助 Nacos 的远程配置功能实现规则的持久化，但阿里开源的 Sentinel 不支持该功能，只有收费版本支持。要让开源的免费版本支持，需要修改 Sentinel-dashboard 的源码后重新打包运行。

具体方式可以参考这篇文章。

源码的修改过程倒不是很复杂，但是该项目引用的依赖非常多，下载依赖要花费很长时间（大概一天左右），所以这里提供一个我修改好的 jar 包。

运行的时候只要指定 Nacos 服务的地址就行：

java -jar -Dnacos.addr=192.168.0.88:8848 sentinel-dashboard.jar

The End，谢谢阅读。

参考资料

https://www.bilibili.com/video/BV1LQ4y127n4?p=143