Sentinel服务调控---Sentinel常用规则介绍与测试

1. Sentinel界面介绍

       Sentinel界面主要分为功能区以及展示区，左边的主要是每个服务相对应的服务调控规则，如：流控，熔断，热点，系统规则等，而右边则是展示区，主要展示相对应功能的观察以及操作页面。

实时监控： 主要是监控一些资源的实时状态，如：接口的响应时间，接口访问的成功以及一个线形展示界面，这个界面主要是展示某个时间段的资源访问情况

簇点链路： 主要是展示指定客户端资源的运行情况，分为树状以及列表俩种模式。

流控规则： 主要是监控应用流量的 QPS 或并发线程数等指标，并设置相关的阈值

熔断规则： 与Hystrix的熔断基本一样，用来预防服务调用超时等错误从而导致服务崩溃等情况

热点规则： 可以使规则设置详细到参数，用来设置参数规则的

系统规则： 主要用来监控系统的资源使用情况，大部分作用于Linux系统

授权规则： 主要是针对Sentinel系统登录用户的权限使用情况

2. 流控规则

2.1 界面介绍

       Sentinel流控规则主要是针对每个资源的访问次数，时间等信息来进行调整与控制，其原理是监控应用流量的 QPS 或并发线程数等指标，当达到指定的阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。

资源名： 唯一的名称，默认是路径名，就是说这个规则是加到哪个接口或者方法的

针对来源： Sentinel可以针对服务调用者来进行限流，可以填相关的微服务名，默认是default（不区分来源）

阈值类型/单机阈值：

• QPS：每分钟的请求数量，当这个资源的每分钟请求数量达到阈值时，进行限流

• 并发线程数：当调用该api的线程数达到阈值时，进行限流，线程数只有流控模式，并没有流控效果，线程数与QPS类似，但他们是不同的

• 不同点：QPS与线程数的区别在于，QPS模式是接收了所有的请求，但只执行一个，而线程数则是只接收一个请求，其他请求不接受。

流控模式：

• 直接：api达到限流阈值时，直接限流
• 关联：当关联的资源达到阈值时，就将自己限流。比如：A接口关联了B接口，当B达到阈值时，就降A限流
• 链路：只记录指定链路上的链路的流量当达到阈值时限流

流控效果：

• 快速失败：直接失败，抛出异常，返回相关的提示信息
• Warm up：预热模式，根据codeFactor的值，默认是3，从阈值/codeFactor开始，经过预热时长，才达到设置的QPS阈值
• 排队等待：严格控制请求通过的时间，让请求可以以均匀的速度通过，对应的是漏桶算法

2.2 效果测试

前提： 搭建好测试项目，可参考：https://blog.csdn.net/I_am_fine_/article/details/124564895

2.2.1 测试QPS-直接-快速失败

设置流控规则： 阈值设为1，表示该接口一秒钟只能触发一次，超过则直接限流

测试结果： 以刷新的方式来模拟调用

2.2.2 测试QPS-直接-WarmUP

设置流控规则： 预热模式的话主要是，比如我们设置阈值为10，预热时长为5，那么系统初始化的阈值为10/3（取整），当经过5秒后阈值才提升为10

测试： 一直刷新页面，一开始一秒超过了3次，他会限流，然后一直点，5秒后则正常了，除非一秒的刷新次数超过10次

3. 熔断规则

        Sentinel的熔断降级跟Hystrix断路器熔断降级类似，都是在我们调用服务时，避免服务链路出错导致请求发送堆积从而影响整个服务宕机，从而使用熔断降级的方法来响应请求。

        Sentinel熔断降级会在调用链路中某个资源出现不稳定状态（比如：调用超时，服务内部异常数过多等等），对这个资源的调用进行限制，让他快速失败，避免影响到其他资源从而导致服务宕机。简单点来说就是：当我们在服务之间相互调用时，一个服务多次出现了读取超时或错误时，我们就熔断这个服务或这个服务中的某一个方法，让他快速失败，等熔断时间过去了，才让他恢复正常。

        Sentinel对比Hystrix的熔断规则来说的话，大体上是类似的，但Sentinel在配置熔断规则时会更加的方便简单，而且Sentinel提供的熔断规则方式比Hystrix更加丰富。

​ 注意： 在Sentinel1.8之前，sentinel的熔断是没有半开状态的，在1.8之后，引入了半开状态（请求探测恢复状态）。

3.1 界面介绍

• 资源名 resource：唯一名称，默认请求路径；

• 熔断策略 grade：

• • 慢调用比例: 请求的响应时间大于 RT 统计为慢调用。当单位统计时长内，请求数目大于设置的最小请求数，并且慢调用的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态，若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断，若大于设置的慢调用 RT 则会再次被熔断；
  • 异常比例 : 当单位统计时长内，请求数目大于设置的最小请求数目，并且异常的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。异常比率的阈值范围是 [0.0, 1.0]，代表 0% - 100%；
  • 异常数 : 当单位统计时长内的异常数目超过阈值之后会自动进行熔断。经过熔断时长后熔断器会进入探测恢复状态，若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断；

