目录
说明:
由于部分渠道的不良访问,在一段时间内大量访问服务,导致服务后台处理很多无用的数据,并且项目目前部署不是很完善,正式环境只有两台机器,并发量大了很容易宕机并且影响其他渠道,所以先使用流控策略,控制QPS,外加参数校验,过滤掉异常请求。
1.下载资源
原文参考:dashboard
06-Sentinel限流熔断应用实践_雨田说码-CSDN博客
2.运行服务
nohup java -Dserver.port=9903 -Dcsp.sentinel.dashboard.server=139.9.178.38:9903 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard-1.8.3.jar > sentinel.log 2>&1 &
运行服务后登陆浏览器 登陆 http://ip:port
在这里我们会看到整个页面空空如也,即便你的微服务已经启动了,但这里依旧什么都没有。
不必惊慌,这不是程序BUG,也不是配置出了问题,而是sentinel采用了懒加载的方式加载服务信息,也就是说,我们需要访问一次服务接口,这里就会显示服务的信息了。
3.客户端配置
3.1 引入依赖
<!-- 这里我使用的是2.3.6.RELEASE版本,为了和其他服务保持一致 -->
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.3.6.RELEASE</version>
</parent>
<!-- 所以这里没有尝试过高的版本 -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
<version>2.2.3.RELEASE</version>
</dependency>
3.2 添加配置
spring:
cloud:
sentinel:
transport:
dashboard: your_ip:9903 # 服务端ip和端口,需要和服务端保持一致
3.2 初始化接口信息
由于是懒加载,所以这里需要访问一下接口初始化监测信息
4.流控规则
5.踩坑记录
5.1 依赖问题
一开始跟着官方文档来,在客户端加入了csp的包,导致提示com.alibaba.csp.sentinel.spi.SpiLoader找不到
解决方法:
删除掉csp的包,只留下 spring-cloud-starter-alibaba-sentinel包,访问服务启动正常
5.2 在集成环境中问题
在其他服务中,因为用到了nacos,redis,kafka,admin等分布式组件导致相同的pom依赖和配置无法运行
我记得我服务中是没有用到hibernate的校验的,大胆猜测是其他组件中用到了
网上也给出了这个问题的解决办法,有的建议添加一个hibernate-validator的坐标拉取依赖,我这边拉取包失败
最后选择了springboot的校验包后成功启动服务
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-validation</artifactId>
</dependency>
访问sentinel服务,可以看到访问的QPS
6.动态加载规则
6.1 配置中心
配置中心可以选择nacos、zookeeper
相关使用详细后续补上
7.熔断降级
7.1 熔断
参考文档:Wiki - Gitee.com
https://github.com/alibaba/Sentinel/wiki/%E7%86%94%E6%96%AD%E9%99%8D%E7%BA%A7
除了流量控制以外,对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。一个服务常常会调用别的模块,可能是另外的一个远程服务、数据库,或者第三方 API 等。例如,支付的时候,可能需要远程调用银联提供的 API;查询某个商品的价格,可能需要进行数据库查询。然而,这个被依赖服务的稳定性是不能保证的。如果依赖的服务出现了不稳定的情况,请求的响应时间变长,那么调用服务的方法的响应时间也会变长,线程会产生堆积,最终可能耗尽业务自身的线程池,服务本身也变得不可用。
Sentinel 提供以下几种熔断策略:
- 慢调用比例 (
SLOW_REQUEST_RATIO
):选择以慢调用比例作为阈值,需要设置允许的慢调用 RT(即最大的响应时间),请求的响应时间大于该值则统计为慢调用。当单位统计时长(statIntervalMs
)内请求数目大于设置的最小请求数目,并且慢调用的比例大于阈值,则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态(HALF-OPEN 状态),若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断,若大于设置的慢调用 RT 则会再次被熔断。 - 异常比例 (
ERROR_RATIO
):当单位统计时长(statIntervalMs
)内请求数目大于设置的最小请求数目,并且异常的比例大于阈值,则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态(HALF-OPEN 状态),若接下来的一个请求成功完成(没有错误)则结束熔断,否则会再次被熔断。异常比率的阈值范围是[0.0, 1.0]
,代表 0% - 100%。 - 异常数 (
ERROR_COUNT
):当单位统计时长内的异常数目超过阈值之后会自动进行熔断。经过熔断时长后熔断器会进入探测恢复状态(HALF-OPEN 状态),若接下来的一个请求成功完成(没有错误)则结束熔断,否则会再次被熔断。
注意异常降级仅针对业务异常,对 Sentinel 限流降级本身的异常(
BlockException
)不生效。为了统计异常比例或异常数,需要通过Tracer.trace(ex)
记录业务异常
@SentinelResource(value = "LenovoReqService_bidInquiry", fallback = "blockExHandler")
@Override
public LenovoResponse bidInquiry(LenovoRequestTo request) {
String url = "http://xxx";
return restTemplate.postForObject(url, request, LenovoResponse.class);
}
public LenovoResponse blockExHandler(LenovoRequestTo request) {
log.error("sentinel降级");
return null;
}
需要先调一次接口才能初始化,初始化之后配置熔断规则
测试熔断是否生效
这里设置了平均响应时间超过200ms就会熔断,比例阈值代表了超过RT的请求平均一半会降级处理
这里也很好理解,10000ms内有一个请求响应时间超过了200ms,就会熔断10s钟
请求的响应时间大于200ms该值则统计为慢调用。当单位统计时长10000ms内请求数目大于设置的最小请求数目1,并且慢调用的比例大于阈值0.5,则接下来的熔断时长内请求会自动被熔断。经过熔断时长10s后熔断器会进入探测恢复状态(HALF-OPEN 状态),若接下来的一个请求响应时间小于设置的慢调用 RT 200ms则结束熔断,若大于设置的慢调用 RT 则会再次被熔断。
未完待续....