在sentinel控制台的簇点链路里可以看到我们监控的请求，而针对每个请求又有不同的操作，分别是流控、降级、热点、授权。
接下来我们了解流控的部分。
点击新增流控可以看到如下页面。
新增流控就是要配置流控规则。
那么什么是流控规则呢？
1.流控规则
流量控制，其原理是监控应用流量得QPS或并发线程数等指标，当达到指定阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮，从而保障应怡红的高可用性。
官网给出的详细流控规则文档：https://github.com/alibaba/Sentinel/wiki/%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6
下面是我自己整理的一部分：
- 资源名：唯一名称，默认请求路径
- 针对来源：Sentinel可以针对调用者进行限流，填写微服务名，默认default（不区分来源）
- 阈值类型/单机阈值
- QPS(每秒钟请求数量)：当调用该api的QPS达到阈值的时候进行限流。
- 线程数：当调用该api的线程数达到阈值的时候进行限流
- 是否集群：不需要集群
- 流控模式：
- 直接：api达到限流条件时直接限流
- 关联：当关联的资源达到阈值时，就限流自己
- 链路：只记录指定链路上的额流量（指定资源从入口资源进来的流量，如果达到阈值，就进行限流）
- 流控效果：
- 快速失败：直接失败，抛异常
- Warm Up：根据codeFactor（冷加载因子，默认3）的值，从阈值/codeFactor，经过预热时长，才达到设置的QPS阈值
- 排队等待：匀速派对，让请求以匀速的速度通过，阈值类型必须设置为QPS，否则无效
2.QPS直接失败
接下来我们给A请求新增一个QPS直接失败的规则
我们设置的阈值是1，意思是当每秒请求数大于1的时候就会触发流控。
新增好后可以在流控规则的菜单里看到我们刚刚新增的。
接下来我们测试一下。
慢一点发送请求的时候是正常的
一直点的时候就会触发流控了
这就说明我们QPS的限流配置成功了
3.线程数直接失败
我们直接修改刚刚的流控规则就可以了
接下来我们要稍微修改一下controller里的代码，因为流控判断的标准是线程数，我们要模拟多个线程处理的话最好让线程睡上两秒钟
接下来我们继续测试，注意我们这次开两个窗口来发送请求，那么一定有一个成功了一个没成功。
可以看到我们线程数的规则也生效了。
4.关联
由于微服务系统中各个服务之间是互相调用的，如果A服务要请求B服务，那么当A服务达到流控阈值的时候，B服务也应该无法访问。
比如，一个场景，需要我们先下单再支付，那么如果订单服务挂掉了，就不允许请求再发往支付服务了。
我们再编辑一下流控规则（QPS和线程数的效果是一样的，我就都用QPS来测试了）
接下来我们用postman来循环发送请求B。如果规则生效的话，那么我们的A就访问不了了。
我们设置循环20此，每次间隔0.3秒，因为B请求没有设置限流规则，因此是不会被限流的。
在循环的过程中我们来观察A请求。
我们可以看到A请求失败了，因为我们设置了A和B请求的关联规则
5.预热
首先来看官方文档解释的预热
什么意思呢？
比如秒杀场景、整点抢购场景，原来的系统处于平稳状态，不会有那么多的流量，而一旦活动开始了，巨大的流量突然涌向系统，容易导致系统瘫痪，这时候可以使用我们的预热机制把流量慢慢的放进来，慢慢延长阈值。
公式：阈值初一coldFactory（默认值是3），经过预热时长后才会达到阈值。
那么接下来我再新增一个预热的流控规则
这个规则的意思是：默认coldFactor为3，即请求QPS从(threshole/3)开始，经过预热时长逐渐升至设定的QPS阈值。
也就是说系统初始化的阈值为10/3约等于3；然后经过5s后阈值才慢慢提升至10。
我们只要在浏览器访问该接口一直刷新就可以看到效果了。
6.匀速排队
也就是说让系统匀速处理请求，而不是忙的时候忙死，闲的时候闲死。
接下来我们再编辑一下流控规则
我们再用postman循环发送请求也是可以测出来的。
