自建服务器网站备案,wordpress自媒体博客,广安市建设局网站,贵州网站中企动力建设目录
一、前言
二、环境准备
2.1 部署sentinel管控台
2.1.1 官网下载sentinel的jar包
2.1.2 启动控制台 2.1.3 访问控制台
2.2 整合springcloud-alibaba
2.2.1 引入相关依赖
2.2.2 修改配置文件
2.2.3 增加一个测试接口
2.2.4 接口测试
三、sentinel 流控规则使用
…目录
一、前言
二、环境准备
2.1 部署sentinel管控台
2.1.1 官网下载sentinel的jar包
2.1.2 启动控制台 2.1.3 访问控制台
2.2 整合springcloud-alibaba
2.2.1 引入相关依赖
2.2.2 修改配置文件
2.2.3 增加一个测试接口
2.2.4 接口测试
三、sentinel 流控规则使用
3.1 实时监控
3.2 簇点链路
3.3 流控规则概述
3.3.1 流量控制原理
3.3.2 流量控制常用场景
3.3.3 流控规则的详细参数
3.4 常用流控规则
3.4.1 QPS限流 3.4.2 自定义限流返回结果
3.4.3 并发线程数限流
3.4.4 自定义异常
3.5 流控模式
3.5.1 流控模式概述
3.5.2 流控模式 —— 直接
3.5.3 流控模式 —— 关联
3.5.4 流控模式 —— 链路
3.6 流控效果
3.6.1 快速失败
3.6.2 Warm Up
3.6.3 排队等待
四、sentinel 降级规则
4.1 降级规则概述
4.1.1 为什么需要降级
4.1.2 降级与隔离
4.1.3 熔断后的处理逻辑
4.2 熔断策略
4.2.1 慢调用比例
4.2.2 异常比例
五、整合openfeign
5.1 服务提供方
5.2 服务消费方
5.2.1 添加pom依赖
5.2.2 添加配置文件
5.2.3 添加feign接口
5.2.4 提供降级的类
5.2.5 添加测试接口
5.2.6 接口测试与验证
六、热点参数限流
6.1 何为热点参数
6.1.1 使用场景
6.2 热点参数使用
6.2.1 新增一个测试接口
6.2.2 dashboard 如下配置
6.2.3 测试验证
6.3 系统规则使用
6.3.1 系统规则来源
6.3.2 sentinel系统规则概述
6.3.3 sentinel控制台配置
七、Sentinel配置规则持久化
7.1 三种规则持久化模式
7.1.1 原始模式
7.1.2 pull模式
7.1.3 push模式
7.2 整合nacos规则持久化
7.2.1 引入依赖
7.2.2 配置文件
7.2.3 naocos新增一个配置文件
7.2.4 请求接口
7.2.5 重启服务
八、写在文末 一、前言
从前面的学习了解到sentinel是springcloud alibaba微服务生态下的一个重要的流量治理组件在微服务架构中占据着非常重要的地位本篇将详细介绍下springcloud alibaba中如何整合sentinel以及结合sentinel控制台聊聊其深入的使用。 二、环境准备 2.1 部署sentinel管控台 git下载地址下载地址 2.1.1 官网下载sentinel的jar包
注意版本的匹配 2.1.2 启动控制台
由于是一个springboot的服务jar包直接使用java -jar命令即可启动 2.1.3 访问控制台
启动成功后默认端口是8080浏览器直接localhost:8080默认登录账户名和密码为sentinel /sentinel登录之后看到下面界面首次进入为空页面 2.2 整合springcloud-alibaba sentinel与springcloud-alibaba整合比较简单按照下面的几步操作即可。 2.2.1 引入相关依赖
导入以下基础依赖即可 dependenciesdependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-web/artifactId/dependencydependencygroupIdorg.projectlombok/groupIdartifactIdlombok/artifactIdoptionaltrue/optional/dependencydependencygroupIdcom.alibaba.cloud/groupIdartifactIdspring-cloud-alibaba-sentinel/artifactId/dependency/dependencies 2.2.2 修改配置文件
这里暂时没有对接其他的外部依赖只需配置与sentinel的控制台的连接信息
server:port: 8032spring:application:name: sentinel-order#注册中心使用nacoscloud:sentinel:transport:dashboard: localhost:8080 2.2.3 增加一个测试接口
这里添加一个测试接口用于接下来的各种流控规则的测试
RestController
RequestMapping(/order)
public class OrderController {GetMapping(/add)public String add(){System.out.println(准备下单);return hello ;}} 2.2.4 接口测试
启动工程后浏览器反复调用几次接口localhost:8032/order/add此后在sentinel的控制台就能看到如下相关的监控信息了 三、sentinel 流控规则使用 通过上面的准备在sentinel控制台左侧呈现出了详细的规则配置菜单接下来结合代码分别聊聊各种配置的详细使用。 3.1 实时监控
监控接口的通过的QPS和拒绝的QPS比如我们反复刷以下add接口就能在监控中左侧看到该接口一段时间内的调用频率趋势图右侧的表格则更直观的记录了在具体的时间点内QPS的通过和拒绝情况 3.2 簇点链路 显示微服务的所有被监控的API资源信息比如上面的add接口在图中就呈现了出来同时这个页面也是后续设置API接口流控规则的主要入口。 3.3 流控规则概述 还记得在上一篇中我们通过使用sentinel的SDK演示了各种流控规则的使用有了sentinel的控制台之后就变得更简单了接下来就来详细说明下如何使用控制台的各种流控规则的配置。 3.3.1 流量控制原理 其原理是监控应用流量的 QPS 或并发线程数等指标当达到指定的阈值时对流量进行控制以避免被瞬时的流量高峰冲垮从而保障应用的高可用性。 3.3.2 流量控制常用场景
应对洪峰流量比如秒杀大促下单回流等付费系统根据使用流量付费API Gateway精准控制API流量其他应用探测应用中运行慢的模块进行控制3.3.3 流控规则的详细参数
同一个资源可以设置多条限流规则FlowSlot 会对该资源的所有限流规则依次遍历直到有规则触发限流或者所有规则遍历完毕一条限流规则主要由下面几个因素组成我们可以组合这些元素来实现不同的限流效果 Field 说明 默认值 resource 资源名资源名是限流规则的作用对象 count 限流阈值 grade 限流阈值类型QPS 模式1或并发线程数模式(0) QPS 模式 limitApp 流控针对的调用来源 default代表不区分调用来源 strategy 调用关系限流策略直接、链路、关联 根据资源本身直接 controlBehavior 流控效果直接拒绝/WarmUp/匀速排队等 待不支持按调用关系限流 直接拒绝 clusterMode 是否集群限流 否
流控规则详细说明git地址 3.4 常用流控规则 3.4.1 QPS限流
QPSQuery Per Second 每秒请求数就是说服务器在一秒的时间内处理了多少个请求。 给order接口设置一个流控规则现在每秒的请求数量上限为2 设置完成后界面再次快速访问时如果超过了QPS设置的阈值将会看到下面的效果说明配置规则生效了 3.4.2 自定义限流返回结果
上面的规则生效后快速刷接口时返回的提示信息是sentinel默认的一串值如果要自定义返回信息只需要通过SentinelResource注解进行自定义返回值即可如下 GetMapping(/add)SentinelResource(value add,blockHandler addBlockHandler)public String add(){System.out.println(准备下单);return hello ;}public String addBlockHandler(BlockException b){return add 接口被流控了;}
然后重新启动工程再次快速刷接口时将会看到下面的效果 3.4.3 并发线程数限流
并发线程数控制用于保护业务线程池不被慢调用耗尽。 例如当应用所依赖的下游应用由于某种原因导致服务不稳定、响应延迟增加对于调用者来说意味着吞吐量下降和更多的线程数占用极端情况下甚至导致线程池耗尽。为应对太多线程占用的情况业内有使用隔离的方案比如通过不同业务逻辑使用不同线程池来隔离业务自身之间的资源争抢线程池隔离。这种隔离方案虽然隔离性比较好但是代价就是线程数目太多线程上下文切换的 overhead 比较大特别是对低延时的调用有比较大的影响。 Sentinel 并发控制不负责创建和管理线程池而是简单统计当前请求上下文的线程数目正在执行的调用数目如果超出阈值新的请求会被立即拒绝效果类似于信号量隔离。并发数控制通常在调用端进行配置。 新增一个接口 为了模拟出效果给接口添加一个休眠时间表示当前接口执行速度较慢这样的话当设置并发线程数时如果第一个请求没有处理完下一个请求过来时只能排队等待 GetMapping(/flow/thread)SentinelResource(value flowThread,blockHandler flowThreadBlockHandler)public String flowThread(){try {Thread.sleep(10000);} catch (InterruptedException e) {e.printStackTrace();}System.out.println(准备flowThread);return flowThread ;}public String flowThreadBlockHandler(BlockException b){return flowThread 接口被流控了;}
界面上为该接口配置如下流控规则这里设置为1 保存之后第一次请求该接口此时再开一个窗口再次请求该接口将会看到如下的效果 3.4.4 自定义异常
为了统一处理流控接口的异常可以通过自定义全局异常类然后在需要使用的地方引用即可
public class MyBlockException {public static Map handleException(BlockException e){MapString,Object resultMap new HashMap();if(e instanceof FlowException){resultMap.put(code,100);resultMap.put(msg,被限流了: e.getMessage());} else if (e instanceof DegradeException) {resultMap.put(code,101);resultMap.put(msg,服务被降级了: e.getMessage());} else if (e instanceof ParamFlowException) {resultMap.put(code,102);resultMap.put(msg,热点参数限流: e.getMessage());} else if (e instanceof SystemBlockException) {resultMap.put(code,103);resultMap.put(msg,触发系统保护规则: e.getMessage());} else if (e instanceof AuthorityException){resultMap.put(code,104);resultMap.put(msg,授权规则不通过: e.getMessage());}return resultMap;}}再在需要限流的接口上通过 SentinelResource 引用即可 GetMapping(/add)//SentinelResource(value add,blockHandler addBlockHandler)SentinelResource(value add,blockHandlerClass MyBlockException.class,blockHandler handleException)public MapString, Object add() {System.out.println(准备下单);MapString, Object resultMap new HashMap();resultMap.put(code, 200);resultMap.put(msg, 下单成功);return resultMap;}
通过sentinel控制台配置一下限流规则后再次测试以下add接口 3.5 流控模式
在流控规则下面点开高级选项可以看到流控模式这一选项相当于是限流规则的补充 3.5.1 流控模式概述 1基于调用关系的流量控制调用关系包括调用方、被调用方 2一个方法可能会调用其它方法形成一个调用链路的层次 关系 从控制台可以看到提供了3钟方式分别为直接关联和链路。 3.5.2 流控模式 —— 直接 资源调用达到设置的阈值后直接被流控抛出异常 比如上文中设置的QPS限流默认情况下即为直接的效果 3.5.3 流控模式 —— 关联 当两个资源之间具有资源争抢或者依赖关系的时候这两个资源便具有了关联设置了关联之后当一个资源被限流后这个关联的资源也将会受到影响 比如有下面两个接口一个生成订单的接口一个查询订单的接口假设生成订单接口会影响到查询订单即它们两个之间存在关联 GetMapping(/create)public String createOrder(){System.out.println(生成订单);return 生成订单;}GetMapping(/get)public String getOrder(){System.out.println(查询订单);return 查询订单;}
在sentinel控制台做如下设置 3.5.4 流控模式 —— 链路 根据调用链路入口限流 比如当微服务集群中某个微服务调用了一系列其他的微服务时相互之间可能就构成了一棵调用树其根节点就是起始调用的那个接口比如这棵树的根节点是一个名字为 getUser 的虚拟节点调用链的入口都是这个虚节点的子节点 getUser / \ / \ /order/test1 /order/test2 上图中来自入口 /order/test1 和 /order/test2的请求都调用到了资源 getUserSentinel 允许只根据某个入口的统计信息对 资源限流。 新增两个接口 Autowiredprivate UserService userService;GetMapping(/user1)public String user1(){return userService.getUser();}GetMapping(/user2)public String user2(){return userService.getUser();} 业务实现
Service
public class UserService {SentinelResource(value getUser)public String getUser() {return 查询用户;}
} sentinel控制台设置链路仅对来源为user2的接口进行限流 3.6 流控效果 流控效果即资源被流控之后展示出来的效果主要包括3种
快速失败Warm up排队等待3.6.1 快速失败
默认的流控方式上面展示的大多数流控后的效果就是快速识别抛出流控异常这里不再演示。 当QPS超过任意规则的阈值后新的请求就会被立即拒绝拒绝方式为抛出FlowException。这种方式适用于对系统处理能力确切已知的情况下比如通过压测确定了系统的准确水位时。 3.6.2 Warm Up
即预热/冷启动方式。 当系统长期处于低水位的情况下当流量突然增加时直接把系统拉升到高水位可能瞬间把系统压垮。通过Warm Up的方式让通过的流量缓慢增加在一定时间内逐渐增加到阈值上限给冷系统一个预热的时间避免冷系统被压垮。 sentinel控制台如下设置 测试发现当接口刷的频率达到一定值时将会看到被限流的效果但不是立马被限流而是能明显看到经历了一个过程 也可以通过实时监控效果进一步确认当前接口的访问频率 3.6.3 排队等待
这种方式会严格控制请求通过的间隔时间也即是让请求以均匀的速度通过底层实现对应的是漏桶算法。 这种方式主要用于处理间隔性突发的流量例如消息队列。想象一下这样的场景在某一秒有大量的请求到来而接下来的几秒则处于空闲状态我们希望系统能够在接下来的空闲期间逐渐处理这些请求而不是在第一秒直接拒绝多余的请求。 在sentinel的控制台做如下配置 通过压测工具访问接口一段时间内当请求的QPS超过5个时界面上会出现短暂的等待效果 通过实时监控效果也可以看出请求时间段内的QPS情况 四、sentinel 降级规则 4.1 降级规则概述 4.1.1 为什么需要降级
除了流控以外对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。 我们需要对不稳定的弱依赖服务调用进行熔断降级暂时切断不稳定调用避免局部不稳定因素导致整体的雪崩。熔断降级作为保护自身的手段通常在客户端调用端进行配置。 4.1.2 降级与隔离
服务的熔断、降级与隔离是保护服务自身的一种有效手段通常在consumer端组合使用主要实施手段有 1并发控制信号量隔离 2基于慢调用比例熔断 3基于异常比例熔断 4.1.3 熔断后的处理逻辑
当消费端调用的服务进行熔断后通常可采用下面的处理逻辑 1提供fallback结果服务降级 2返回错误result 3读取缓存降低DB访问量 熔断降级规则DegradeRule包含下面几个重要的属性Field 说明 默认值 resource 资源名即规则的作用对象 grade 熔断策略支持慢调用比例/异常比例/异常数策略 慢调用比例 count 慢调用比例模式下为慢调用临界 RT超出该值计为慢调用异常比例/异常数模式下为对应的阈值 timeWindow 熔断时长单位为 s minRequestAmount 熔断触发的最小请求数请求数小于该值时即使异常比率超出阈值也不会熔断1.7.0 引入 5 statIntervalMs 统计时长单位为 ms如 60*1000 代表分钟级1.8.0 引入 1000 ms slowRatioThreshold 慢调用比例阈值仅慢调用比例模式有效1.8.0 引入 4.2 熔断策略 4.2.1 慢调用比例
选择以慢调用比例作为阈值需要设置允许的慢调用 RT即最大的响应时间请求的响应时间大于该值则统计为慢调用。 当单位统计时长statIntervalMs内请求数目大于设置的最小请求数目并且慢调用的比例大于阈值则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态HALFOPEN 状态若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断若大于设置的慢调用 RT 则会再次被熔断 新增一个接口在该接口中处理需要3秒 GetMapping(/flow/thread)public String flowThread() {try {Thread.sleep(3000);} catch (InterruptedException e) {e.printStackTrace();}System.out.println(准备flowThread);return flowThread ;} 在sentinel控制台做如下配置简单说下几个关键参数含义
最大RT本次规则容忍的请求接口最大处理时长为毫秒比如这里设置的不能超过1秒最小请求数即统计的时间区间内最小的请求数量的下限不得低于这个数熔断时长触发熔断之后的持续时长比例阈值10次请求中当发生多少比例请求的慢调用时触发熔断规则保存完毕后可以直接在浏览器进行模拟调用当调用的次数和频率符合了规则时将看到下面的效果 同时可以从实时监控效果可以看到QPS的数据 4.2.2 异常比例
当单位统计时长statIntervalMs内请求数目大于设置的最小请求数目并且异常的比例大于阈值则接下来的熔断时长内请求会自动被熔断。 经过熔断时长后熔断器会进入探测恢复状态HALFOPEN 状态若接下来的一个请求成功完成没有错误则结束熔断否则会再次被熔断。异常比率的阈值范围是 [0.0, 1.0]代表 0% 100%。 新增一个带有异常的接口 GetMapping(/err)public String err() {int a 1/0;return err ;}
sentinel做如下配置 浏览器访问接口当满足规则中的条件时将会触发熔断出现下面的效果 五、整合openfeign
在使用openfeign进行服务调用时对于客户端来说被调用的服务接口出现异常时为了消费端的服务接口不被拖垮通常来说也需要做服务的熔断降级处理以提升自身的稳定性此时就可以考虑接入sentinel接下来看看如何在openfeign中使用sentinel。 5.1 服务提供方 准备两个工程第一个工程作为服务提供方使用之前的一个扣减库存的工程其中有一个异常接口 GetMapping(/reduct2)public String reduct2() {int a1/0;return 扣减库存 : reduct2;}5.2 服务消费方 工程结构如下 5.2.1 添加pom依赖 dependenciesdependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-web/artifactId/dependency!--nacos-discovery 注册中心-服务发现与注册--dependencygroupIdcom.alibaba.cloud/groupIdartifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId/dependencydependencygroupIdorg.springframework.cloud/groupIdartifactIdspring-cloud-starter-openfeign/artifactId/dependencydependencygroupIdcom.alibaba.cloud/groupIdartifactIdspring-cloud-alibaba-sentinel/artifactId/dependency/dependencies 5.2.2 添加配置文件
server:port: 8040spring:application:name: order-servicecloud:nacos:discovery:server-addr: localhost:8848 #服务注册中心地址#config:#server-addr: localhost:8848 #配置中心地址sentinel:transport:dashboard: localhost:8080feign:sentinel:enabled: true 5.2.3 添加feign接口
FeignClient(name stock-service,path /stock,fallback FallBackService.class)
public interface StockFeignService {GetMapping(/reduct)public String reduct();GetMapping(/reduct2)public String reduct2();GetMapping(/get)public String get(RequestParam(id) Integer id);
} 5.2.4 提供降级的类
Component
public class FallBackService implements StockFeignService{Overridepublic String reduct() {return null;}Overridepublic String reduct2() {return 服务被降级了;}Overridepublic String get(Integer id) {return null;}
} 5.2.5 添加测试接口
RestController
RequestMapping(/order)
public class OrderController {Autowiredprivate StockFeignService stockFeignService;//localhost:8083/order/addGetMapping(/add)public String add(){System.out.println(下单成功);String reduct stockFeignService.reduct2();return add order : reduct;}} 5.2.6 接口测试与验证
启动nacos服务启动两个工程浏览器调用localhost:8040/order/add看到下面的效果 六、热点参数限流 6.1 何为热点参数 热点参数也可以理解为热点接口即在一个系统中那些被高频调用的接口以及某参数对应的接口比如根据商品ID获取商品详情这样的接口在一个电商系统中一定是高频被调用的接口。 很多时候我们希望统计某个热点数据中访问频次最高的数据并对其访问进行限制以免被该来源的IP或应用占用太多的服务资源拖慢了整个系统的效率。 6.1.1 使用场景
比如热点商品的访问访问控制识别热点参数接口之后对来源用户/app/IP进行限制避免防刷 热点参数限流会统计传入参数中的热点参数并根据配置的限流阈值与模式对包含热点参数的资源调用进行限流。热点参数限流可以看做是一种特殊的流量控制仅对包含热点参数的资源调用生效。 6.2 热点参数使用 6.2.1 新增一个测试接口
注意点 1热点规则需要使用SentinelResource(resourceName)注解否则不生效 2参数必须是7种基本数据类型才会生效 GetMapping(/get/{id})SentinelResource(value getById,blockHandler hotBlockHandler)public String getById(PathVariable(id) Integer id){System.out.println(正常访问);return 正常访问 ;}public String hotBlockHandler(PathVariable(id) Integer id,BlockException e){return 热点异常处理结果 ;} 6.2.2 dashboard 如下配置 新增完成后在热点规则列表就有了一个数据继续编辑 6.2.3 测试验证
请求时设置参数为1 每秒1次可以正常响应结果 每秒超过1次时触发热点规则降级 6.3 系统规则使用 6.3.1 系统规则来源
在真实的生产环境下对一个复杂的系统来说引起系统故障或者突然崩溃的因素有很多比如
对系统容量评估不到位导致个别大流量的接口没有配置限流规则或者配置不合理由于来不及处理而崩溃机器突发CPU飙高但是短期内很难定位到原因导致系统挂掉集群中其中一台机器挂掉导致流量被转移到其他机器上另外的机器被打满而引起服务雪崩或宕机希望有个全局的兜底防护即使一开始缺少容量评估也有一定的保护机制。简单来说就是结合系统的指标和服务容量能够自适应动态调整流量。 6.3.2 sentinel系统规则概述 Sentinel 系统自适应限流从整体维度对应用入口流量进行控制结合应用的 Load、CPU 使用率、总体平均 RT、入口 QPS 和并发线程数等几个维度的监控指标通过自适应的流控策略让系统的入口流量和系统的负载达到一个平衡让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。 Load 自适应 仅对 LinuxUnixlike 机器生效是系统的 load1 作为启发指标进行自适应系统保护。当系统load1 超过设定的启发值且系统当前的并发线程数超过估算的系统容量时才会触发系统保护BBR 阶段。系统容量由系统的 maxQps * minRt 估算得出。设定参考值一般是 CPU cores * 2.5。 CPU usage 当系统 CPU 使用率超过阈值即触发系统保护取值范围 0.01.0比较灵敏。 平均 RT 当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护单位是毫秒 并发线程数 当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护 入口QPS 当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护 6.3.3 sentinel控制台配置 在控制台上提供了多种系统保护规则这里以其中的某一种为例进行说明比如下面设置“入口QPS”这里设置为1 删除之前配置的其他接口配置规则快速刷新接口时可以看到下面的效果说明这种全局配置规则生效了。 七、Sentinel配置规则持久化 在上面的操作中可以发现一个比较大的问题就是一旦当工程重启或者sentinel服务重启之后之前界面上配置的规则就丢失了这个并不奇怪因为默认情况下这些规则是动态的存储在内存中的这在线上环境是肯定不允许的因此为了安全起见需要将sentine的配置规则进行持久化存储。 关于sentinel的规则持久化官方主要提供了3种模式分别做一一概述 7.1 三种规则持久化模式 7.1.1 原始模式 API 将规则推送至客户端并直接更新到内存中扩展写数据源WritableDataSource其优点就是简单无需任何依赖缺点也很明显重启就丢失。 7.1.2 pull模式 扩展写数据源WritableDataSource客户端主动向某个规则管理中心定期轮询拉取规则这个规则中心可以是 RDBMS、文件等其优点就是简单无需任何依赖缺点是不能保证一致性实时性得不到保障拉取过于频繁时可能存在性能问题。 pull 模式的数据源如本地文件、RDBMS 等一般是可写入的。使用时需要在客户端注册数据源将对应的读数据源注册至对应的 RuleManager将写数据源注册至 transport的WritableDataSourceRegistry 中。 7.1.3 push模式 扩展读数据源ReadableDataSource规则中心统一推送客户端通过注册监听器的方式时刻监听变化比如使用 Nacos、Zookeeper 等配置中心。这种方式有更好的实时性和一致性保证。生产环境下一般采用 push 模式的数据源其优点是规则持久化且能保持一致性快捷但是需要引入第三方依赖。 生产环境下一般更常用的是 push 模式的数据源。对于 push 模式的数据源,如远程配置中心ZooKeeper, Nacos, Apollo等等推送的操作不应由 Sentinel 客户端进行而应该经控 制台统一进行管理直接进行推送数据源仅负责获取配置中心推送的配置并更新到本地。因此推送规则正确做法应该是 配置中心控制台/Sentinel 控制台 → 配置中心 → Sentinel 数据源 → Sentinel而不是经 Sentinel 数据源推送至配置中心。这样的流程就非常清晰了 7.2 整合nacos规则持久化 7.2.1 引入依赖 dependencygroupIdcom.alibaba.csp/groupIdartifactIdsentinel-datasource-nacos/artifactId/dependency 7.2.2 配置文件
下面贴出完整的配置文件内容
server:port: 8040spring:application:name: order-servicecloud:nacos:discovery:server-addr: localhost:8848 #服务注册中心地址#config:#server-addr: localhost:8848 #配置中心地址sentinel:transport:dashboard: localhost:8080datasource:ds1:nacos:server-addr: localhost:8848dataId: order-flow-rulesgroupId: DEFAULT_GROUPdata-type: jsonrule-type: flowfeign:sentinel:enabled: true 7.2.3 naocos新增一个配置文件
配置文件的名称即为yaml中的dataId对应的名称选择json格式内容如下
[{resource: /testFlow,limitApp:default,grade:1,count:1,strategy:0,controlBehavior:0,clusterMode:false}
]关于参数解释 resource资源名称 limitApp来源应用 grade阀值类型0线程数1QPS count单机阀值 strategy流控模式0直接1关联2链路 controlBehavior流控效果0快速失败1warmUp2排队等待 clusterMode是否集群 7.2.4 请求接口
此时还未登录dashboard的情况下快速刷接口时可以看到如下效果说明此时从nacos中读取到了配置规则 此时再看dashboard可以看到这里针对该接口多了一个流控规则 7.2.5 重启服务
重启服务稍等一会之后再次刷接口再次进入dashboard进行查看流控规则发现依然能够加载到之前从nacos中的流控规则说明持久化规则生效了。 八、写在文末
本文通过较大的篇幅全方位讲述了sentinel的限流、熔断降级等规则的使用以及如何整合springcloud进行跨服务访问使用由于sentinel涉及到的点比较多需要投入较多的时间和精力去研究这对于后续在生产环境中合理使用sentinel的功能时也是一个很好的储备。
