四.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 达到阈值即触发系统保护。