摘要:服务过载在云时代是必然存在的,如何解决与应对成为了云服务开发、运营与运维的关键要素,通过过载场景现象、基础过载控制等能力,来应对出现的服务/应用过载。
本文分享自华为云社区《云服务过载控制的前世今生》,作者:SRE确定性运维 。
1.为什么会有过载?
过载,是服务或应用处理的请求超过了自身所能承载的能力,造成服务或应用自身处理请求时延变慢、错误率增加,或者请求失败,乃至服务中断。
![](https://pic3.zhimg.com/80/v2-337b43b4436379d53a00da7616c52042_720w.webp)
如上图,客户端与服务器通信的分布式系统中,客户端在等待一段时间后常常会变得不耐烦,并会停止等待服务器响应。这段时间称为超时时间。如果服务器因过载而导致其延迟超过客户端的超时值,请求会开始失败。图1显示服务器响应时间如何随着提交的吞吐量(以每秒事务数为单位)增加而延长,最终到达情况迅速恶化的转折点。
![](https://pic2.zhimg.com/80/v2-6b5eb516380166d1302db51a3239d735_720w.webp)
如上图,当响应时间超过客户端超时值,可清楚看到情况很糟糕,但并未显示到底有多糟糕。可在延迟旁边画出客户端感知到的可用性,不使用常规的响应时间测量值,而是改用中值响应时间。中值响应时间表示50%的请求比中值快。如果服务的中值延迟时间等于客户端超时值,则表示一半的请求超时,因此可用性为50%,进而将延迟增加问题转化为可用性问题。
2. 过载的典型表现?
2.1 典型过载环介绍
● 客户端发起一个会造成系统瘫痪的恶意/规模性请求。
● LB节点将这个请求转发给一个后端服务管理节点处理。
● 后端服务管理节点尝试处理这个恶意/规模性请求。
● LB节点自动识别到这个请求后端管理节点无法正常处理,并将处理这个请求的管理节点剔除。
● 客户端再次尝试,且LB将这个恶意请求再次下发给另外一个后端管理节点。
● LB再次将处理这个恶意请求的后端管理节点剔除。
● 恶意/规模请求一直持续下去,直到所有的后端管理节点故障,乃至重大隐患/事件发生。
![](https://pic3.zhimg.com/80/v2-36facb4f5260f662663829973e46e016_720w.webp)
2.2 过载表现说明
● 缺少基于优先级的过载控制(按照租户/请求类型QoS),导致请求处理通道堵塞或异常,任何请求均失败。
● 缺少过载感知与溯源能力,海量蚂蚁流类请求无序抢占,导致正常请求出现了性能损失,但无法在短时间内感知过载现象,无法获取过载源。
● 缺少依赖组件过载感知与控制,服务自身请求没有过载,但依赖组件出现过载,导致服务整个链路的请求发生过载。
3. 如何应对服务/应用过载?
应对业务随机突增,扩展服务或应用处理能力,但无法控制客户的请求按照优先级处理。当客户端请求速率超过规格时,相应请求可被拒绝、或可被限制(包括速限制单个客户端对该服务继续施加负载),实现服务或应用已承接业务的持续高可用(已经接入用户,在过载期间SLA满足业务目标)。
过载处理模型:通用可伸缩定律(Universal Scalability Law),阿姆达尔定律Amdahl’s Law的一个衍生理论,定义了系统中的串行化,例如数据库的性能瓶颈,包括关系数据库和非关系数据库,很难做到在线实时扩缩容。重负载时,请求排队等待处理,这时线程争用,上下文切换和垃圾回收等会加重系统负载。请求排队的时间越来越长直到超时,如此形成一个恶性循环。
![](https://pic4.zhimg.com/80/v2-30ae97e5656122c2af0d29a01c8cd31b_720w.webp)
服务过载控制是一个循序渐进的过程,在大象流/蚂蚁流的冲击下,服务一般具备三步走的过载控制:
Step1:服务过载自治,包括Scale-out,Scale-up,基于系统自身的基础能力进行扩容。
Step2:感知过载现象,哪个服务/集群出现了过载异常,影响了哪些业务。
Step3: 启动过载控制
3.1基础过载控制:重试保护,小服务主动消费,超时保护,幂等保等基础能力。
3.2中阶过载控制:过载溯源,基于QoS、黑白名单的过载控制。
3.3高阶过载控制:基于AIOPS自动学习,主动进行过载反压,过载拉黑,及精细化QoS、黑白名单控制等。
本文重点介绍服务或应用应对过载的基础能力:
● 重试保护:重试服务调用链中,存在逐级放大的风险。可以每个主调用最多重试1次;为每个依赖项保留少数重试次数(最多10次),如每1000次请求重试次数最多10次。
● 消费者向生产者发起请求:拥有小规格的服务向大规格服务请求,而不是大规格服务请求小规格服务,减少内部冲击!
![](https://pic4.zhimg.com/80/v2-07a40e99e3a95d78c37420172b60869b_720w.webp)
● 超时保护:服务依赖项响应慢要有超时保护(如TP99.9出现异常,主动超时),减少服务请求因尝试/多次超时对系统造成持续消耗,最终导致服务过载。
● 幂等设计&过时请求释放:每个请求包含唯一ID,如果与请求ID关联的请求已经成功,在再次获得相同请求时,直接忽略,并确认成功即可(公网不稳定/不可靠是一个长期存在的现实)。且排队过期请求(long live),如50%客户在10秒后放弃请求,系统在5min后处理该请求的意义就不存在了。
● 服务降级:服务在降级/亚健康前,主动拒绝不能处理的请求,减少过度请求对系统造成过载冲击。
● 统一错误码:过载类的API请求或过载类的页面请求定义唯一的标识符,支撑客户端快速感知过载现象,进而在客户端主动规避过载异常。
结束语:
服务过载在云时代是必然存在的,上层应用(比如某购物App,或者某翻译App)客户端少量重负载的大象流或海量的蚂蚁流请求下会造成服务过载,服务端偶发的高负载会造成服务过载,网络的抖动或时延会造成服务过载,互联网各种攻击/恶意行为也会造成服务过载。如何解决与应对成为了云服务开发、运营与运维的关键能力。
如何高效&及时感知过载、有效的处置过载就成为了关键能力,本期我们谈到基础过载控制能力,下期会围绕过载控制与感知的中高阶能力进行介绍,包括过载溯源,精细化与分布式的过载控制等。