Sentinel的规则
四.Sentinel的规则
流量控制有以下几个角度:
- 资源的调用关系，例如资源的调用链路，资源和资源之间的关系；
- 运行指标，例如 QPS（每秒查询率）、线程池、系统负载等；
- 控制的效果，例如直接限流、冷启动、排队等。
Sentinel 的设计理念是让您自由选择控制的角度，并进行灵活组合，从而达到想要的效果。
资源名:
唯一的资源名称，默认是接口路径，也可以自定义.
针对来源：
指定对哪个微服务进行限流，这里填写服务名，默认是default，表示不区分来源。
阈值类型:
QPS: 每秒请求数，当调用当前接口的每秒请求数达到阈值，则限流
线程数:当调用当前接口的线程数达到阈值，则限流。
流控模式:
**直接：**当前资源达到限流条件时，开启限流。
关联: 当关联的资源达到限流条件时，开启限流.
例如存在资源 A和B，A资源依赖B资源，当B资源达到阈值，则限流A。
比如支付模块B达到阈值，则限流订单模块A，因为支付已经达到上限了，过量的订单会使得支付压力更大，需要限流。
**链路：**只针对从指定链路访问到本资源的请求做统计，判断是否达到限流条件时，开启限流.
例如有两条请求链路：
/query /queryUsers
/save /queryUsers
如果只限制从/search进入到/goods的请求，就可以设置链路模式.
流控效果
快速失败
预热Warm UP
排队等待
上面已演示
1.添加测试代码
2.添加流控规则
当关联资源/pay的阈值达到3时，资源/addOrder被流控
3.模拟关联资源/pay超过阈值
启动
4.测试结果
/test1被流控
1.添加测试代码
Sentinel默认只标记Controller中的方法为资源，如果要标记其它方法，需要利用@SentinelResource注解。
2.添加流控规则
对从/query路径调用users资源（也就是queryUsers方法)进行流控，这里为了方便测试，阈值设置为1
3.设置关闭context整合
如果直接测试上述规则，会发现没有作用，这是因为自从 sentinel-spring-webmvc-adapter -1.7.2 开始，在SentinelWebMvcConfig对象(sentinel参数配置类)中含有一个webContextUnify属性，默认值为true，表示合并web context，达到节约内存的目的；如果设置为false，表示入口处的contexts会拆分为不同的url。我们针对链路模式，必须设置为false，否则会导致链路模式不生效。
4.测试
启动服务测试：
当一秒内访问超过1次，就报错.
后续我们会对此做降级处理，而不是只是返回异常。
就是被限流时，返回失败信息到页面
默认coldFactor冷加载因子为3，即请求QPS从（请求总数/3）开始，经过我们设置的时间才逐渐升至设定的QPS阈值。
例如：阈值为10,预热时长设置为4秒
限流效果：系统初始化的阈值为10/3等于3.即阈值刚开始为3.如果刚开始每秒请求数大于3则默认失败。过了4秒后阈值才慢慢升高恢复到10，即4秒后能承受大于3但是仍要小于10的请求，才不会被限流
应用场景
如：秒杀系统在开启的瞬间，会有很多流量上来，很有可能把系统打死，预热方式就是把为了保护系统，可慢慢的把流量放进来,慢慢的把阀值增长到设置的阀值。
让请求以均匀的速度通过,单机阈值为每秒通过数量，其余的排队等待。他还会设置一个超时时间，当请求超过超时时间还未处理，则会被丢弃.
注意:
阈值类型必须设置为QPS，否则无效
匀速排队模式暂时不支持 QPS > 1000 的场景。
例如：对资源/goods设置每秒1次请求，超过的话就排队等待，等待的超时时间为20000毫秒。
测试：
应用场景：
这种方式主要用于处理间隔性突发的流量，例如消息队列。在某一秒有大量的请求到来，而接下来的几秒则可能处于空闲状态，我们希望系统能够在接下来的空闲期间逐渐处理这些请求，以起到“削峰填谷”的效果，而不是拒绝所有请求。
Sentinel 熔断降级会在调用链路中某个资源出现不稳定状态时（例如调用超时或异常比例升高），对这个资源的调用进行限制，让请求快速失败，避免影响到其它的资源而导致级联错误。当资源被降级后，在接下来的降级时间窗口之内，对该资源的调用都自动熔断
熔断降级作为保护自身的手段，通常在客户端（调用端）进行配置。
选择以慢调用比例作为阈值，需要设置允许的慢调用RT（即最大的响应时间),请求的响应时间大于该值则统计为慢调用。当单位统计时长内请求数目大于设置的最小请求数目，并且慢调用比例大于阈值，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN状态)，若接下来的一个请求响应时间小于设置的慢调用RT则结束熔断,若大于设置的慢调用RT则会再次被熔断.
例如：以下配置的含义为：如果1秒内持续进入大于等于5个请求，并且请求响应的时间大于1000ms时，这个请求即为慢调用，当慢调用的比例大于0.5时会触发降级，熔断时间为5秒。
测试：
添加测试代码：
Jmeter中模拟多个慢应用并运行
再浏览器中访问test接口时，会被降级
如果1秒内持续进入大于等于最小请求数，并且请求出现异常的比例超过比例阈值时，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断
例如：如下配置为：如果1秒内持续进入大于等于5个请求，并且请求出现异常的比例超过0.5时，会触发降级
测试代码：
添加代码，模拟出异常情况
Jmeter中模拟多个慢应用并运行
浏览器中访问test2接口
如果1秒内持续进入大于等于最小请求数，并且请求出现异常的次数超过设置的异常数时，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN状态)，若接下来的一个请求响应时间小于设置的慢调用RT则结束熔断,若大于设置的慢调用RT则会再次被熔断.
触发熔断后的处理措施:
1.提供fallback实现服务降级
2.读缓存(DB访问降级)
3.返回错误result
1.1什么是热点参数流控
热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的 Top K 数据，并对其访问进行限制。比如：
商品 ID 为参数，统计一段时间内最常购买的商品 ID 并进行限制
用户 ID 为参数，针对一段时间内频繁访问的用户 ID 进行限制
热点参数限流会统计传入参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流。
热点参数限流可以看做是一种特殊的流量控制，仅对包含热点参数的资源调用生效。
1.2 测试
添加测试代码：
添加规则:
对资源getGoodsById中的第一个参数整体限流10，但对其中的id=1的值限流3.
当容量评估不到位，某个大流量接口限流配置不合理或者没有配置，导致系统崩溃，或者突然发现机器的load和CPU等开始飙升，但不能快速确认是什么原因造成等，这时候，需要一个全局的兜底防护方案，即使缺乏容量评估也能有一定的保护机制。这就是系统保护规则。
Sentinel系统自适应限流从整体维度对应入口流量进行控制，结合应用的Load、cup使用率、总体平均RT、入口QPS和并发线数等几个维度的监控指标，通过自适应的流控策略，让系统的入口流量和系统的负载达到一个平衡，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。
load自适应（仅对Linux/Unix系统有效）
当系统load1（1分钟平均负载）超过阈值，且并发线程数超过系统容量时触发。其中的load1，可以在Linux系统上通过命令 uptime 查看，这个命令返回3个值，分别为load1、load5、load15，表示系统1分钟的平均负载、5分钟的平均负载、15分钟的平均负载。
CPU usage（1.5.0+ 版本）： 当系统 CPU 使用率超过阈值即触发系统保护（取值范围 0.0-1.0），比较灵敏。
平均 RT： 当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护，单位是毫秒。
并发线程数： 当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。
入口 QPS： 当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护。
