Sentinel

初识Sentinel

雪崩问题

微服务调用链路中的某个服务故障，引起整个链路中的所有微服务都不可用，这就是雪崩。

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

• 超时处理
• 舱壁模式
• 熔断降级
• 流量控制

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

舱壁模式：限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，也叫线程隔离。

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

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

总结：

避免因瞬间高并发流量而导致服务故障——流量控制。

避免因服务故障引起的的雪崩问题——超时处理、线程隔离、降级熔断

服务技术对比

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

Sentinel具有以下特征：

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

Sentinel的安装

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

Github下载地址：https://github.com/alibaba/Sentinel

下载好后运行jar包即可：

java -jar sentinel-dashboard-1.8.1.jar
1

dashboard的端口是8080，在浏览器登录即可。账号密码均默认是sentinel。

如果要修改默认端口、账号、密码，通过下面的配置进行修改

注：在启动服务时，加上-D之后跟要修改的配置项即可。

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

微服务整合Sentinel

步骤一：引入sentinel依赖

<!-- sentinel -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
1
2
3
4
5

步骤二：配置控制台地址

spring:
  cloud:
    sentinel:
      transport:
        dashboard: localhost:8080
1
2
3
4
5

访问微服务的任意端点，触发Sentinel监控

限流规则

簇点链路：即项目内的调用链路，链路中被监控的每个接口就是一个资源。默认情况下sentinel会监控Spring MVC的每一个端点（Endpoint），因此SpringMVC的每一个端点就是调用链路中的一个资源。

流控模式

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

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

流控模式-关联

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

使用场景：比如用户支付时需要修改订单状态，同时用户要查询订单。查询和修改操作回争抢数据库锁，产生竞争。

• 业务需求是有限支付和更新订单的业务，因此当修改订单业务触发阈值时，需要对查询订单业务限流。

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

案例

需求：

• 在OrderController下新建两个端点：/order/query和/order/update，无需实现具体业务。
• 配置流控规则，当/order/update资源被访问的QPS超过5时，对/order/query请求限流。

配置流控规则

使用JMeter进行测试，测试后对query进行访问：

监控页面：

流控模式-链路

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

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

步骤一：在OrderService中添加一个queryGoods方法，不用实现业务

    @SentinelResource("goods")
    public void queryGoods(){
        System.err.println("查询商品");
    }
1
2
3
4

步骤二：在OrderController中，改造/order/query端点，调用OrderService中的queryGoods方法

    @GetMapping("/query")
    public String queryOrder(){
        // 查询商品
        orderService.queryGoods();
        // 查询订单
        System.out.println("查询订单");
        return "查询订单成功";
    }
1
2
3
4
5
6
7
8

步骤三：在OrderService中添加一个/order/save的端点，调用OrderService的queryGoods方法。

    @GetMapping("/save")
    public String saveOrder(){
        // 查询商品
        orderService.queryGoods();
        // 新增订单
        System.out.println("新增订单");
        return "新增订单成功";
    }
1
2
3
4
5
6
7
8

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

在该案例中，需要注意以下两点：

1. 默认情况下Sentinel只监视Spring MVC的每一个端点，即controller中的方法为资源。如果要标记其他的方法，就要使用@SentinelResource注解
2. Sentinel默认会将Controller方法做context整合，导致链路模式的流控失效，需要修改application.yml，添加配置

spring:
  cloud:
    sentinel:
      transport:
        dashboard: localhost:8080
      web-context-unify: false # 关闭context整合
1
2
3
4
5
6

完成上述准备工作后，我们使用JMeter进行测试：

流控效果

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

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

流控效果-warm up

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

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

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

流控效果-排队等待

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

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

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

热点参数限流

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

代表的含义是：对hot这个资源的0号参数（第一个参数）做统计，每1秒相同参数值的请求数不能超过5。

在热点参数限流的高级选项中，可以对部分参数设置例如配置：

这里的含义是对0号的long类型参数限流，每1秒相同参数的QPS不能超过5，但有两个例外：

• 如果参数值是100，则每1秒允许的QPS为10
• 如果参数值是101，则每1秒允许的QPS为15

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

• 默认的热点参数规则是每一秒请求量不超过2。
• 给102这个参数设置例外：每1秒请求量不超过4。
• 给103这个参数设置例外：每1秒请求量不超过10。

注：热点参数限流对默认的Spring MVC资源无效。

隔离和降级

虽然限流可以尽量避免因高并发而引起的服务故障，但服务还会因为其它原因而故障。而要将这些故障控制在一定范围，避免雪崩，就要靠线程隔离（舱壁模式）和熔断降级手段了。

不管是线程隔离还是熔断降级，都是对客户端（调用方）的保护。

Feign整合Sentinel

Spring Cloud中，微服务调用都是通过Feign来实现的，因此做客户端保护必须整合Feign和Sentinel。

步骤一：修改OrderService的application.yml文件，开启Feign的Sentinel功能

feign:
  sentinel:
    enabled: true  # 开启Feign的Sentinel功能
1
2
3

步骤二：给FeignClient编写失败后的降级逻辑

• 方式一：FallbackClass，无法对远程调用的异常做处理。
• 方式二：FallbackFactory，可以对远程调用的异常做处理。

我们使用第二种方式：

