1. 流控规则介绍
- 资源名:
唯一名称，默认请求路径
- 针对来源:
Sentinel可以针对调用者进行限流，填写微服务名，默认default (不区分来源)
- 阈值类型/单机阈值?:
- QPS?：表示每秒钟的请求数量，当调用该 api 的 QPS 达到阈值的时候，进行限流。
- 线程数?: 当调用该 api 的线程数达到阈值的时候，进行限流
- 流控模式
- 直接?: api 达到限流条件时，直接限流
心- 关联?: 当关联的资源达到阈值时，就限流自己
- 链路?: 只记录指定链路上的流量（指定资源从入口资源进来的流量，如果达到阈值，就进行限流)【api级别的针对来源】
- 流控效果:
- 快速失败?: 直接失败，抛异常
- Warm Up?: 根据codeFactor(冷加载因子，默认3)的值，从阈值codeFactor，经过预热时长，才达到设置的QPS阈值
- 排队等待?: 匀速排队，让请求以匀速的速度通过，阈值类型必须设置为QPS，否则无效
2. 流控模式演示
2.1 直接（默认的）
- api 达到限流条件时，直接限流
1、为 /testA 请求设置流控规则
表示一秒钟查询一次就ok，若超过次数1，就直接-快速失败，报默认错误
?
?2、查看流控规则
?3、发出请求，体验限流
先是一秒点一次，可以正常访问
?连续点几次，出现提示语句
2.2 关联?
- 当关联的资源达到阈值时，就限流自己
- 实际场景 ：对于同级别的服务，比如?下订单、支付?两个服务，当?支付?流量过高，撑不住了，就限制一下?下单?服务，把资源留给?支付?服务，先撑过去。
1、修改上面建立的流控规则
当关联资源/testB的qps阈值超过1时，就限流/testA的Rest访问地址
?
2、使用 PostMan模拟并发密集访问testB,发出请求，体验限流
?
?
?
?
3、访问 /testA
?2.3 链路
- 只记录指定链路上的流量（指定资源从入口资源进来的流量，如果达到阈值，就进行限流)【api级别的针对来源】
1、修改上面建立的流控规则
?2、使用 Postman 对 /testB 进行连续访问
3、访问 /testA?
3. 流控效果演示
3.1 快速失败（默认的）
就是上面一直出现的提示界面
3.2 Warm Up（预热）
应用场景
官方说明 ：流量控制 · alibaba/Sentinel Wiki · GitHub
?
-
冷加载因子 ：默认 coldFactor 为 3，即请求 QPS 从 threshold/3 开始，经预热时长逐渐升至设定的QPS阈值。
-
限流 冷启动 ：https://github.com/alibaba/Sentinel/wiki/%E9%99%90%E6%B5%81—%E5%86%B7%E5%90%AF%E5%8A%A8
1、修改 流控效果
?2、一直发出 /testA 请求
发现刚开始提示 Blocked by Sentinel(flow limiting) 的频率比较高
越往后频率越低
最后几乎不会出现
这就是阈值再慢慢预热的过程
3.3 排队等待
- 让请求以匀速的速度通过，阈值类型必须设置为QPS，否则无效
- 每个请求，愿意等就等，不愿意等就超时重试
1、修改 流控效果
testA每秒一次请求，超过的话就排队等候，等待的超时时间为20000毫秒
2、在 Controller 中添加一行输出语句，打印时间
3、使用 Postman 模拟大量请求?
4、观察控制台?
?