罗湖网站建设公司,福州网站建设找嘉艺网络,互联网网站建设水平,网站建设手机app目录 雪崩问题
解决雪崩问题的方法#xff1a;
我们使用sentinel组件实现微服务的保护 一#xff1a;下载sentinel
二.启动sentinel
三.访问#xff1a;localhost:8080 默认的账号和密码都是sentinel 微服务整合sentinel
一.导入sentinel依赖
二.在application.yml配置…目录 雪崩问题
解决雪崩问题的方法
我们使用sentinel组件实现微服务的保护 一下载sentinel
二.启动sentinel
三.访问localhost:8080 默认的账号和密码都是sentinel 微服务整合sentinel
一.导入sentinel依赖
二.在application.yml配置文件中编写配置sentinel控制台的地址
第三步启动微服务项目并访问微服务的某一个接口
Sentinel设置流控
使用jmeter工具测试接口
jmeter介绍
jmeter安装 启动
编辑 使用
测试计划添加线程组
添加http请求行为编辑
编辑 添加响应结果监听器 启动线程组
查看结果树有一个成功因为设置了sentinel流控设置了一秒只能访问一次这个接口
查看聚合报告
编辑 流控模式
直接模式
关联模式 雪崩问题
微服务调用链路中的某一个服务故障引起整个链路中所有微服务都不可用就会造成雪崩
举个例子一个微服务就是一个tomcat服务器而一个tomcat服务器只有几百个线程可用这个A服务在访问另一个B微服务时需要60秒才能响应那么这个A服务的所有线程都会因为B服务的长时间不响应而阻塞最后导致A服务不可用进而导致调用A微服务的所有微服务都不可用这就是雪崩问题
解决雪崩问题的方法
1.超时处理设置超时时间请求超过一定时间没有响应就直接返回错误信息这样一来就不会无休止等待
2.舱壁模式限定每一个微服务能使S用的线程数从而避免耗尽整个tomcat的资源因此也叫做线程隔离
3.熔断降级由断路器统计业务执行的异常比例如果超出阈值则会熔断该服务拦截访问该业务的一切请求。就是一个微服务出现内部异常一旦超过一定比例就会有一段时间其他服务都不能访问整个出现问题的微服务过了一段时间后才尝试进行访问如果还是不行就继续熔断
4.流量控制限制业务访问的QPS每秒的访问数量,避免服务因为流量激增而故障。就是如果有几万个请求同时访问一个服务需要把这些请求分批次少量的发送服务
我们使用sentinel组件实现微服务的保护 一下载sentinel
下载地址
Release v1.8.1 · alibaba/Sentinel
下载sentinel的jar包
二.启动sentinel
java -jar sentinel-dashboard-1.8.1.jar
三.访问localhost:8080 默认的账号和密码都是sentinel 如果想改端口号 java -Dserver.port9090 -Dcsp.sentinel.dashboard.serverlocalhost:9090 -Dproject.namesentinel-dashboard -jar sentinel-dashboard-1.8.1.jar 微服务整合sentinel
一.导入sentinel依赖
!-- 导入sentinel依赖--dependencygroupIdcom.alibaba.cloud/groupIdartifactIdspring-cloud-starter-alibaba-sentinel/artifactId/dependency
这里我没有指定版本号因为我在父工程已经导入了spring-cloud-alibaba的父工程来管理spring-cloud-alibaba的所有组件的版本号
!-- SpringCloudAlibaba的父工程管理依赖--dependencygroupIdcom.alibaba.cloud/groupIdartifactIdspring-cloud-alibaba-dependencies/artifactIdversion${spring-cloud-alibaba}/versiontypepom/typescopeimport/scope/dependency
二.在application.yml配置文件中编写配置sentinel控制台的地址
spring:cloud:sentinel:transport:dashboard: localhost:9090 #控制台地址
第三步启动微服务项目并访问微服务的某一个接口
可以发现sentinel已经监控到了这个order-service微服务 簇点链路就是项目内的调用链路链路中被监控的每一个接口就是一个资源。默认情况下sentinel会监控SpringMVC的每一个端点(Endpoint)一个端点就是一个接口因此SpringMVC的每一个端点就是调用链路中的每一个资源。流控熔断等都是针对簇点链路中的资源来设置的因此我们可以点击后面的按钮来设置规则 Sentinel设置流控
流控设置点击接口后面的流控按钮
选择阈值类型未QPS每秒中的访问次数,然后阈值设置为1
这样一来这个接口的流控为每秒中只能访问一次 效果
一秒内访问多次就会显示被sentinel阻塞直接报错 使用jmeter工具测试接口
jmeter介绍
JMeter是由Apache组织开发的一款基于Java的压力测试工具。它最初设计用于Web应用测试但随着时间的推移JMeter的功能已经扩展到了其他的测试领域。JMeter能够模拟大量用户对服务器、网络或对象进行负载测试从而测试它们在不同压力下的性能并进行整体性能分析。
jmeter安装
官网下载链接Apache JMeter - Download Apache JMeter 启动
解压以后进入bin目录打开jmeter.properties文件修改语言为中文 点击jmeter.bat文件启动jemter工具 使用
测试计划添加线程组 在线程组中设置线程数为200ramp-up为在多长时间内创建这200个线程时间越短越高并发
循环次数为每个线程的执行次数 添加http请求行为
设置请求路径和编码格式 (utf8) 添加响应结果监听器 启动线程组 查看结果树有一个成功因为设置了sentinel流控设置了一秒只能访问一次这个接口 查看聚合报告 流控模式
直接模式统计当前资源的请求触发阈值对当前资源直接限流也就是默认的模式关联模式统计与当前资源相关的另一个资源触发阈值时对当前资源限流链路模式统计从指定链路访问到本资源的请求触发阈值时对指定的链路限流
直接模式
对这个接口每秒钟只能访问五次 设置在2秒内创建20个线程即一秒10个线程期望的结果就是每秒钟有五个线程访问这个接口成功 关联模式 统计与当前资源相关的另一个资源触发阈值时对当前资源限流
使用场景比如用户支付时需要修改订单状态同时用户要查询订单。查询和修改会争抢数据库锁就会产生竞争。业务需求是优先支付和更新订单的业务因此当修改订单业务触发阈值时需要对查询订单业务进行限流 写资源优先一旦写资源达到阈值就会对读资源的操作进行限流因为写资源优先
例子
写两个接口一个查询一个更新
GetMapping(query)public String query() {return 查询订单;}GetMapping(update)public String update(){return 更新订单;} 配置流控规则当/order/update 资源被访问的QPS超过5时对/order/query资源进行限流
在/order/query的流控按钮中编写 在jmeter中测试一秒创建10个线程去访问/order/update,这样一来已经超过了QPS阈值(一秒只能访问5次)最后sentinel对/order/query进行限流 链路模式
链路模式只针对从指定链路访问到本资源的请求做统计判断是否超过阈值。
配置示例
例如有两条请求链路 /test1 -- /common /test2 -- /common
如果只希望限制从/test2进入到/common的请求而限制从/test1开始的则可以这样配置 实战案例
需求有查询订单和创建订单业务两者都需要查询商品。针对从查询订单进入到查询商品的请求统计并设置限流。
步骤 在OrderService中添加一个queryGoods方法不用实现业务 在OrderController中改造/order/query端点调用OrderService中的queryGoods方法 在OrderController中添加一个/order/save的端点调用OrderService的queryGoods方法 给queryGoods设置限流规则从/order/query进入queryGoods的方法限制QPS必须小于2 注意需要给queryGoods方法使用SentinelResourse注解让sentinel知道这个方法也是一个资源sentinel默认只会把使用SpringMVC注解的方法当作资源 //让sentinel知道这个方法也是一个资源因为sentinel默认只会把使用SpringMVC注解的方法当作资源SentinelResource(goods)public void queryGoods(){System.out.println(查询商品);}
在链路模式中是对不同来源的两个链路做监控。但是sentinel默认会给进入SpringMVC的所有请求设置同一个root资源会导致链路模式失效。
我们需要关闭这种对SpringMVC的资源聚合修改order-service服务的application.yml文件
spring:cloud:sentinel:web-context-unify: false # 关闭context整合 给/order/query的goods资源做链路限制 结果
通过/order/save访问的goods资源不受限制 通过/order/query访问的goods资源每一秒只能访问2次 总结
直接直接当前资源进行限流
关联如果高优先级资源 触发阈值就对低优先级资源进行限制
链路阈值统计时只统计从指定资源进入当前资源的请求是对请求来源的限流
流控效果 流控效果是指请求达到流控阈值时应该采取的措施包括三种 快速失败达到阈值后新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式。 warm up预热模式对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化从一个较小值逐渐增加到最大阈值自己规定的。 排队等待让所有的请求按照先后次序排队执行两个请求的间隔不能小于指定时长
