Sentine规则测试

流量控制

直接拒绝

• provider

@Override
public User testFlowQPSDefault(Long userId) {
    return new User(100L, "国产凌凌漆");
}

• consumer

/**
 * 限流测试 QPS 直接拒绝
 */
@Scheduled(cron = "0/10 * *  * * ? ")
public void testFlowQPSDefault() {
    for (int i = 1; i <= 10; i++) {
        try {
            log.info("{} : {} ", i, userService.testFlowQPSDefault(100L).getUserName());
        } catch (Exception e) {
            log.error("第 {} 个限流失败", i);
        }
    }
}

• 限流规则

[{"app":"titans-provider3","clusterMode":false,"controlBehavior":0,"count":6.0,"grade":1,"key":"1548575169161","limitApp":"titans-consumer","maxQueueingTimeMs":500,"resource":"@[email protected]:testFlowQPSDefault(java.lang.Long)","strategy":0,"warmUpPeriodSec":10}]

• 结果分析
  这个很好理解，每秒通过6个，其它的直接拒绝

2019-01-27 15:50:40.003 : 1 : 国产凌凌漆 
2019-01-27 15:50:40.005 : 2 : 国产凌凌漆 
2019-01-27 15:50:40.006 : 3 : 国产凌凌漆 
2019-01-27 15:50:40.007 : 4 : 国产凌凌漆 
2019-01-27 15:50:40.009 : 5 : 国产凌凌漆 
2019-01-27 15:50:40.011 : 6 : 国产凌凌漆 
2019-01-27 15:50:40.016 : 第 7 个限流失败
2019-01-27 15:50:40.020 : 第 8 个限流失败
2019-01-27 15:50:40.025 : 第 9 个限流失败
2019-01-27 15:50:40.031 : 第 10 个限流失败
......

预热冷启

• provider

@Override
public User testFlowQPSWarmUp(Long userId) {
    return new User(100L, "国产凌凌漆");
}

• consumer

/**
 * 限流测试 QPS Warm UP
 */
@Scheduled(fixedDelay = 50000)
public void testFlowQPSWarmUp() throws InterruptedException {
    for (int i = 1; i <= Integer.MAX_VALUE; i++) {
        // 前10个请求，让qps在一个非常低的水平
        if (i <= 10) {
            long time = System.currentTimeMillis() % 2000;
            if (time < 500) {
                time = 500;
            }
            Thread.sleep(time);
        }

        if (i > 10) {
            // 流量突然增大，为了方便测试，这里设置sleep为10之内，qps阈值为20，对于测试来说够了
            Thread.sleep(System.currentTimeMillis() % 10);
        }
        try {
            log.info("{} : {} ", i, userService.testFlowQPSWarmUp(100L).getUserName());
        } catch (Exception e) {
        }
    }
}

• 限流规则

[{"app":"titans-provider3","clusterMode":false,"controlBehavior":1,"count":20,"grade":1,"key":"1548575169161","limitApp":"titans-consumer","maxQueueingTimeMs":500,"resource":"@[email protected]:testFlowQPSDefault(java.lang.Long)","strategy":0,"warmUpPeriodSec":10}]

• 结果分析

【前10个请求qps很低】
2019-01-27 16:48:29.947  : 1 : 国产凌凌漆 
2019-01-27 16:48:31.897  : 2 : 国产凌凌漆 
......
2019-01-27 16:48:42.985  : 10 : 国产凌凌漆 

【qps突增加，在接下来的10s，要将QPS从一个很低的值增加要20，下面统计了接下来十几秒内每秒的QPS数量】

【42--3】
【43--6】
【44--7】
【45--7】
【46--7】
【47--8】
【48--9】
【49--9】
【50--10】
【51--12】
【52--14】
【53--17】
【54--20】
【55--20】
【56--20】
【57--20】

【从上面的结果可以看到，到54秒的时候，QPS达到了阈值20，之后就一直保持在20，这样算一下好像 42 到 54 秒超过了10秒中，这是因为第10个请求完成的时间是16:48:42.985，这接近43秒了，这样看偏差会更小一点】

匀速排队

count=10，maxQueueingTimeMs = 20000， count=10代表1s可以通过10个请求，所以每个请求平均100ms，maxQueueingTimeMs = 20000代表队中的请求最长等待时间为20s，也就是 大概能给处理 每秒/200 个请求

