启动8401微服务后台查看sentinel控制，啥也没有？=> Sentinel采用懒加载，执行两次访问http:localhost8401/testA，http:localhost8401/testB，效果如下：
名词说明：
资源名：唯一名字，默认请求路径
针对来源：Sentinel可以针对调用者进行限流，填写微服务名，默认default（不区分来源）
阈值类型/单机阈值：
QPS（每秒钟的请求数量）：当调用该API的QPS达到阈值的时候，进行限流
线程数：当调用该API的线程数达到阈值的时候，进行限流
是否集群：我们这里不需要集群
流控模式：
直接：API达到限流条件时，直接限流
关联：当关联的资源达到阈值时，就限流自己
链路：只记录指定链路上的流量（指定资源从入口资源进来的流量，如果达到阈值，就进行限流）【API级别的针对来源】
流控效果：
快速失败：直接失败，抛异常
Warm Up：根据codeFactor（冷加载因子，默认3）的值，从阈值/codeFactor，经过预热时长，才达到设置的QPS阈值
排队等待：匀速排队，让请求以匀速的速度通过，阈值类型必须设置为QPS，否则无效
流控模式
直接（默认）
配置：表示1秒钟内查询1次就是OK，若超过次数1，就直接快速失败，报默认错误
测试：快速点击访问 :8401/testA ⇒ Blocked by Sentinel(flow limiting)
思考：直接调用了默认报错信息，技术方面是没问题的，但是 是否因该有我们自己的后续处理呢？（类似有一个fallback的兜底方法），后面会讲到如何配置
关联
是什么：当关联的资源达到阈值时，就限流自己。当与A关联的资源B达到阈值后，就限流自己。例如B惹事A挂了
配置A：当关联资源/testB的QPS阈值超过1时，就限流/testA的Rest访问地址，当关联资源到阈值后限制配置好的资源名
postman模拟并发密集访问testB
访问B成功
postman里新建多线程集合组（Collection）
将访问地址添加进新线程组（Collection）
RUN ⇒ 大批量线程高并发访问B，导致A失效了
运行后发现testA挂了（点击访问A ⇒Blocked by Sentinel(flow limiting) ）
链路
多个请求调用了同一个微服务，相同道理，这里就不演示了
流控效果
快速失败
直接失败，抛出异常（Blocked by Sentinel(flow limiting)）
源码：com.alibaba.csp.sentinel.slots.block.controller.DefaultController
Warm Up（预热）
说明：公式 ⇒ 阈值除以coldFactor冷加载因子(默认值为3)，经过预热时长后才会达到阈值
源码：com.alibaba.csp.sentinel.slots.block.flow.controller.WarmUpController
Warm Up
Warm Up（RuleConstant.CONTROL_BEHAVIOR_WARM_UP）方式，即预热/冷启动方式。当系统长期处于低水位的情况下，当流量突然增加时，直接把系统提升到高水位可能瞬间把系统压垮。通过“冷启动”，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮。详细文档可以参考 流量控制 - Warm Up文档，具体的例子可见 WarmUpFlowDemo。
通常冷处理的过程系统允许通过的QPS曲线如下图所示：
WarmUp配置
多次点击:8401/testB，刚开始不行，后续慢慢OK
应用场景如：秒杀系统在开启瞬间，会有很多流量上来，很可能把系统打死，预热方式就是为了保护系统，可慢慢的把流量放进来，慢慢的把阈值增加到设置的阈值。
排队等待
匀速排队，阈值必须设置为QPS，否则无效
源码：com.ailibaba.csp.sentinel.slots.block.controller.RateLimiterController
匀速排队：