写点什么

云服务过载控制的前世今生

  • 2023-03-29
    广东
  • 本文字数:2107 字

    阅读完需:约 7 分钟

云服务过载控制的前世今生

本文分享自华为云社区《云服务过载控制的前世今生》,作者:SRE 确定性运维 。

为什么会有过载?


过载,是服务或应用处理的请求超过了自身所能承载的能力,造成服务或应用自身处理请求时延变慢、错误率增加,或者请求失败,乃至服务中断。



如上图,客户端与服务器通信的分布式系统中,客户端在等待一段时间后常常会变得不耐烦,并会停止等待服务器响应。这段时间称为超时时间。如果服务器因过载而导致其延迟超过客户端的超时值,请求会开始失败。图 1 显示服务器响应时间如何随着提交的吞吐量(以每秒事务数为单位)增加而延长,最终到达情况迅速恶化的转折点。



如上图,当响应时间超过客户端超时值,可清楚看到情况很糟糕,但并未显示到底有多糟糕。可在延迟旁边画出客户端感知到的可用性,不使用常规的响应时间测量值,而是改用中值响应时间。中值响应时间表示 50%的请求比中值快。如果服务的中值延迟时间等于客户端超时值,则表示一半的请求超时,因此可用性为 50%,进而将延迟增加问题转化为可用性问题。

2. 过载的典型表现?

2.1 典型过载环介绍


● 客户端发起一个会造成系统瘫痪的恶意/规模性请求。

●  LB 节点将这个请求转发给一个后端服务管理节点处理。

●  后端服务管理节点尝试处理这个恶意/规模性请求。

●  LB 节点自动识别到这个请求后端管理节点无法正常处理,并将处理这个请求的管理节点剔除。

●  客户端再次尝试,且 LB 将这个恶意请求再次下发给另外一个后端管理节点。

●  LB 再次将处理这个恶意请求的后端管理节点剔除。

● 恶意/规模请求一直持续下去,直到所有的后端管理节点故障,乃至重大隐患/事件发生。


2.2 过载表现说明


● 缺少基于优先级的过载控制(按照租户/请求类型 QoS),导致请求处理通道堵塞或异常,任何请求均失败。      

                   

● 缺少过载感知与溯源能力,海量蚂蚁流类请求无序抢占,导致正常请求出现了性能损失,但无法在短时间内感知过载现象,无法获取过载源。


● 缺少依赖组件过载感知与控制,服务自身请求没有过载,但依赖组件出现过载,导致服务整个链路的请求发生过载。

3. 如何应对服务/应用过载?


应对业务随机突增,扩展服务或应用处理能力,但无法控制客户的请求按照优先级处理。当客户端请求速率超过规格时,相应请求可被拒绝、或可被限制(包括速限制单个客户端对该服务继续施加负载),实现服务或应用已承接业务的持续高可用(已经接入用户,在过载期间 SLA 满足业务目标)。


过载处理模型:通用可伸缩定律(Universal Scalability Law),阿姆达尔定律 Amdahl’s Law 的一个衍生理论,定义了系统中的串行化,例如数据库的性能瓶颈,包括关系数据库和非关系数据库,很难做到在线实时扩缩容。重负载时,请求排队等待处理,这时线程争用,上下文切换和垃圾回收等会加重系统负载。请求排队的时间越来越长直到超时,如此形成一个恶性循环。



服务过载控制是一个循序渐进的过程,在大象流/蚂蚁流的冲击下,服务一般具备三步走的过载控制:


Step1:服务过载自治,包括 Scale-out,Scale-up,基于系统自身的基础能力进行扩容。


Step2:感知过载现象,哪个服务/集群出现了过载异常,影响了哪些业务。


Step3: 启动过载控制

3.1 基础过载控制:重试保护,小服务主动消费,超时保护,幂等保等基础能力。

3.2 中阶过载控制:过载溯源,基于 QoS、黑白名单的过载控制。

3.3 高阶过载控制:基于 AIOPS 自动学习,主动进行过载反压,过载拉黑,及精细化 QoS、黑白名单控制等。


本文重点介绍服务或应用应对过载的基础能力:


● 重试保护:重试服务调用链中,存在逐级放大的风险。可以每个主调用最多重试 1 次;为每个依赖项保留少数重试次数(最多 10 次),如每 1000 次请求重试次数最多 10 次。


● 消费者向生产者发起请求:拥有小规格的服务向大规格服务请求,而不是大规格服务请求小规格服务,减少内部冲击!



● 超时保护:服务依赖项响应慢要有超时保护(如 TP99.9 出现异常,主动超时),减少服务请求因尝试/多次超时对系统造成持续消耗,最终导致服务过载。


● 幂等设计 &过时请求释放:每个请求包含唯一 ID,如果与请求 ID 关联的请求已经成功,在再次获得相同请求时,直接忽略,并确认成功即可(公网不稳定/不可靠是一个长期存在的现实)。且排队过期请求(long live),如 50%客户在 10 秒后放弃请求,系统在 5min 后处理该请求的意义就不存在了。


● 服务降级:服务在降级/亚健康前,主动拒绝不能处理的请求,减少过度请求对系统造成过载冲击。


● 统一错误码:过载类的 API 请求或过载类的页面请求定义唯一的标识符,支撑客户端快速感知过载现象,进而在客户端主动规避过载异常。

结束语:


服务过载在云时代是必然存在的,上层应用(比如某购物 App,或者某翻译 App)客户端少量重负载的大象流或海量的蚂蚁流请求下会造成服务过载,服务端偶发的高负载会造成服务过载,网络的抖动或时延会造成服务过载,互联网各种攻击/恶意行为也会造成服务过载。如何解决与应对成为了云服务开发、运营与运维的关键能力。


如何高效 &及时感知过载、有效的处置过载就成为了关键能力,本期我们谈到基础过载控制能力,下期会围绕过载控制与感知的中高阶能力进行介绍,包括过载溯源,精细化与分布式的过载控制等。


点击关注,第一时间了解华为云新鲜技术~

发布于: 刚刚阅读数: 3
用户头像

提供全面深入的云计算技术干货 2020-07-14 加入

生于云,长于云,让开发者成为决定性力量

评论

发布
暂无评论
云服务过载控制的前世今生_云计算_华为云开发者联盟_InfoQ写作社区