一、初始Sentinel
1.雪崩问题及解决方案
1.1 什么是雪崩
微服务调用链路中的某个服务故障,引起整个链路中的所有微服务都不可用,这就是雪崩。
1.2 怎么解决雪崩问题
解决雪崩问题的常见方式有四种:
• 超时处理:设定超时时间,请求超过一定时间没有响应就返回错误信息,不会无休止等待• 舱壁模式:限定每个业务能使用的线程数,避免耗尽整个 tomcat 的资源,因此也叫线程隔离。• 流量控制:限制业务访问的 QPS ,避免服务因流量的突增而故障。
超时处理:设定超时时间,请求超过一定时间没有响应就返回错误信息,不会无休止等待
舱壁模式:限定每个业务能使用的线程数,避免耗尽整个tomcat的资源,因此也叫线程隔离。
熔断降级:由断路器统计业务执行的异常比例,如果超出阈值则会熔断该业务,拦截访问该业务的一切请求。
流量控制:限制业务访问的QPS,避免服务因流量的突增而故障
1.3 总结
2.服务保护技术对比
3.认识Sentinel
3.1 Sentinel介绍
Sentinel是阿里巴巴开源的一款微服务流量控制组件。官网地址:https://sentinelguard.io/zh-cn/index.html
Sentinel 具有以下特征:
3.2 Sentinel安装
sentinel官方提供了UI控制台,方便我们对系统做限流设置。大家可以在GitHub下载。
3.3 Sentinel的启动
使用 java -jar sentinel-dashboard-1.8.1.jar 命令,端口号默认为8080
如果要修改Sentinel的默认端口、账户、密码,可以通过下列配置:
3.4 访问Sentinel
在浏览器输入localhost:8080 (localhost:端口号)即可看到控制台页面,默认的账户和密码都是sentinel
4. 引入微服务项目
要使用Sentinel肯定要结合微服务,这里我们使用SpringCloud实用篇中的cloud-demo工程。没有的小伙伴可以在前面的博客中找到: http://t.csdn.cn/zIezthttp://t.csdn.cn/zIezt
5. 微服务整合Sentinel
我们在order-service中整合Sentinel,并且连接Sentinel的控制台,步骤如下
5.1 引入sentinel依赖
<!-- 引入Sentinel-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
5.2 配置控制台地址
#配置Sentinel控制台地址---默认端口号为8080
spring.cloud.sentinel.transport.dashboard=localhost:8100
5.3 测试
访问微服务的任意端点,触发sentinel监控
二、流量控制
1.簇点链路
簇点链路:就是项目内的调用链路,链路中被监控的每个接口就是一个资源。默认情况下sentinel会监控SpringMVC的每一个端点(Endpoint),因此SpringMVC的每一个端点(Endpoint)就是调用链路中的一个资源。
流控、熔断等都是针对簇点链路中的资源来设置的,因此我们可以点击对应资源后面的按钮来设置规则:
2.快速入门
点击资源/order/{orderId}后面的流控按钮,就可以弹出表单。表单中可以添加流控规则,如下图所示:
其含义是限制 /order/{orderId}这个资源的单机QPS为1,即每秒只允许1次请求,超出的请求会被拦截并报错。
2.1 测试
流控规则入门案例
需求:给 /order/{orderId}这个资源设置流控规则,QPS不能超过 5。然后利用jemeter测试。
1.设置流控规则:
2.jemeter测试:
3. 流控模式
在添加限流规则时,点击高级选项,可以选择三种流控模式:
3.1流控模式----直接
3.2 流控模式---关联
当/update资源访问量触发阈值时,就会对/save资源限流,避免影响/update资源
测试
需求:
• 在 OrderController 新建两个端点: /product/save 和 /product/update ,无需实现业务• 配置流控规则,当 /order/ update 资源被访问的 QPS 超过 5 时,对 /order/query 请求限流
第一步:controller层配置
第二步:测试两个接口并实时注册到Sentinel
第三步: 设置流控模式---关联
当update达到阈值上限,限制save的执行
第四步:测试
满足下面条件可以使用关联模式:
3.3 流控模式----链路
链路模式:只针对从指定链路访问到本资源的请求做统计,判断是否超过阈值。
例如有两条请求链路:
如果只希望统计从/test2进入到/common的请求,则可以这样配置:
测试:
需求:有查询订单和创建订单业务,两者都需要查询商品。针对从查询订单进入到查询商品的请求统计,并设置限流。
步骤:
•Sentinel默认只标记Controller中的方法为资源,如果要标记其它层的方法,需要利用@SentinelResource注解,示例:
Sentinel默认会将Controller方法做context整合,导致链路模式的流控失效,需要修改application.yml,添加配置
#关闭上下文件---注册@SentinelResource("queryGoods")
spring.cloud.sentinel.web-context-unify=false
第一步: controller层
第二步:service层
第三步: 在配置文件中注册该注解第四步: 设置流控模式----链路
两个请求同时调用该链路,只对saveOrder做设置
第五步: 测试
3.4 总结
流控模式有哪些?
4.流控效果
4.1 快速失败
4.2 流控效果----warm up
warm up也叫预热模式,是应对服务冷启动的一种方案。请求阈值初始值是 threshold / coldFactor,持续指定时长后,逐渐提高到threshold值。而coldFactor的默认值是3.
例如,我设置QPS的threshold为10,预热时间为5秒,那么初始阈值就是 10 / 3 ,也就是3,然后在5秒后逐渐增长到10.
测试:
需求:给/order/{orderId}这个资源设置限流,最大QPS为10,利用warm up效果,预热时长为5秒
第一步:设置流控效果----warm Up
第二步: 测试
4.3 流控效果----排队等待
当请求超过QPS阈值时,快速失败和warm up 会拒绝新的请求并抛出异常。而排队等待则是让所有请求进入一个队列中,然后按照阈值允许的时间间隔依次执行。后来的请求必须等待前面执行完成,如果请求预期的等待时间超出最大时长,则会被拒绝。
例如:QPS = 5,意味着每200ms处理一个队列中的请求;timeout = 2000,意味着预期等待超过2000ms的请求会被拒绝并抛出异常
测试:
需求:给/order/{orderId}这个资源设置限流,最大QPS为10,利用排队的流控效果,超时时长设置为5s
第一步: 设置流控效果----排队等待
第二步: 测试
4.4 总结
流控效果有哪些?
• 排队等待:请求会进入队列,按照阈值允许的时间间隔依次执行请求;如果请求预期等待时长大于超时时间,直接拒绝
原文地址:https://www.jb51.cc/wenti/3280571.html
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。