1.开篇
前面的三篇文章分别介绍了sentinel中的流控规则、降级规则、热点规则，那么这篇文章来说一下关于@SentinelResource注解的作用。
在之前学习Hystrix的时候，有一个核心注解是@HystrixCommand，而阿里的sentinel中的@SentinelResource注解可以理解为@HystrixCommand的升级。
2.项目源码
github源码地址：https://github.com/2656307671/SpringCloud-Alibaba-Sentinel
gitee源码地址：https://gitee.com/szh-forever-young/SpringCloud-Alibaba-Sentinel
下面的测试对应了git仓库中的8401模块。前提是nacos启动成功、sentinel启动成功。
2.1 按资源名称限流
首先访问8401模块controller中的 /byResource 请求。需要先访问一次才可以在sentinel中看到它的信息。
接下来在sentinel的簇点链路中可以看到这个请求，我们来新增流控规则。
该配置的意思是：当1秒内byResource请求访问超过1次，则进行限流。这里我在@SentinelResource注解中配置了blockHandler属性，当触发限流之后，不再走sentinel默认的限流机制（Blocked by Sentinel），而是走我们自定义的限流方法（如下图）。
2.2 按URL地址限流
首先访问8401模块controller中的/rateLimit/byUrl 请求。需要先访问一次才可以在sentinel中看到它的信息。
在簇点链路这里可以看到有两个，如果说是按资源名称限流，就选第一个byUrl；如果是按URL地址限流，就选第二个。
这里配置的仍然是QPS超过1则触发限流，但是/rateLimit/byUrl 请求并没有我们自定义的限流方法，所以此时采用的就是sentinel默认的。
经过上面两个案例（按资源名称限流、按URL地址限流），我们会发现一些问题。
1. 系统默认的，没有体现我们自己的业务要求。
2. 依照现有条件，我们自定义的处理方法又和业务代码耦合在一块，不直观。
3. 每个业务方法都添加一个兜底的，那代码膨胀加剧。
4. 全局统一的处理方法没有体现。
这就引出了我们下面的案例，全局统一处理限流方法。
2.3 自定义限流处理逻辑
首先对应8401模块的controller中的/rateLimit/customerBlockHandler 请求，全局统一处理限流方法对应的是 handler 包下的 CustomerBlockHandler 这个类。
开启8401之后，先进行一次 /rateLimit/customerBlockHandler 请求的访问，然后到sentinel中设置它的限流逻辑信息，只要QPS > 1，则触发我们自定义的限流方法。在@SentinelResource注解中就对应着 blockHandlerClass、blockHandler 这两个属性，哪个类中的哪个方法是我们定义的全局限流方法。
上面的所有案例主要介绍了 @SentinelResource注解中的value、blockHandlerClass、blockHandler 这三个属性，分别对应的就是服务降级限流的相关配置。
下面的文章将介绍服务熔断，也就是@SentinelResource注解中的fallback属性。
