服务容错Sentinel的流控规则探究

1. 流控模式–直接

控制台设置流控

再次访问，QPS超过1就报异常

2. 流控模式–关联

当关联的资源达到阈值，就限流自己

场景：内容中心有两个API，一个是查询share表，另一个是修改share表的数据，这是高并发的应用，所以查询接口的调用速度过快，就会影响修改接口的性能，相反也一样。这时可以根据业务需求来衡量优先读还是优先修改！

如何希望优先修改可以以下配置：

这样修改比较频繁的时候，查询接口就会被限流

3. 流控模式–链路

只记录指定链路上的流量

• 图中针对来源。表示是针对某个微服务来限流。
• 图中入口资源。针对API级别，指定的API达到一定阈值就限流。

测试示例

编写两个API同时调用一个Service，使用sentinel对其中一个API限流。

1. 编写都请求的service

@Slf4j
@Service
public class TestService {
    @SentinelResource("common")
    public String common() {
        log.info("common....");
        return "common";
    }
}

2. 写两个controller接口调用上述Service

@Autowired
private TestService testService;

@GetMapping("test-a")
public String testA() {
    this.testService.common();
    return "test-a";
}

@GetMapping("test-b")
public String testB() {
    this.testService.common();
    return "test-b";
}

3. 启动项目分别访问两个接口

可以让sentinel控制台有他们的簇点

4. 给common设置流控

表示只对/test-a接口做流控。

发现并没有起到对/test-a接口限流的效果！！应该是版本更新的原因

参照这个官方项目的issue（https://github.com/alibaba/sentinel/issues/1213），加了个配置。

可以起到限流效果但是页面会报500，后端控制到报空指针

com.alibaba.csp.sentinel.slots.block.flow.FlowException: null

看到网上和官方有挺多解决方案的，现在先不管了！以后项目具体使用到再去踩坑！

4. 流控效果–快速失败

直接失败，抛异常

相关源码

• com.alibaba.csp.sentinel.slots.block.flow.controller.DefaultController

5. 流控效果–Warm Up

根据codeFactor(默认3)的值，从阈值/codeFactor，经过预热时长，才到达设置的QPS阈值

场景：比如一个秒杀微服务，平时访问不是很高，但活动秒杀的瞬间，流量激增，这是就可以使用Warm Up。让流量缓慢增加，在经过预热时间后才达到阈值，保护微服务。

官方的介绍文档：https://github.com/alibaba/Sentinel/wiki/限流—冷启动

相关源码：com.alibaba.csp.sentinel.slots.block.flow.controller.WarmUpController

6. 流控效果–排队等待

匀速排队，让请求以均匀的速度通过，阈值类型必须设成QPS，否则无效

场景：应对突发流量的场景。等突发时期过了，利用空闲时间处理请求。

官方介绍文档：https://qithub.com/alibaba/Sentinel/wiki/%E9%99%90%E6%B5%81—%E5%8C%80%E9%80%9F%E5%99%A8

相关源码：com.alibaba.csp.sentinel.slots.block.flow.controller.RateLimiterController