①在feign-api项目中定义类，实现FallbackFactory：

@Slf4j
public class UserClientFallbackFactory implements FallbackFactory<UserClient> {
    @Override
    public UserClient create(Throwable throwable) {
        // 创建UserClient接口实现类，实现里面的方法，编写失败降级后的处理逻辑
        return new UserClient() {
            @Override
            public User findById(Long id) {
                // 记录异常信息
                log.error("查询用户异常", throwable);
                // 根据业务需求返回默认的数据，这里是空用户
                return new User();
            }
        };
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

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

    @Bean
    public UserClientFallbackFactory userClientFallbackFactory(){
        return new UserClientFallbackFactory();
    }
1
2
3
4

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

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

    @GetMapping("/user/{id}")
    User findById(@PathVariable("id") Long id);
}
1
2
3
4
5
6

线程隔离

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

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

信号量隔离与线程池隔离的优缺点及其使用场景

信号量隔离：

• 优点：轻量级，无额外开销
• 缺点：不知处主动超时；不支持异步调用。
• 场景：高频调用；高扇出

线程池隔离：

• 优点：支持主动超时；支持异步调用
• 缺点：线程额外开销比较大
• 场景：低扇出

Sentinel使用及其案例

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

• QPS：指每秒的请求数。
• 线程数：该资源能使用的tomcat线程数的最大值，通过限制线程数量，实现舱壁模式。

案例：给UserClient的查询用户接口设置流控规则，线程数不能超过2。然后利用jemeter测试。

熔断降级

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

熔断策略

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

慢调用

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

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

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

异常比例或异常数

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

统计最近1000ms的请求，如果请求量超过10次，并且异常比例不低于0.5，则触发熔断，熔断时长为5秒。然后进入half-open状态，放行一次请求做测试。

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

tips：

为了触发以上熔断的情况，需要对UserService的业务进行修改：

    @GetMapping("/{id}")
    public User queryById(@PathVariable("id") Long id, @RequestHeader(value = "Life", required = false) String life) throws InterruptedException {
        if (id == 1){
            Thread.sleep(60);
        }else if (id == 2){
            throw new RuntimeException("故意出错，触发熔断");
        }
        return userService.queryById(id);
    }
1
2
3
4
5
6
7
8
9

授权规则

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

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

例如，我们限定只允许从网关来的请求访问orde-service，那么流控应用中就填写网关的名称。

但是流控应用中填的并非是gateway，sentinel中要求填入的是请求来源名称。想要获取请求来源的名称，Sentinel为我们提供了一个接口：

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

比较可惜的是，在Sentinel中，该接口的parseOrigin方法返回的永远是default，也就是说，无论请求开源是来自网关还是浏览器，Sentinel根本无法区分这两个请求。所以就需要我们自己来实现这个接口，编写它的业务逻辑，让从网关来的请求和浏览器来的请求返回不同的结果。

例如，我们尝试从request中获取一个名为origin的请求头，作为origin的值：

@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;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13

还需要在gateway服务中，利用网关的全局过滤器添加名为gateway的origin头：

spring:
  cloud:
    gateway:
      default-filters:
        - AddRequestHeader=origin,gateway # 添加名为origin的请求头，值为gateway
1
2
3
4
5

浏览器访问：

网关访问：

自定义异常结果

默认情况下，发生限流、降级、授权拦截时，都会抛出异常到调用方。如果要自定义异常时的返回结果，需要实现BlockExceptionHandler接口：

public interface BlockExceptionHandler {
    void handle(HttpServletRequest var1, HttpServletResponse var2, BlockException var3) throws Exception;
}
1
2
3

BlockException包含很多个子类，以应对不同的场景：

在order-service中定义类，实现BlockExceptionHandler接口：

@Component
public class SentinelExceptionHandler 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().write("{\"msg\": " + msg + ", \"status\":" + status + "}");
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

规则持久化

Sentinel的控制台管理规则有三种模式：

原始模式：控制台配置的规则直接推送到Sentinel客户端，也就是我们的应用。然后保存在内存中，服务重启则丢失

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

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

实现push模式

push模式的实现最为复杂，因为其依赖于nacos，并且需要改Sentinel控制台的源码，整体步骤如下：

1. 修改order-service服务，使其监听Nacos配置中心
2. 修改Sentinel-dashboard源码，配置nacos数据源
3. 修改Sentinel-dashboard源码， 修改前端页面
4. 重新编译、打包Sentinel-dashboard源码

修改order-service服务

Ⅰ.引入依赖

        <dependency>
            <groupId>com.alibaba.csp</groupId>
            <artifactId>sentinel-datasource-nacos</artifactId>
        </dependency>
1
2
3
4

Ⅱ.配置nacos地址

spring:
  cloud:
    sentinel:
      datasource:
        flow:
          nacos:
            server-addr: localhost:8848 # nacos地址
            dataId: orderservice-flow-rules
            groupId: SENTINEL_GROUP
            rule-type: flow   # 还可以是degrade、authority、param-flow
        degrade:
          nacos:
              server-addr: localhost:8848 # nacos地址
              dataId: orderservice-degrade-rules
              groupId: SENTINEL_GROUP
              rule-type: degrade   # 还可以是degrade、authority、param-flow
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16