之八 2流高手速成记：基于Sentinel实现微服务体系下的限流与熔断( 二 ) _生活百科

我们将原有的select方法的返回值从原来的List<Person>升级为SelectPersonVo ，后者在前者原有基础上扩展了一个error字段，用于返回异常信息
接着是本节的关键：select方法新增@SentinelResource注解，我们前边讲过：Sentinel根据对应资源配置的规则来为资源执行相应的流控/降级/系统保护策略
因此这个注解的作用是——用于标明这是一个Sentinel系统中的资源

value代表这个资源的名称是person/select，这个名字可以随自己的习惯自定义
blockHandler指定了一个方法，这个方法在Sentinel系统触发某种规则的时候会被执行，关于“某种规则”我们稍后会讲

这里指定的selectBlock方法，在定义时是有硬性要求的：

1. 保留select方法一样的参数，外加一个BlockException参数
2. 返回值必须和select方法相同 —— 所以明白为什么要额外定义一个SelectRetVo了吧？

控制台的使用我们像上一节一样，分别启动provider和consumer，然后刷新Sentinel控制台页面

文章插图
看到这个界面的时候，你是否有种豁然开朗的感觉？
因为consumer中定义了Sentinel资源，所以当dubbo-nacos-consumer工程执行之后，控制台会有相关显示
而功能菜单中有N多项的名称都是XX规则，这也就是前边我们定义的blockHandler对应的某种规则
我们在post中调用consumer中的select方法，此时实时监控页面显示如下内容：

文章插图
这里的person/select自然就是我们定义的【资源】，控制台配套显示了其各项指标数据，很直观也很方便

下边还有一项/person/select（开头多个/），这个又是什么？这里先直接告诉大家答案——Sentinel默认会将所有Controller添加请求映射的方法视为资源
那我们额外添加一个@SentinelResource注解是否多此一举？答案是否，因为Controller生成的默认Sentinel资源是不带自定义规则触发方法的
因此@SentinelResource依然是有必要的，待本篇内容结束之后，大家可以自行验证这个说法

而从第二项【簇点链路】中，我们也能看到person/select和/person/select本身具备从属关系

文章插图
流控规则第三项【流控规则】对应了本节标题中提到的【限流】

文章插图
这里涉及到三个概念：
阈值类型

QPS —— 服务器每秒接受的最大请求数
线程数 —— 服务器能容忍的最大线程占用数，一般用于保护服务器的业务线程池不被耗尽

流控模式

直接 —— 默认项，接口到达限流要求时，规则直接生效
关联 —— 当关联在资源到达阈值时，直接限流自己，一般应用于效率让步的诉求
链路 —— 记录链路流量，当入口资源到达阈值，则限流自己

流控效果

快速失败 —— 默认项，超出阈值后新请求直接拒绝
排队等待 —— 让请求匀速通过（漏桶算法），每个请求在一个允许的延迟时长范围内
Warm up —— 冷启动模式，防止流量瞬间暴增直接将服务压垮，而是逐渐外放请求上限

我们先按图所示创建一个最简单的限流规则 —— QPS阈值为1，直接快速失败
而后我们启动两个post，同时向服务器端发送select请求，则结果对比如下：

文章插图

文章插图
由于QPS指定的阈值为1，因此同时发起的第二个请求会因触发限流规则而执行blockHandler方法
而我们针对阈值类型、流控模式、流控效果这三个指标交叉组合，可以创造出适用于各种服务器场景之下的限流规则
再比如我们按如下设置限流规则

文章插图
这种设置方式代表我们所能允许select方法同时请求的上限值为2000，但是这个数值是在5分钟（300秒）之间逐步放开的，比如我们用这种模式可以应对类似双11期间大力度优惠而带来的突发流量洪峰
通过【限流】可以很好的起到保护服务器的作用，在特殊时期针对流量进行削峰填谷，使得服务器处在一个长期稳定的环境