SpringCloud Alibaba——Sentinel服务熔断与限流（四@SentinelResource注解）

Posted 2021-09-11 张起灵-小哥

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属性。