• 最大 RT、比例阈值 count: 慢调用比例模式下为慢调用临界 RT（最大响应时间）；异常比例和异常数模式下为对应的阈值；

• 慢调用比例阈值: 仅慢调用比例模式有效（1.8.0 引入），范围是0到1，可以理解为百分数，即100%以内；

• 熔断时长: 单位为 s，当过了熔断时长后，sentinel进入探测恢复状态（类似于Hystrix里的半开状态）；

• 最小请求数: 请求数小于该值时即使异常比率超出阈值也不会熔断（1.7.0 引入）；

• 统计时长：如 60*1000 代表分钟级（1.8.0 引入），就是每多少分钟，毫秒统计一次，判断是否熔断；

3.2 效果测试

3.2.1 慢调用比例测试

规则简述： 在1000毫秒内，当请求数大于5，接口响应时间大于300ms，慢调用比例达到10%时（就是说全部请求（10个）中，有1个请求的响应时间超过300毫秒），接下来的10秒内自动开启熔断，,10秒后开始进入探测恢复状态。（以上条件都要满足，缺一个服务都不会熔断）

测试方案： 使用Jmete模拟1秒内发送10次请求，让服务进入熔断，10秒后再访问看看服务有没有恢复。

1.修改测试接口，模拟一个请求需要5秒的时间（线程休眠）

@GetMapping("/test")
public String test(){
    try {
        TimeUnit.SECONDS.sleep(5);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    return info;
}

2.Jemete模拟压力测试

3.浏览器测试是否熔断

4.等待10秒后访问服务是否恢复正常

3.2.2 异常比例测试

规则简述： 在1000毫秒内（即1秒），当请求数超过5个，并且请求出现异常的比例超过10%（比如：10个请求内出现一个异常）时，接下来的10秒内自动开启熔断，,10秒后开始进入探测恢复状态。（以上条件都要满足，缺一个服务都不会熔断）

测试方案： 设定程序出现异常，并使用jmete模拟1秒内发送10个请求，使服务进入熔断，10秒后再访问看看服务有没有恢复。

1.设置程序，使程序出现异常

//这个程序本身会出现错误，因为分母不能为0
@GetMapping("/test")
public String test(){
    int a = 1/0;
    return info;
}

2.Jemete模拟压力测试

3.浏览器测试是否熔断

4.等待10秒后访问服务是否恢复正常

3.2.3 异常数测试

规则简述： 在1000毫秒内，当请求数超过2，并且异常数超过2（就是请求2次，2次都有异常），接下来的10秒内自动开启熔断，,10秒后开始进入探测恢复状态。

测试方案： 设定程序出现异常，连续访问2次请求，使服务进入熔断，10秒后测试服务熔断是否结束。

1.设置程序，使程序出现异常

//这个程序本身会出现错误，因为分母不能为0
@GetMapping("/test")
public String test(){
    int a = 1/0;
    return info;
}

2.浏览器测试是否熔断：连续访问，即1秒内超过3次即可

3.10秒后访问服务是否恢复正常

4. 热点规则

4.1 界面介绍

       热点规则主要是针对请求中带有参数的接口，可以看成一种特殊的流量控制规则，仅对带有参数的请求有效。它主要是利用LRU策略统计经常访问的参数，然后利用漏桶算法来进行参数级别的流控。简单点来说就是针对某一个参数来进行流控，限制那个参数的访问效率。

• 限流模式：限流模式只支持 QPS 模式；
• 参数索引：必填，对应 SphU.entry(xxx, args) 中的参数索引位置；
• 单机阈值：限流阈值，必填，就是；
• 统计窗口时长：单位为秒，1.6.0 版本开始支持；
• 是否集群：是否是集群参数流控规则，热点规则提供集群方式；
• 参数类型： 声明参数类型，为8种基本类似，如：String，int等等
• 参数值： 对参数的值进行限流
• 限流阈值： 每秒访问多少次

4.2 效果测试

规则简述： 对请求中的第一个参数进行限流，当1秒中该请求（带有第一个参数）访问次数超过1时，服务出错，但当第1个参数的值为5的时候，他的阈值就变为1秒中不要超过5次即可。

测试方案： 在请求中设置相对应的参数，首先不指定参数值为5,1秒钟请求次数超过1，测试服务是否出错，然后再把参数定位5来测试。

1.修改测试接口

@GetMapping("/test")
@SentinelResource(value = "test")
public String test(@RequestParam(value = "id") String id){
    return id+":"+info;
}

2.在浏览器中访问

3.测试值为5时