【金秋打卡】第14天 构建微服务设计架构知识体系--过载保护
2022/11/11 3:24:01
本文主要是介绍【金秋打卡】第14天 构建微服务设计架构知识体系--过载保护,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
课程名称:海量数据高并发场景,构建Go+ES8企业级搜索微服务
课程章节:5-8
课程讲师:少林码僧
课程内容:
什么是过载保护
系统会把一个峰值来设定为临界点阈值,当系统临近这个过载点的时候,放弃一部分的请求来避免系统超过负载
什么情况下出现过载
突发流量,或者故障节点离线导致资源不足引发过载
随着业务的发展,系统数据达到瓶颈.
当故障发生后,调用方会发起大量的重试。比如 A->B->C 这样调用,每次重试次数为三次,A发起请求调用B,但是B调用C 的时候失败了,B对C进行了三次重试,A对B又进行了三次重试,这样A实际透传到C的请求是9次,调用链越长,这种放大效越明显
系统过载引发的问题
直观表现是系统服务所在的实例的CPU内存等资源持续占用过高
请求持续进入,导致很多请求进入排队状态,资源被持续占用无法释放
常常伴随着一系列的连锁反应,并且在调用链比较长的时候,很难追溯到问题的根源
如何应对服务的过载问题呢?
在过载发生前,对关键服务进行良好的容量预估,和监控埋点,及时的进行监控告警
过载情况发生的时候,触发过载预案,及时通知相关责任人,并对服务进行优雅的降级
过载保护的实现方式
基于QPS或者基于系统资源占比的来实现,基于系统资源使用率更能准确的反应系统实例的繁忙程度
可以通过负载均衡器,当负载均衡器发现某一节点负载过高,可以把请求转发到不繁忙的服务上,防止流量倾斜
客户端节流控制也能很好的防止系统过载,这只能应对正常的请求,如果接口已经被人解析或者爆破,早就绕过了正常的客户端限流
课程收获:
微服务中的过载保护,主要是针对系统本身而言的,实际上如流量过大,应该及时考虑扩容,而不是一味的过载保护
这篇关于【金秋打卡】第14天 构建微服务设计架构知识体系--过载保护的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!
- 2024-05-15鸿蒙生态设备数量超8亿台
- 2024-05-13TiDB + ES:转转业财系统亿级数据存储优化实践
- 2024-05-09“2024鸿蒙零基础快速实战-仿抖音App开发(ArkTS版)”实战课程已上线
- 2024-05-09聊聊如何通过arthas-tunnel-server来远程管理所有需要arthas监控的应用
- 2024-05-09log4j2这么配就对了
- 2024-05-09nginx修改Content-Type
- 2024-05-09Redis多数据源,看这篇就够了
- 2024-05-09Google Chrome驱动程序 124.0.6367.62(正式版本)去哪下载?
- 2024-05-09有没有大佬知道这种数据应该怎么抓取呀?
- 2024-05-09这种运行结果里的10.100000001,怎么能最快改成10.1?