文章目录
- 项目结构
- 一、断路器
- 二、sentinel 主要特性
- 三、sentinel 两个部分、三步骤
- 四、使用核心库(如果已经引入了 springcloudalibabajar 不需要单独选择版本,只需直接引用)
- 五、使用控制台
- 六、控制台各功能详情
- 七、sentinel 规则管理及三种模式
项目结构
一、断路器
1.1.为什么使用断路器?
在微服务架构中,我们将系统拆分成了很多服务单元,各单元的应用间通过服务注册
与订阅的方式互相依赖。由于每个单元都在不同的进程中运行,依赖通过远程调用的方式
执行,这样就有可能因为网络原因或是依赖服务自身间题出现调用故障或延迟,而这些问
题会直接导致调用方的对外服务也出现延迟,若此时调用方的请求不断增加,最后就会因
等待出现故障的依赖方响应形成任务积压,最终导致自身服务的瘫痪。为了解决这样的问题,
产生了断路器等一系列的服务保护机制。
1.2.断路器两大常用组件 Sentinel 和 Hystrix 对比
Sentinel | Hystrix | |
---|---|---|
隔离策略 | 信号量隔离(并发控制) | 线程池隔离/信号量隔离 |
熔断降级策略 | 基于慢调用比例、异常比例、异常数 | 基于异常比例 |
实时统计实现 | 滑动窗口(LeapArray) | 滑动窗口(基于 RxJava) |
动态规则配置 | 支持近十种动态数据源 | 支持多种数据源 |
扩展性 | 多个扩展点 | 插件的形式 |
基于注解的支持 | 支持 | 支持 |
单机限流 | 基于 QPS,支持基于调用关系的限流 | 有限的支持 |
集群流控 | 支持 | 不支持 |
流量整形 | 支持预热模式与匀速排队控制效果 | 不支持 |
系统自适应保护 | 支持 | 不支持 |
热点识别/防护 | 支持 | 不支持 |
多语言支持 | Java/Go/C++ | Java |
Service Mesh 支持 | 支持 Envoy/Istio | 支持 |
控制台 | 提供开箱即用的控制台,可配置规则、实时监控、机器发现等 | 简单的监控查看 |
维护 | 持续维护 | 停止维护 |
使用方式 | 单独一个组件,可以独立。直接界面化的细粒度统一配置 | 需要程序员手工搭建监控平台 |
二、sentinel 主要特性
三、sentinel 两个部分、三步骤
3.1.两部分
a) 核心库(Java 客户端)不依赖任何框架/库,能够运行于所有 Java 运行时环境,
同时对 Dubbo / Spring Cloud 等框架也有较好的支持。
b) 控制台(Dashboard)基于 Spring Boot 开发,打包后可以直接运行,不需要额外
的 Tomcat 等应用容器。
3.2.三步骤
a) 定义资源
b) 定义规则
c) 检验规则是否生效
四、使用核心库(如果已经引入了 springcloudalibabajar 不需要单独选择版本,只需直接引用)
项目中引入核心库
<dependency>
<groupId>com.alibaba.csp</groupId>
<artifactId>sentinel-core</artifactId>
<version>1.8.1</version>
</dependency>
a) 定义资源:定义资源提供三种方式:1、使用
@SentinelResource
注解提供使用 AspectJ
拓展用于自动定义资源 2、Sphu(抛出异常)3、Spho(返回布尔类值)
i. 使用注解并开启对应切面需要引入SentinelResourceAspect
1.引入依赖
<dependency>
<groupId>com.alibaba.csp</groupId>
<artifactId>sentinel-annotation-aspectj</artifactId>
<version>1.8.1</version>
</dependency>
如果使用原生 spring 需要通过配置将 sentinelAspectConfiguration
注册为一个 springbean。如
果使用 springcloudalibaba
则不需要
@Configuration
public class SentinelAspectConfiguration {
@Bean
public SentinelResourceAspect sentinelResourceAspect() {
return new SentinelResourceAspect();
}
}
查看 SentinelResourceAspect
方法
可以看到 SentinelResourceAspect 使用 aspect 的 around 拦截,拦截标注有 SentinelResource
的注解,进入方法之前调用 SphU.entry(resourceName, entryType),结束之后调用 entry.exit();
底层和另外两种方式是一样的
2.需要定义资源的地方使用@SentinelResource
注解并定义一个资源名
@SentinelResource
属性值
属性 | 说明 |
---|---|
value | 资源名称,必需项,因为需要通过 resource name 找到对应的规则,这个是必须配置的 |
fallback | fallback 函数名称,可选项,用于在抛出异常的时候提供 fallback 处理逻辑。fallback 函数可以针对所有类型的异常(除了 exceptionsToIgnore 里面排除掉的异常类型)进行处理 |
entryType | 流量类型类型,可选项,有 IN 和 OUT 两个选项,默认为 EntryType.OUT |
blockHandlerClass | blockHandler 函数默认需要和原方法在同一个类中,如果希望使用其他类的函数,则需要指定 blockHandlerClass 为对应的类的 Class 对象,注意对应的函数必需为 static 函数,否则无法解析 |
blockHandler | blockHandler 对应处理 BlockException 的函数名称,可选项。blockHandler 函数访问范围需要是 public,返回类型需要与原方法相匹配,参数类型需要和原方法相匹配并且最后加一个额外的参数,类型为 |
BlockException | |
fallbackClass | fallbackClass 的应用和 blockHandlerClass 类似,fallback 函数默认需要和原方法在同一个类中。若希望使用其他类的函数,则可以指定fallbackClass 为对应的类的 Class 对象,注意对应的函数必需为 static函数,否则无法解析 |
defaultFallback | 如果没有配置 defaultFallback 方法,默认都会走到这里来。默认的 fallback函数名称,可选项,通常用于通用的 fallback 逻辑。默认 fallback 函数可以针对所有类型的异常(除了 exceptionsToIgnore 里面排除掉的异常类型)进行处理。若同时配置了 fallback 和 defaultFallback,则只有fallback 会生效 |
exceptionsToIgnore | 用于指定哪些异常被排除掉,不会计入异常统计中,也不会进入 fallback逻辑中,而是会原样抛出 |
3.使用 Sphu(作用方式是抛出异常)
try (Entry entry = SphU.entry ("resourceName")) {
// 被保护的业务逻辑
// do something here...
} catch (BlockException ex) {
// 资源访问阻止,被限流或被降级
// 在此处进行相应的处理操作
}
4.使用 Spho(作用方式是返回布尔类型的值)
// 资源名可使用任意有业务语义的字符串
if (SphO.entry ("自定义资源名")) {
// 务必保证 finally 会被执行
try {
/**
* 被保护的业务逻辑
*/
} finally {
SphO.exit();
}
} else {
//资源访问阻止,被限流或被降级
//进行相应的处理操作
}
5.定义规则 (使规则生效可以使用@PostConstruct
注解)
1.流量控制参数说明
参数 | 说明 | 默认值 |
---|---|---|
resource | 资源名,资源名是限流规则的作用对象 | |
Count | 限流阈值 | |
grade | 限流阈值类型,是按照 QPS 还是线程数 | QPS 模式 |
limitApp | 是否根据调用者来限流 | 否 |
strategy | 判断的根据是资源自身,还是根据其它资源(refResource),还是根据链路入口 (refResource) | 根据资源本身 |
controlBehavior | 发生拦截后的流量整形和控制策略(直接拒绝 / 排队等待 / 慢启动模式) | 直接拒绝 |
private static void initFlowQpsRule() {
List<FlowRule> rules = new ArrayList<>();
FlowRule rule1 = new FlowRule();
rule1.setResource("资源名");
// set limit qps to 2
rule1.setCount(2);
rule1.setGrade(RuleConstant. FLOW_GRADE_QPS );
rule1.setLimitApp("default");
rules.add(rule1);
FlowRuleManager.loadRules(rules);
}
2.熔断降级规则参数说明
参数 | 说明 | 默认值 |
---|---|---|
resource | 资源名,资源名是限流规则的作用对象 | |
Count | 限流阈值 | |
grade | 降级模式,根据 RT 降级还是根据异常比例降级 | RT |
timeWindow | 降级时间 |
private static void initDegradeRule() {
List<DegradeRule> rules = new ArrayList<>();
DegradeRule rule = new DegradeRule();
rule.setResource("资源名");
// set threshold rt, 10 ms
rule.setCount(10);
rule.setGrade(RuleConstant. DEGRADE_GRADE_RT );
rule.setTimeWindow(10);
rules.add(rule);
DegradeRuleManager.loadRules(rules);
}
3.热点规则参数说明
参数 | 说明 | 默认值 |
---|---|---|
resource | 资源名,资源名是限流规则的作用对象 | |
limitApp | 授权使用限制来源方 | default |
grade | 0:线程数(客户端并发控制)1:QPS(默认) | QPS |
paramIdx | 必填项,热点参数索引位置 对应 SphU.entry(xxx,args)中的参数索引位置 | |
count | 必填项,限流阈值 | |
controlBehavior | 0:(直接拒绝)2:匀速通过 | 0 |
maxQueueingTimeMs | 当 controlBehavior=2 时,排队等待时间 | |
burstCount | 应对突发流量额外允许的数量 | |
durationInSec | 统计窗口时间长度 | 1 秒 |
paramFlowItemList | 额外选项,针对特定的参数单独限流 | |
clusterMode | 是否为集群模式 | false |
clusterConfig | 集群限流配置 |
private static void initParamFlowRule() {
ParamFlowRule rule = new ParamFlowRule( “资源名” );
rule.setParamIdx(0);
rule.setCount(5);
ParamFlowItem item = new ParamFlowItem();
// 针对 int 类型的参数 PARAM_B,单独设置限流 QPS 阈值为 10,而不是全局的阈值 5.
item.setObject(String. valueOf (10));
item.setClassType(int.class.getName());
item.setCount(10);
rule.setParamFlowItemList(Collections. singletonList (item));
ParamFlowRuleManager. loadRules (Collections.singletonList (rule));
}
4.系统保护规则参数说明
参数 | 说明 | 默认值 |
---|---|---|
highestSystemLoad | 最大的 load1 | -1 (不生效) |
avgRt | 所有入口流量的平均响应时间 | -1 (不生效) |
maxThread | 入口流量的最大并发数 | -1 (不生效) |
private void initSystemProtectionRule() {
List<SystemRule> rules = new ArrayList<>();
SystemRule rule = new SystemRule();
rule.setHighestSystemLoad(10);
rules.add(rule);
SystemRuleManager.loadRules(rules);
}
5.授权规则参数说明
参数 | 说明 | 默认值 |
---|---|---|
resource | 资源名,资源名是限流规则的作用对象 | |
limitApp | 对应的黑名单/白名单,不同 origin 用 , 分隔,如 appA,appB | default,代表不区分调用来源 |
strategy | 限制模式,AUTHORITY_WHITE 为白名单模式,AUTHORITY_BLACK 为黑名单模式,默认为白名单模式 | AUTHORITY_WHITE |
public void initAuthorityRule() {
AuthorityRule authorityRule = new AuthorityRule();
authorityRule.setResource("资源名");
authorityRule.setStrategy(RuleConstant.AUTHORITY_WHITE );
authorityRule.setLimitApp("白名单应用");
AuthorityRuleManager.loadRules (Collections.singletonList(authorityRule));
}
6.检验规则是否生效
i. 接口其他接口可以查看 https://blog.csdn.net/tsuiearl/article/details/116492167
http://IP:对外通信端口/getRules?type={} 支持 4 种类型:flow、degrade、authority、system
ii. 实际操作测试
五、使用控制台
a) 从 github 上 https://github.com/alibaba/Sentinel/releases 下载 jar 包
b) 可以通过 jvm 配置参数启动 jar。java -Dserver.port=8849
-Dcsp.sentinel.dashboard.server=localhost:8849 -Dproject.name=sentinel-dashboard
-jar sentinel-dashboard.jar
默认账号密码均为 sentinel
1.实时监控:实时查看各个资源的 QPS
2.簇点链路:查看 http 请求
3.流控规则:控制 QPS、线程等
4.降级规则:服务降级
5.热点规则:经常访问的数据,很多时候我们希望统计某个热点数据中访问频次
最高的 Top K 数据,并对其访问进行限制,热点参数限流可以看做是一种特殊的
流量控制,仅对包含热点参数的资源调用生效
6.系统规则:系统规则自然对应所有入口的 rest 请求做处理,整体管控
7.授权规则:设置白名单及黑名单,来源访问控制
8. 集群流控:以上配置均为单机应用,假如你的应用有多个实例,那么你设置了
限流的规则之后,每一台应用的实例都会生效相同的流控规则
9.机器列表:链接到 sentinel 控制台的机器
六、控制台各功能详情
6.1.流控规则
1.简介
根据 QPS、线程控制资源
2.新增流控规则
3.参数
一级参数 | 二级参数 | 说明 |
---|---|---|
资源名 | 唯一名称 | |
针对来源 | Sentinel 可以针对调用者进行限流,填写微服务名,指定对哪个微服务进行限流 ,默认 default(不区分来源,全部限制) | |
阈值类型 | QPS | (每秒钟的请求数量):当调用该接口的 QPS 达到了阈值的时候,进行限流 |
阈值类型 | 线程数 | 当调用该接口的线程数达到阈值时,进行限流 |
单机阈值 | 设置阈值 | |
流控模式 | 直接 | 接口达到限流条件时,直接限流 |
流控模式 | 关联 | 当关联的资源达到阈值时,就限流关联资源 |
流控模式 | 链路 | 只记录指定链路上的流量(指定资源从入口资源进来的流量,如果达到阈值,就可以限流)api 级别的针对来源 |
流控效果 | 快速失败 | 直接失败 |
流控效果 | Warm up | 即请求 QPS 从 threshold / 3 开始,设置预热时长,经预热时长后逐渐升设定的 QPS 阈值。预热方式就是为了保护系统,可慢慢的把流量放进来,慢慢的把阈值增长到设置的阈值 |
流控效果 | 排队等待 | 匀速排队,让请求以均匀的速度通过,阈值类型必须需设成 QPS,否则无效。这种方式主要用于处理间隔性突发流量,例如消息队列,在某一秒有大量的请求道来,而接下来的几秒则处于空闲状态,我们希望系统能够在接下来的空闲期间逐渐处理这些请求,而不是一秒直接拒绝多余的请求 |
4.场景例子
每秒支持两次访问
6.2.降级规则
1.简介
Sentinel 熔断降级会在调用链路中某个资源出现不稳定状态时,例如调用超时
或异常比例升高,对这个资源的调用进行限制,让请求快速失败,避免影响到其他的
资源而导致级联错误
当资源被降级后,在接下来的降级时间窗口之内,对该资源的调用都自动熔断(默认
抛出DegradeException
)
2.新增慢调用比例降级规则
3.参数
一级参数 | 说明 |
---|---|
资源名 | 唯一名称 |
熔断策略 | 慢调用比例。每秒平均响应时间,超过阈值,且时间窗口内通过的请求>=5,两个条件同时满足触发降级,RT 最大 4900 |
最大 RT | 超过配置 ms 则判定为慢请求 |
比例阈值 | 触发熔断的慢调用比例阈值为 80% |
熔断时长 | 设置熔断的时长 |
最小请求数 | 触发熔断的最小请求数目 |
统计时长 | 统计窗口时长 |
4.场景例子
如图所示设置规则开启后,在统计时长 1 秒内,当请求数目大于 10,并且慢调用
的比例大于 80%的时候,则在接下来 5 秒的熔断时长内,请求都会快速失败。经过
5 秒后熔断器会进入探测恢复状态,若接下来的一个请求响应时间小于设置的 1000
ms 则结束熔断,若大于 1000 ms 则会再次被熔断。
5.新增异常比例降级规则
参数
一级参数 | 说明 |
---|---|
资源名 | 唯一名称 |
熔断策略 | 异常比例 |
比例阈值 | 触发熔断的慢调用比例阈值百分比 |
熔断时长 | 设置熔断的时长 |
最小请求数 | 触发熔断的最小请求数目 |
统计时长 | 统计窗口时长 |
场景例子:
规则开启后,在统计时长 1 秒内,当请求数目大于 10,并且异常的比例大于等于
80%的时候,则在接下来 5 秒的熔断时长内,请求都会快速失败。经过 5 秒后熔断
器会进入探测恢复状态,若接下来的一个请求没有异常则结束熔断,否则会再次熔
断
6.新增异常数降级规则
参数:
参数 | 说明 |
---|---|
资源名 | 唯一名称 |
熔断策略 | 异常数 |
异常数 | 异常数触及熔断 |
熔断时长 | 设置熔断的时长 |
最小请求数 | 触发熔断的最小请求数目 |
统计时长 | 统计窗口时长 |
场景例子:
规则开启后,在统计时长 1 秒内,当请求数目大于 10,并且异常的数量大于等于 5
的时候,则在接下来 5 秒的熔断时长内,请求都会快速失败。经过 5 秒后熔断器会
进入探测恢复状态,若接下来的一个请求没有异常则结束熔断,否则会再次熔断
6.3.热点规则
1.简介
热点就是经常访问的数据,根据请求的参数来做限流,比如请求带的参数是热点参数,就对这个请求应用特殊的限流规则;对携带非热点参数的请求,走另一个限流规则
2.新增热点规则
参数 | 说明 |
---|---|
资源名 | 唯一名称 |
限流模式 | 默认 QPS 模式 |
参数索引 | 指定热点参数的下标,从 0 开始。如果额外参数不匹配则默认为 0 |
单机阈值 | 对资源内的接口阈值设置 |
统计窗口时长 | 统计时间长度 |
参数类型 | 参数例外项,可以针对指定的参数值单独设置限流阈值,不受前面 count 阈值的限制。仅支持基本类型和字符串类型 |
参数值 | 传递参数值 |
限流阈值 | 传递参数值对应的阈值 |
场景例子:
规则开启后,在统计时长 1 秒内,如果传递参数为 2 则以 20 作为阈值,若不传递
参数则以 2 作为阈值
6.4.系统规则
1.简介
系统保护规则是从应用级别的入口流量进行控制,从单台机器的 load、CPU 使用率、平均 RT、入口 QPS 和并发线程数等几个维度监控应用指标,让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。可以理解为系统规则是全局的限流配置,可以针对服务的全局 QPS、机器的 CPU 等参数进行限流
2.新增系统规则
参数 | 说明 |
---|---|
Load 自适应(仅对Linux/Unix-like机器生效) | 系统的 load1 作为启发指标,进行自适应系保护。当系统 load1 超过设定的启发值,且系统当前的并发线程数超过估算的系统容量时才会触发系统保护(BBR 阶段)。系统容量由系统的 maxQps * minRt 估算得出。设定参考值一般是 CPU cores* 2.5 |
RT | 当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护,单位是毫秒 |
线程数 | 当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护 |
入口 QPS | 当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护 |
CPU 使用率 | 当系统 CPU 使用率超过阈值即触发系统保护(取值范围 0.0-1.0),比较灵敏 |
场景例子:
当 CPU 的使用率大于 70%,就停止新的请求
6.5.授权规则
1.简介
当我们需要根据调用来源来判断该次请求是否允许放行,这时候可以使用Sentinel 的来源控制功能。表示控制功能基于请求标识信息,只要 Sentinel 保护的接口资源被访问,Sentinel 就会调用 RequestOriginParser 的实现类去解析调用者标识。若配置白名单,则只有请求来源位于白名单内时才可通过,若配置黑名单,则请求来源位于黑名单时不允许通过,其余的请求来源可以通过
2.访问控制的功能,加上相应的授权规则。新增
参数 | 说明 |
---|---|
资源名 | 调用方,也就是调用来源了,比如 app 端调用或 pc 端调用 |
流控应用 | 白名单:只有请求来源位于白名单内时才可通过 |
授权类型 | 黑名单:请求来源位于黑名单时不通过,其余的请求通过 |
场景例子:
资源名为 getTest 的资源仅有服务叫 demo 的可以调用
代码配置:
@Component
public class RequestOriginParserDefinition implements RequestOriginParser {
//基于 Spring 的 Interceptor 拦截资源
// 获取调用方标识信息并返回
@Override
public String parseOrigin(HttpServletRequest request) {
String serviceName = request.getParameter("serviceName");
if (StringUtils.isEmpty(serviceName)) {
throw new IllegalArgumentException("serviceName must not be null");
}
return serviceName;
}
}
七、sentinel 规则管理及三种模式
推送模式 | 说明 | 优点 | 缺点 |
---|---|---|---|
简单模式 | API 将规则推送至客户端并直接更新到内存中,扩展写数据源(WritableDataSource) | 简单,无任何依赖 | 不保证一致性;规则保存在内存中,重启即消失。严重不建议用于生产环境 |
pull 模式 | 扩展写数据源(WritableDataSource), 客户端主动向某个规则管理中心定期轮询拉取规则,这个规则中心可以是 RDBMS、文件等 | 简单,无任何依赖 | 规则持久化 不保证一致性;实时性不保证,拉取过于频繁也可能会有性能问题。 |
push 模式 | 扩展读数据源(ReadableDataSource),规则中心统一推送,客户端通过注册监听器的方式时刻监听变化,比如使用 Nacos、Zookeeper 等配置中心。这种方式有更好的实时性和一致性保证。生产环境下一般采用push 模式的数据源。 | 规则持久化;一致性;快速 | 引入第三方依赖 |
7.1.结合 nacos 使用 push 模式实现 sentinel 流控规则持久化
1.推送规则:
i. 控制台增加的规则推送到 nacos
ii. sentinel 链接 nacos 客户端,获取规则配置。并监听 Nacos 配置变化,如发生
变化,更新本地缓存(从而让本地缓存和 Nacos 一致)
2.下载 sentinel 源码,对源码进行改造
i. (需要源码联系博主即可)
1). sentinel-core:Sentinel 核心模块,实现限流、熔断等基本能力。
2). sentinel-dashboard:Sentinel 可视化控制台,提供基本的管理界面,配置
限流、熔断规则等,展示监控数据等。
3). sentinel-adapter:Sentinel 适配,Sentinel-core 模块提供的是限流等基本
API,主要是提供给应用自己去显示调用,对代码有侵入性,故该模块对
主流框架进行了适配,目前已适配的模块:
a) sentinel-apache-dubbo-adapter:对 Apache Dubbo 版本进行适配,这样
应用只需引入 sentinel-apache-dubbo-adapter 包即可对 dubbo 服务进行流控
与熔断,大家可以思考会利用 Dubbo 的哪个功能特性。
b)sentinel-dubbo-adapter:对 Alibaba Dubbo 版本进行适配。
c)sentinel-grpc-adapter:对 GRPC 进行适配。
d)sentinel-spring-webflux-adapter:对响应式编程框架 webflux 进行适配。
e)sentinel-web-servlet:对 servlet 进行适配,例如 Spring MVC。
f)sentinel-zuul-adapter:对 zuul 网关进行适配。
4). sentinel-cluster:提供集群模式的限流与熔断支持,因为通常一个应用会
部署在多台机器上组成应用集群。
5). sentinel-transport:网络通讯模块,提供 Sentinel 节点与
sentinel-dashboard 的通讯支持,主要有如下两种实现。
a)sentinel-transport-netty-http:基于 Netty 实现的 http 通讯模式。
b)sentinel-transport-simple-http:简单的 http 实现方式。
6). sentinel-extension:Sentinel 扩展模式。主要提供了如下扩展(高级)功能:
a)sentinel-annotation-aspectj:提供基于注解的方式来定义资源等。
b)sentinel-parameter-flow-control:提供基于参数的限流(热点限流)。
c)sentinel-datasource-extension:限流规则、熔断规则的存储实现,默认是
存储在内存中。
d)sentinel-datasource-apollo:基于 apollo 配置中心实现限流规则、熔断
规则的存储,动态推送生效机制。
e)sentinel-datasource-consul:基于 consul 实现限流规则、熔断规则的存
储,动态推送生效机制。
f)sentinel-datasource-etcd:基于 etcd 实现限流规则、熔断规则的存储,
动态推送生效机制。
g)sentinel-datasource-nacos:基于 nacos 实现限流规则、熔断规则的存储,
动态推送生效机制。
h)entinel-datasource-redis:基于 redis 实现限流规则、熔断规则的存储,
动态推送生效机制。
i)sentinel-datasource-spring-cloud-config:基于 spring-cloud-config 实现限
流规则、熔断规则的存储,动态推送生效机制。
j)sentinel-datasource-zookeeper:基于 zookeeper 实现限流规则、熔断规
则的存储,动态推送生效机制。
3.改造 sentinel 中 sentinel-dashboard 模块 打开 pom 去掉中 nacos 的 test 注解
拓展 maven scope 标签
a) compile:默认的 scope,运行期有效,需要打入包中
b) provided:编译期有效,运行期不需要提供,不会打入包中
c) runtime:编译不需要,在运行期有效,需要导入包中。(接口与实
现分离)
d) test:测试需要,不会打入包中
e) system:非本地仓库引入、存在系统的某个路径下的 jar
4.把 src/test/java/com/alibaba/csp/sentinel/dashboard/rule/nacos
文件夹拷贝到src/main/java/com/alibaba/csp/sentinel/dashboard/rule
目录下:
5.修改改模块下的 application.properties,根据实际需要修改 address、namespace。需要注意 GROUPID 默认值是 SENTINEL_GROUP,在 nacos 新建规则时候需要注意
6.修改 nacosconfig 文件,使得 nacos 链接可以通过配置文件实现
7.修改流控制器 FlowControllerV2 注入
注入的两个 bean:flowRuleNacosProvider
:就是实现 Nacos 的限流规则配置拉取。flowRuleNacosPublisher
:实现 Nacos 的配置推送
进入 flowruleNacosPublisher 默认的 GROUP_ID 为
8.打开 src/main/webapp/resources/app/scripts/directives/sidebar/sidebar.html
,找
到 dashboard.flowV1({app: entry.app})修改为 dashboard.flow({app: entry.app})
。
9. 打开 src/main/webapp/resources/app/scripts/controllers/identity.js
,把
FlowServiceV1 改为 FlowServiceV2。
上述已经完成所有的配置操作
7.2.测试下
1.启动 DashboardApplication 模块进行测试默认端口为 8080,首先打开 nacos 中
sentinel 的 spacename 可以看到目前配置为空
2.项目 pom.xml 中新增相关依赖
<!-- sentinel 流量控制 -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
<dependency>
<groupId>com.alibaba.csp</groupId>
<artifactId>sentinel-datasource-nacos</artifactId>
</dependency>
配置文件中增加
访问测试接口。为 getTest 新增一条流控规则
3.打开 nacos 可以看到命名空间内新增了一条配置,查看详情与 sentinel 的配置
相同
7.3.结合 nacos 使用 push 模式改造其他规则持久化
1.新增降级规则、热点规则、授权规则、系统规则的配置后缀以作区分
2.添加规则推送类
3.nacosConfig 中添加规则转化类
@Bean
public Converter<List<DegradeRuleEntity>, String> degradeRuleEntityEncoder() {
return JSON::toJSONString ;
}
@Bean
public Converter<String, List<DegradeRuleEntity>> degradeRuleEntityDecoder() {
return s -> JSON.parseArray(s, DegradeRuleEntity.class);
}
@Bean
public Converter<List<SystemRuleEntity>, String> systemRuleEntityEncoder() {
return JSON:: toJSONString ;
}
@Bean
public Converter<String, List<SystemRuleEntity>> systemRuleEntityDecoder() {
return s -> JSON. parseArray (s, SystemRuleEntity.class);
}
@Bean
public Converter<List<AuthorityRuleEntity>, String> authorityRuleEntityEncoder() {
return JSON:: toJSONString ;
}
@Bean
public Converter<String, List<AuthorityRuleEntity>> authorityRuleEntityDecoder() {
return s -> JSON.parseArray(s, AuthorityRuleEntity.class);
}
@Bean
public Converter<List<ParamFlowRuleEntity>, String> paramFlowRuleEntityEncoder() {
return JSON::toJSONString ;
}
@Bean
public Converter<String, List<ParamFlowRuleEntity>> paramFlowRuleEntityDecoder() {
return s -> JSON.parseArray(s, ParamFlowRuleEntity.class);
}
4.参照 FlowControllerV2 修改对应的降级规则、热点规则、授权规则、系统规则的控制器增加对 nacos 的推送支持
5.应用配置文件中增加相关配置
7.4.全部修改完成后需要在 pom.xml 中增加
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.22.1</version>
<configuration>
<skipTests>true</skipTests>
</configuration>
</plugin>
跳过对 test 的打包运行 mvn clean package 打成一个 fat jar 启动 jar 包 sentinel 提供了 jvm 启动参数
补充:
配置内容说明:resource
:接口名,即限流规则的作用对象limitApp
:流控针对的调用来源,若为 default 则不区分调用来源grade
:限流阈值类型(QPS 或并发线程数);0 代表根据并发数量来限流,1 代表根据 QPS
来进行流量控制count
:限流阈值strategy
:调用关系限流策略controlBehavior
:流量控制效果(直接拒绝、Warm Up、匀速排队)clusterMode
:是否为集群模式