• provider
  如果时dubbo服务，主要设置dubbo服务的timeout >= 20000

/**
 * QPS 匀速排队
 *
 * @param userId
 * @return
 */
@Override
public User testFlowQPSPace(Long userId) throws InterruptedException {
    return new User(100L, "国产凌凌漆");
}

• consumer
  consumer 需要修改不同的并发数来达到测试效果， 并发数分别为：100、200、250

/**
 * 限流测试 QPS 匀速排队
 */
@Scheduled(fixedDelay = 100000)
public void testFlowQPSPace() throws InterruptedException {
    for (int i = 1; i <= 250; i++) {
        new Thread(() -> {
            try {
                TimeUnit.MILLISECONDS.sleep(5);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            try {
                log.info("{} ", userService.testFlowQPSPace(100L).getUserName());
            } catch (Exception e) {
                log.error(e.getMessage());
                log.error("请求被限流");
            }
        }).start();
    }
}

• 限流规则
  count=10，maxQueueingTimeMs = 20000， count=10代表1s可以通过10个请求，所以每个请求平均100ms，maxQueueingTimeMs = 20000代表队中的请求最长等待时间为20s，也就是 大概能给处理 每秒/200 个请求，当超过200请求/s 时，多出来的请求就会被直接拒绝

[{"app":"titans-provider3","clusterMode":false,"controlBehavior":2,"count":10,"grade":1,"key":"1548575169161","limitApp":"titans-consumer","maxQueueingTimeMs":20000,"resource":"@[email protected]:testFlowQPSPace(java.lang.Long)","strategy":0,"warmUpPeriodSec":10}]

• 结果分析

【100个并发，即 100请求/s 情况】
【观察时间，可以发现请求时匀速通过，每100ms一个，耗时大概10s】
2019-01-27 18:08:08.269  : 1 : 国产凌凌漆 
2019-01-27 18:08:08.368  : 2 : 国产凌凌漆 
......
2019-01-27 18:08:18.070  : 99 : 国产凌凌漆 
2019-01-27 18:08:18.168  : 100 : 国产凌凌漆


【200个并发，即 200请求/s 情况】
【观察时间，可以发现请求时匀速通过，每100ms一个，耗时大概20s】
2019-01-27 18:40:56.498  : 国产凌凌漆 
2019-01-27 18:40:56.676  : 国产凌凌漆
......
2019-01-27 18:41:15.868  : 国产凌凌漆 
2019-01-27 18:41:16.071  : 国产凌凌漆

【220个并发，即 220请求/s 情况，每100ms一个，大概有20个请求被直接降级】
2019-01-27 18:44:08.782 : 国产凌凌漆 
2019-01-27 18:44:08.829 : 国产凌凌漆 
2019-01-27 18:44:08.834 : 请求被限流
2019-01-27 18:44:08.834 : 请求被限流
......
2019-01-27 18:44:08.846 : 请求被限流
2019-01-27 18:44:08.928 : 国产凌凌漆 
2019-01-27 18:44:09.020 : 国产凌凌漆 
......

线程数

• provider

/**
 * 线程数
 *
 * @param userId
 * @return
 */
@Override
public User testFlowThread(Long userId) throws InterruptedException {
    // sleep 1000ms 是为了制造并发场景，其实可以当作时模拟服务调用，在sleep期间可能会堆积大量的请求
    Thread.sleep(1000);
    return new User(100L, "国产凌凌漆");
}

• consumer

@Scheduled(fixedDelay = 20000)
public void testFlowThread() throws InterruptedException {
    for (int i = 1; i <= 30; i++) {
        new Thread(() -> {
            try {
                log.info("{} ", userService.testFlowThread(100L).getUserName());
            } catch (Throwable e) {
                log.error("请求被限流");
            }
        }).start();
    }
}

• 限流规则
  count=20，代表线程数20为阈值

[{"app":"titans-provider3","clusterMode":false,"controlBehavior":0,"count":20.0,"grade":0,"key":"1548587521446","limitApp":"titans-consumer","maxQueueingTimeMs":500,"resource":"@[email protected]:testFlowThread(java.lang.Long)","strategy":0,"warmUpPeriodSec":10}]

• 结果分析

【通过21个，限流10个】
2019-01-27 19:58:45.001 E: 请求被限流
......
2019-01-27 19:58:45.006 E: 请求被限流
2019-01-27 19:58:06.019  国产凌凌漆 
2019-01-27 19:58:06.019  国产凌凌漆 
......

【通过20个，限流10个】
2019-01-27 19:58:45.001 E: 请求被限流
......
2019-01-27 19:58:45.006 E: 请求被限流
2019-01-27 19:58:25.965  : 国产凌凌漆 
2019-01-27 19:58:25.966  : 国产凌凌漆 
......

链路限流

-provider

/**
 * 链路限流，入口为testRefResource01的调用才会记录到 REF_RESOURCE 的限流统计当中
 *
 * @return
 * @throws BlockException
 */
@Override
public String testRefResource01() throws BlockException {
    testRefResource();
    return "国产凌凌漆";
}

/**
 * 链路限流，入口为testRefResource02的调用不会记录到 REF_RESOURCE 的限流统计当中
 *
 * @return
 * @throws BlockException
 */
@Override
public String testRefResource02() throws BlockException {
    testRefResource();
    return "国产凌凌漆";
}

/**
 * 链路限流，testRefResource01 和 testRefResource02 方法里面调用了这个方法，会根据REF_RESOURCE上的限流规则的refResource字段来决定是否对他们生效
 *
 * @throws BlockException
 */
private void testRefResource() throws BlockException {
    Entry entry = SphU.entry("REF_RESOURCE");
    if (entry != null) {
        entry.exit();
    }

}

• consumer
  为了查看限流效果，分别执行以下两个定时任务，为了测试方便，这里写到一起

/**
 * 入口为testRefResource01的调用才会记录到 REF_RESOURCE 的限流统计当中
 */
@Scheduled(fixedDelay = 1000)
public void testRefResource01() {
    for (int i = 1; i <= 10; i++) {
        try {
            log.info("{} : {}", i, userService.testRefResource01());
        } catch (Exception e) {
            log.error("第 {} 个限流失败", i);
        }
    }
}

/**
 * 入口为testRefResource02的调用不会记录到 REF_RESOURCE 的限流统计当中
 */
@Scheduled(fixedDelay = 1000)
public void testRefResource02() {
    for (int i = 1; i <= 10; i++) {
        try {
            log.info("{} : {}", i, userService.testRefResource02());
        } catch (Exception e) {
            log.error("第 {} 个限流失败", i);
        }
    }
}

• 限流规则
  这里的refResource指定为”@[email protected]:testRefResource01()“，代表REF_RESOURCE上这个规则只有在入口为”@[email protected]:testRefResource01()“时才会生效

[{"app":"titans-provider3","clusterMode":false,"controlBehavior":0,"count":6.0,"grade":1,"key":"1548675382541","limitApp":"titans-consumer","maxQueueingTimeMs":500,"refResource":"@[email protected]:testRefResource01()","resource":"REF_RESOURCE","strategy":2,"warmUpPeriodSec":10}]

• 结果分析

【运行定时任务testRefResource01的结果如下，规则生效了】
2019-01-28 19:45:16.830 : 1 : 国产凌凌漆
2019-01-28 19:45:16.831 : 2 : 国产凌凌漆
2019-01-28 19:45:16.833 : 3 : 国产凌凌漆
2019-01-28 19:45:16.835 : 4 : 国产凌凌漆
2019-01-28 19:45:16.837 : 5 : 国产凌凌漆
2019-01-28 19:45:16.839 : 6 : 国产凌凌漆
2019-01-28 19:45:16.841 : 第 7 个限流失败
2019-01-28 19:45:16.843 : 第 8 个限流失败
2019-01-28 19:45:16.845 : 第 9 个限流失败
2019-01-28 19:45:16.849 : 第 10 个限流失败


【运行定时任务testRefResource01的结果如下，规则没有生效，符合预期】
2019-01-28 19:46:38.777  : 1 : 国产凌凌漆
......
2019-01-28 19:46:39.827  : 10 : 国产凌凌漆

【测试结果符合预期，测试成功】

关联限流

• provider

/**
 * 关联限流，读方，对读方设置限流规则 strategy = RuleConstant.STRATEGY_RELATE，refResource = 写方，其中的count代表允许 【写方】每秒通过的请求数
 *
 * @return
 */
@Override
public String testRefResourceRelateRead() throws InterruptedException {
    Thread.sleep(300);
    return "国产凌凌漆";
}

/**
 * 关联限流，写方
 *
 * @return
 */
@Override
public String testRefResourceRelateWrite(int i) throws InterruptedException {
    Thread.sleep(200);
    return "国产凌凌漆";
}

• consumer
  下面两个定时任务分别代表读方和写方，为了便于观察结果，按以下顺序进行操作
  1、不设置任何限流规则，启动读方，观察日志输出；
  2、不设置任何限流规则，启动读方，然后启动写方，观察日志输出；
  3、通过provider的代码可以发现，写方的QPS小于5，这时候对读方添加限流规则，count 分别设置小于5，大于5，启动读方，然后启动写方，观察日志输出；

/**
 * 关联限流，读方， 对读方设置限流规则 strategy = RuleConstant.STRATEGY_RELATE，refResource = 写方，其中的count代表允许 【写方】每秒通过的请求数
 */
@Scheduled(fixedDelay = 1000)
public void testRefResourceRelateRead() {
    for (int i = 1; i <= Integer.MAX_VALUE; i++) {
        try {
            log.info("{} : {}", i, userService.testRefResourceRelateRead());
        } catch (Exception e) {
            log.error("读方第 {} 个限流失败", i);
        }
    }
}


/**
 * 关联限流，写方
 */
@Scheduled(fixedDelay = 1000)
public void testRefResourceRelateWrite() {
    log.info("写方开始启动");
    for (int i = 1; i <= Integer.MAX_VALUE; i++) {
        try {
            log.info("{} : {}", i, userService.testRefResourceRelateWrite(i));
        } catch (Exception e) {
            log.error("写方第 {} 个限流失败，这个按理来说不会打印", i);
        }
    }
}

• 限流规则
  分别设置以下规则，count值是针对于写方的，即当写方的QPS大于count之后，开始对读方完全限流。
  这里的refResource指定为”@[email protected]:testRefResourceRelateWrite(int)“，也就是写方，代表写方的QPS到达count值时对读方限流

[{"app":"titans-provider3","clusterMode":false,"controlBehavior":0,"count":3.0,"grade":1,"key":"1548679522569","limitApp":"titans-consumer","maxQueueingTimeMs":500,"refResource":"@[email protected]:testRefResourceRelateWrite(int)","resource":"@[email protected]:testRefResourceRelateRead()","strategy":1,"warmUpPeriodSec":10}]


[{"app":"titans-provider3","clusterMode":false,"controlBehavior":0,"count":6.0,"grade":1,"key":"1548679522569","limitApp":"titans-consumer","maxQueueingTimeMs":500,"refResource":"@[email protected]:testRefResourceRelateWrite(int)","resource":"@[email protected]:testRefResourceRelateRead()","strategy":1,"warmUpPeriodSec":10}]

• 结果分析

1、【不设置规则，只启动读方，日志输出正常，读方没有被限流】
2、【不设置规则，先启动读方，然后启动写方，日志输出正常，读方没有被限流】
3、【设置规则，count=3，先启动读方，然后启动写方，在写方启动之后读方开始被完全限流，关闭写方之后读方恢复正常】
4、【设置规则，count=6，先启动读方，然后启动写方，日志输出正常，读方没有被限流】

熔断降级

RT

• provider

/**
 * 理想情况
 * 平均响应时间阈值为20毫秒，第40个请求的时候，平局响应时间为20毫秒， 接下来的5个请求 sleep 时间为 41，42，43，44，45
 * 这5个请求的RT均超过阈值， 接下来时间窗口内的请求将被直接拒绝  2s
 *
 * 

 * 实际情况
 * 考虑服务调用本身的耗时，每个服务调用大概需要1-3ms，这里估算2ms
 *
 * @param userId 这里的userId为1-1000的递增数字
 * @return
 * @throws InterruptedException
 */
@Override
public User testDegrRT(Long userId) throws InterruptedException {
    Thread.sleep(userId % 50);
    return new User(100L, "国产凌凌漆");
}

• consumer

/**
 * 测试降级，RT timeWindow 2s, count 20ms，10s执行一次
 */
@Scheduled(cfixedDelay = 10000)
public void testDegrRT() {
    for (int i = 1; i <= 1000; i++) {
        try {
            log.info("{} : {} ", i, userService.testDegrRT(Long.valueOf(i)).getUserName());
        } catch (Exception e) {
        }
    }
}

• 限流规则
  指定时间窗口为2s，阈值为20ms

[{"app":"titans-provider3","count":20.0,"cut":false,"grade":0,"key":"1548391072645","limitApp":"titans-consumer","passCount":0,"resource":"@[email protected]","timeWindow":2}]

• 测试结果

【第一个10s之内的请求数】
2019-01-25 13:01:00.067   [pool-2-thread-1]   : 1 : 国产凌凌漆 
...... 
2019-01-25 13:01:01.007   [pool-2-thread-1]   : 41 : 国产凌凌漆 
2019-01-25 13:01:01.050   [pool-2-thread-1]   : 42 : 国产凌凌漆 
【加上服务调用本身的时间，第37个请求的时候平均响应时间达到了20，后面5个请求的响应时间都超过了20，所以对这5个请求之后的2s之内的请求直接降级】

【2s过后，接下来的5个请求响应时间都大于20(对50取余)，所以这5个请求通过后，接下来的请求被直接降级，即 577 -1000 的请求被直接降级了，所以没有打印】
2019-01-25 13:01:03.078   [pool-2-thread-1]   : 572 : 国产凌凌漆 
2019-01-25 13:01:03.103   [pool-2-thread-1]   : 573 : 国产凌凌漆 
2019-01-25 13:01:03.129   [pool-2-thread-1]   : 574 : 国产凌凌漆 
2019-01-25 13:01:03.156   [pool-2-thread-1]   : 575 : 国产凌凌漆 
2019-01-25 13:01:03.183   [pool-2-thread-1]   : 576 : 国产凌凌漆 


【消费端定时任务休息了10s之后继续发送请求，这时候上面总共通过了47个请求，平均响应时间 （42*43/2 + 24*3）/47 + 每个请求实际耗时1-2ms】
【上面计算的这个结果是大于20的，但是马上又被接下来的请求耗时给平均下去了】
2019-01-25 13:01:10.004   [pool-2-thread-1]   : 1 : 国产凌凌漆 
......
2019-01-25 13:01:10.893   [pool-2-thread-1]   : 40 : 国产凌凌漆 
2019-01-25 13:01:10.936   [pool-2-thread-1]   : 41 : 国产凌凌漆 
【前面41个请求和第一个10s类似，不过因为第一个10s内的请求平均耗时大于20s，所以这里的平均响应时间提前达到阈值，即 41 的时候就到了】

【接下来类似，只要平均响应到了20 ，就判断接下来的5个请求是否大于阈值，大于就降级 2s】
2019-01-25 13:01:12.944   [pool-2-thread-1]   : 556 : 国产凌凌漆 
......
2019-01-25 13:01:13.597   [pool-2-thread-1]   : 585 : 国产凌凌漆 
2019-01-25 13:01:13.633   [pool-2-thread-1]   : 586 : 国产凌凌漆 

异常比例

这种方式的降级和上面稍有不同，在dubbo服务中，平均RT中的资源可以是接口，也可以时具体的方法，但在和异常相关的降级中，资源只能是方法。 每秒的异常数/每秒的请求量 如果大于阈值，就会在接下来的时间窗口内降级，有一个需要注意的地方，这一秒的请求数达到5之后才会开始计算

• provider

/**
 * 理想情况
 * 每100毫秒一个请求，一秒钟可以处理10个请求，阈值设置为0.1，timeWindow为2s
 * 

 * 这里每3个请求抛出一个异常，1s之内抛出的异常数大于 10%， 所以会被降级2s , 接下来又是一个周期
 *
 * @param userId
 * @return
 * @throws InterruptedException
 */
@Override
public User testDegrRatio(Long userId) throws InterruptedException {
    Thread.sleep(100);
    if (userId % 3 == 0) {
        throw new NullPointerException("手动抛出一个业务异常");
    }
    return new User(100L, "国产凌凌漆");
}

• consumer

@Scheduled(fixedDelay = 10000)
public void testDegrRatio() {
    for (int i = 1; i <= 100; i++) {
        try {
            log.info("{} : {} ", i, userService.testDegrRatio(Long.valueOf(i)).getUserName());
        } catch (Exception e) {
            if (e instanceof NullPointerException) {
                log.error("第 {} 个请求被手动抛出业务异常", i);
            }

            if (e instanceof RpcException) {
                log.error("第 {} 个限流失败", i);
            }
        }
    }
}

• 降级规则
  指定时间窗口为2s，阈值为0.1，

[{"app":"titans-provider3","count":0.1,"cut":false,"grade":1,"key":"1548558413966","limitApp":"titans-consumer","passCount":0,"resource":"@[email protected]:testDegrRatio(java.lang.Long)","timeWindow":2}]

• 测试结果

2019-01-27 13:07:14.584 : 1 : 国产凌凌漆 
2019-01-27 13:07:14.687 : 2 : 国产凌凌漆 
2019-01-27 13:07:14.790 : 第 3 个请求被手动抛出业务异常
2019-01-27 13:07:14.891 : 4 : 国产凌凌漆 
2019-01-27 13:07:14.992 : 5 : 国产凌凌漆 

【第3个请求抛出了一个业务异常，但是接下来并没有被直接降级，因为这里还有一个隐藏条件，当这一秒的请求数达到5之后才开始计算，所以第六个请求就被直接降级了】
【而时间窗口定义为2s,该2s内直接拒绝100个请求】
2019-01-27 13:07:14.998 : 第 6 个限流失败
2019-01-27 13:07:15.003 : 第 7 个限流失败
......
2019-01-27 13:07:15.370 : 第 99 个限流失败
2019-01-27 13:07:15.373 : 第 100 个限流失败

异常数量

一分钟内的以异常数如果超过一个阈值，在接下来的timeWindow内服务将处于降级状态，如果timeWindow小于60， 结果是不精确的，所以强烈建议将timeWindow的值设置为大于或者等于60

• provider

/**
 * 理想情况
 * 每1秒一个请求，一分钟可以处理60个请求，阈值设置为6，每5个请求抛出一个异常，30个请求之后异常数达到阈值，此时耗时30，
 * 然后根据timeWindow进行降级，这时候分两种情况
 * 1、当timeWindow小于60，这时候降级时间是不精确的，不推荐这种做法
 * 

 * 2、当timeWindow>=60, 限流时间 从 第一个降级请求开始算，在接下来的timeWindow内，服务将处于降级状态，
 * 例如第一个降级请求时间是：15:01:10.619， timeWindow=70，那么在 15:01:10.619 - 15:02:20.619 这段时间内服务将处于降级状态
 *
 * @param userId
 * @return
 * @throws InterruptedException
 */
@Override
public User testDegrCount(Long userId) throws InterruptedException {
    Thread.sleep(1000);
    if (userId % 5 == 0) {
        throw new NullPointerException("手动抛出一个业务异常");
    }
    return new User(100L, "国产凌凌漆");
}

• consumer

/**
 * 测试降级， 一分钟之内业务异常数, timeWindow 40s, count 6
 */
@Scheduled(fixedDelay = 10000)
public void testDegrCount() {
    for (int i = 1; i <= 100; i++) {
        try {
            log.info("{} : {} ", i, userService.testDegrCount(Long.valueOf(i)).getUserName());
        } catch (Exception e) {
            if (e instanceof NullPointerException) {
                log.error("第 {} 个请求被手动抛出业务异常", i);
            }

            if (e instanceof RpcException) {
                log.error("第 {} 个限流失败", i);
            }
        }
    }
}

• 降级规则

[{"app":"titans-provider3","count":6.0,"cut":false,"grade":2,"key":"1548569038841","limitApp":"titans-consumer","passCount":0,"resource":"@[email protected]:testDegrCount(java.lang.Long)","timeWindow":50}]

• 测试结果
  这一步的结果分析可能会更复杂一些，所以一些连续性的日志我会省略，但不影响分析结果

【13:44:26.187 完成第一个请求】

2019-01-27 13:44:26.187 : 1 : 国产凌凌漆 
......
2019-01-27 13:44:30.196 : 第 5 个请求被手动抛出业务异常
2019-01-27 13:44:31.199 : 6 : 国产凌凌漆 
......
2019-01-27 13:44:35.207 : 第 10 个请求被手动抛出业务异常
2019-01-27 13:44:36.208 : 11 : 国产凌凌漆 
......
2019-01-27 13:44:40.214 : 第 15 个请求被手动抛出业务异常
2019-01-27 13:44:41.216 : 16 : 国产凌凌漆 
......
2019-01-27 13:44:45.223 : 第 20 个请求被手动抛出业务异常
2019-01-27 13:44:46.224 : 21 : 国产凌凌漆 
......
2019-01-27 13:44:50.230 : 第 25 个请求被手动抛出业务异常
2019-01-27 13:44:51.232 : 26 : 国产凌凌漆 
...... 
2019-01-27 13:44:55.238 : 第 30 个请求被手动抛出业务异常

【13:44:55.238 完成第30个请求，耗时30s多一点点，这时候总共抛出了6个业务异常 】

【count=6, timeWindow=40, 因为这时候count已经达到了6，所以第31个请求开始降级】
2019-01-27 13:44:55.243 : 第 31 个限流失败
2019-01-27 13:44:55.248 : 第 32 个限流失败

......这里省略一部分......

2019-01-27 13:44:55.559 : 第 98 个限流失败
2019-01-27 13:44:55.565 : 第 99 个限流失败
2019-01-27 13:44:55.569 : 第 100 个限流失败

【请求被直接降级，所以在上一任务最后一个请求完成之后，即13:44:55.569，等待10s，又开始一个新任务，这时候时间刚好过去40s多一点，所以这一轮的请求被直接降级】
2019-01-27 13:45:05.574 : 第 1 个限流失败
2019-01-27 13:45:05.578 : 第 2 个限流失败

......这里省略一部分......

2019-01-27 13:45:05.936 : 第 98 个限流失败
2019-01-27 13:45:05.939 : 第 99 个限流失败
2019-01-27 13:45:05.943 : 第 100 个限流失败

【又是一轮任务，这时候时间过去50s多一点，还在一分钟之内，所以请求被直接降级】
2019-01-27 13:45:15.948 : 第 1 个限流失败
2019-01-27 13:45:15.952 : 第 2 个限流失败

......这里省略一部分......

2019-01-27 13:45:16.326 : 第 98 个限流失败
2019-01-27 13:45:16.329 : 第 99 个限流失败
2019-01-27 13:45:16.333 : 第 100 个限流失败

【这里又开始了一轮任务，其实还是有点疑问，按理来说，这时候一分钟已经结束了，应该不会被限流，因为是计算有一些误差】
2019-01-27 13:45:26.349 : 第 1 个限流失败
2019-01-27 13:45:26.356 : 第 2 个限流失败

......这里省略一部分......

2019-01-27 13:45:26.709 : 第 98 个限流失败
2019-01-27 13:45:26.713 : 第 99 个限流失败
2019-01-27 13:45:26.716 : 第 100 个限流失败

【上一轮降级完成之后，又开始下一轮降级】
2019-01-27 13:45:37.718 : 1 : 国产凌凌漆 
2019-01-27 13:45:38.719 : 2 : 国产凌凌漆 
2019-01-27 13:45:39.721 : 3 : 国产凌凌漆 
2019-01-27 13:45:40.722 : 4 : 国产凌凌漆 
2019-01-27 13:45:41.724 : 第 5 个请求被手动抛出业务异常
2019-01-27 13:45:42.725 : 6 : 国产凌凌漆 
2019-01-27 13:45:43.726 : 7 : 国产凌凌漆 
2019-01-27 13:45:44.728 : 8 : 国产凌凌漆 
2019-01-27 13:45:45.729 : 9 : 国产凌凌漆 

考虑到这里需要根据不同的timeWindow考虑各种情况，下面是一个结果汇总

当 timeWindow = 20 的时候， 第1个请求 完成时间  14:47:03.402， 第30个请求完成时间 14:47:32.483。接下来就是降级，在 14:48:04.031 的时候还处于降级状态，在 14:48:15.033 的时候处于非降级状态

当 timeWindow = 30 的时候， 第1个请求 完成时间  14:43:27.979， 第30个请求完成时间 14:43:57.054。接下来就是降级，在 14:44:49.285 的时候还处于降级状态，在 14:45:00.287 的时候处于非降级状态

当 timeWindow = 40 的时候， 第1个请求 完成时间  14:53:12.703， 第30个请求完成时间 14:53:41.834。接下来就是降级，在 14:54:13.409 的时候还处于降级状态，在 14:54:24.411 的时候处于非降级状态

当 timeWindow = 50 的时候， 第1个请求 完成时间  14:56:01.244， 第30个请求完成时间 14:56:30.345。接下来就是降级，在 14:57:12.310 的时候还处于降级状态，在 14:57:23.315 的时候处于非降级状态

【当timeWindow>=60, 限流时间 从 第一个降级请求开始算，在接下来的timeWindow内，服务将处于降级状态， 例如第一个降级请求时间是：15:01:10.619， timeWindow=70，那么在 15:01:10.619 - 15:02:20.619 这段时间内服务将处于降级状态】
当 timeWindow = 60 的时候， 第1个请求 完成时间  15:00:41.495， 第30个请求完成时间 15:01:10.619。接下来就是降级，在 15:02:03.071 的时候还处于降级状态，在 15:02:14.075 的时候处于非降级状态
当 timeWindow = 60 的时候， 第1个请求 完成时间  15:02:14.075， 第30个请求完成时间 15:02:43.140。接下来就是降级，在 15:03:35.314 的时候还处于降级状态，在 15:03:46.316 的时候处于非降级状态     

当 timeWindow = 70 的时候， 第1个请求 完成时间  15:05:08.084， 第30个请求完成时间 15:05:37.145。接下来就是降级，在 15:06:39.727 的时候还处于降级状态，在 15:06:50.730 的时候处于非降级状态
当 timeWindow = 70 的时候， 第1个请求 完成时间  15:06:50.730， 第30个请求完成时间 15:07:19.775。接下来就是降级，在 15:08:22.343 的时候还处于降级状态，在 15:08:33.345 的时候处于非降级状态

从上面的结果可以看到，timeWindow 在 小于60 的时候， 降级时间是没有规律的，即降级死不精确的，当timeWindow>=60, 限流时间 从 第一个降级请求开始算，在接下来的timeWindow内，服务将处于降级状态， 例如第一个降级请求时间是：15:01:10.619， timeWindow=70，那么在 15:01:10.619 - 15:02:20.619 这段时间内服务将处于降级状态。

权限控制

权限控制用于控制哪些调用方可以通过请求，比如指定服务A只有服务B才可以调用，或者只有服务B不可以调用，通过规则中得limitApp来控制

白名单

• provider

/**
 * 权限测试，黑名单，只有titans-consumer,titans-consumer2 才能调用
 *
 * @param userId
 * @return
 */
@Override
public User testAuthWhite(Long userId) {
    return new User(100L, "国产凌凌漆");
}

• consumer

/**
 * 权限测试 白名单，只有titans-consumer,titans-consumer2 才能调用，其它都不可以调用
 */
@Scheduled(fixedDelay = 10000)
public void testAuthWhite() {
    for (int i = 1; i <= 10; i++) {
        try {
            log.info("{} : {} ", i, userService.testAuthWhite(100L).getUserName());
        } catch (Exception e) {
            log.error("第 {} 个限流失败", i);
        }
    }
}

• 权限规则

[{"app":"titans-provider3","key":"1548592173001","limitApp":"titans-consumer,titans-consumer2","resource":"@[email protected]:testAuthWhite(java.lang.Long)","strategy":0}]

• 结果分析

【调用方是 titans-consumer 时，调用成功】

【调用方是 titans-consumer2 时，调用成功】

【调用方是 titans-consumer3 时，调用失败】

黑名单

• provider

/**
 * 权限测试，黑名单，只有titans-consumer,titans-consumer2 不能调用
 *
 * @param userId
 * @return
 */
@Override
public User testAuthBlack(Long userId) {
    return new User(100L, "国产凌凌漆");
}

• consumer

@Scheduled(fixedDelay = 10000)
public void testAuthBlack() {
    for (int i = 1; i <= 10; i++) {
        try {
            log.info("{} : {} ", i, userService.testAuthBlack(100L).getUserName());
        } catch (Exception e) {
            log.error("第 {} 个限流失败", i);
        }
    }
}

• 权限规则

[{"app":"titans-provider3","key":"1548592326969","limitApp":"titans-consumer,titans-consumer2","resource":"@[email protected]:testAuthBlack(java.lang.Long)","strategy":1}]

• 结果分析

【调用方是 titans-consumer 时，调用失败】

【调用方是 titans-consumer2 时，调用失败】

【调用方是 titans-consumer3 时，调用成功】

【调用方是 titans-consumer4 时，调用成功】