Sentinel监控SpringMVC的每一个端点（Endpoint），因此SpringMVC的每一个端点（Endpoint）就是调用链路中的一个资源。请求进入微服务时，访问DispatcherServlet，然后进入Controller、Service、Mapper，这样的一个调用链就叫做簇点链路。簇点链路中被监控的每一个接口就是一个资源。关于资源的进一步了解：跳转
以上述访问链路为例，其端点对应的就是：/order/{orderId}
后续我们的流控、熔断都将针对簇点链路中的资源进行发起。上面操作对应的规则汇总如下：
- 流控：流量控制
- 降级：熔断降级
- 热点：热点参数限流，限流的一种特殊使用场景
- 授权：请求的权限控制
3.1 快速上手
点击编辑资源 /order/{orderId} 的流控按钮
弹出表单如下，我们填写单机阈值：1，其含义是：限制资源/order/{orderId} 的QPS为1，即每秒只允许一次请求，超过的请求会被拦截并报错。
当我们快速刷新浏览器时，会发现出现下述错误信息
但一般来说生产的流量要更多，此处我们将借助于一个压测工具：Jmeter做更为全面的压力测试。
1 新增限流规则
新增一个流控规则，其QPS为5：
2 利用jmeter测试
开始压测之前，对于未使用过Jmeter的可以参考：Jmeter快速入门
导入提供的测试样例：📎sentinel测试.jmx，步骤如下：
确认一下：“流控入门，QPS<5”的请求路径、端口是否与自己本地一致
此规则如下：20个请求在2s内执行完成，此时生效的限流规则上面我们配置的为5（每秒最多5个请求通过）
右键启动运行
运行启动后会发现每秒能通过的请求最多5个（如下展示可能会乱序，以请求时间为准）：
此时，我们就完成了流量控制的入门效果，这一效果也是流控模式之一的直接模式。
3.2 流控模式
在上面的入门案例之后，我们已经实践了流控模式之一的直接模式，接下来我们将针对剩下的逐一实践。
1 直接模式
直接模式是什么
直接模式：针对当前资源的请求，触发阈值时就对当前资源直接限流，也是默认的模式。
直接模式适用于什么场景
对于没有明显差异、特殊化场景的都可以采用直接模式，它更简单易用
直接模式如何实现
参照上述：3.1 快速上手
2 关联模式
关联模式是什么
关联模式：统计与当前资源相关的另一个资源(相关或竞争)，触发阈值时对当前资源限流
关联模式适用于什么场景
在一个商城系统中，用户支付时需要修改订单状态，同时用户需要查询订单。查询和修改操作会争抢数据库锁(读速过高影响写、写速过高影响读速度)，争抢本身带来的开销会降低整体吞吐量。此时我们需要优先保证修改订单的功能，对查询对单业务限流。即当A触发条件时，被关联的资源B产生限流。
关联模式如何实现
针对上述场景，我们可以建立新的关联规则如下：
其规则含义为：当访问：/write接口的资源量触发阈值时（write有自己的流控规则）对：/read限流，从而避免对：/write资源的影响。下面我们结合实际案例来展开代码的实际编写。
- 在OrderController中新建两个端点(http接口)：/order/query 和 /order/update，不用实现具体细节
- 配置流控规则，当 /order/update 资源被访问的QPS超过5时，对 /order/query 请求限流
步骤一：
定义/order/query 端点，模拟订单查询
@GetMapping("/query") public String queryOrder() { return "查询订单成功"; }
步骤二：
定义/order/update 端点，模拟订单更新
@GetMapping("/update") public String updateOrder() { return "更新订单成功"; }
步骤三：
重启OrderApplication应用后，浏览器访问端点：http://localhost:8088/order/query、http://localhost:8088/order/update，访问Sentinel控制台，查看到新的端点信息：
配置流控规则如下：
需注意：我们是针对谁做限流，就点击对应资源的流控按钮，此处我们针对：/order/query
步骤四：
Jmeter压测验证，持续时长100s，qps=10，目的是持续造成超过配置阈值的窗口期，给用户访问验证的时间
运行后我们浏览器访问：http://localhost:8088/order/query，发现限流成功：
3 链路模式
链路模式是什么
链路模式：针对从指定链路访问到本资源的请求做统计，判断是否超过阈值
链路模式适用于什么场景
作为业务开发人员，我们有一个订单查询业务，同时输出做页面展现，访问链路：自身系统Controller-->查询订单接口。此时数据团队需要依赖我们的接口做驾驶舱信息，因为我们将查询订单接口暴露给别的团队，即新增一条访问链路：数据团队Controller-->查询订单接口。
自身系统的QPS我们根据压测做过合理评估，但是数据团队的请求我们并未考虑，假设有上万的请求过来，我们自身的系统性能也将收到明显影响。此时我们就需要将来自数据团队的调用加上限流。如下：
链路模式如何实现
步骤一：OrderService中添加一个queryGoods方法
public void queryGoods() { System.out.println("查询订单成功"); }
步骤二：OrderController中，改造/order/query端点，调用OrderService中的queryGoods方法
@GetMapping("/query") public String queryOrder() { orderService.queryGoods(); return "查询订单成功"; }
步骤三：OrderController中添加一个/order/save的端点，调用OrderService的queryGoods方法
@GetMapping("/save") public String saveOrder() { orderService.queryGoods(); return "存储订单成功"; }
步骤四：给queryGoods设置限流规则，从/order/query进入queryGoods的方法限制QPS必须小于2
注意：设置规则之前同样需要访问才会产生簇点链路，才可以针对性设置规则，因此需要重启服务+访问新接口
步骤五：启动Jmeter压测，预期/oder/save不受影响，而/order/query最多允许放行流量=2
