作者|熊政(八风)
出品|阿里巴巴新零售淘系技术部
导读
诺亚(Noah) 自适应流控 是一种面向结果(保护系统资源不过载)的声明式解决方案,基于反馈控制算法,避免了基于Load限流无法确定性的保障系统稳定,解决了人工静态限流配置疏漏或过时的痛点,大幅提升应用抵抗流量冲击的能力。在过去的一年中,诺亚(Noah)保障了大量业务应用系统,已有数万容器大规模部署;稳定性上最高可提升20倍于业务负载流量的上限QPS;最高可提升100%的资源利用率;同时优化了体验与效率。本文通过详细对比诺亚(Noah)自适应流控与基于Load限流两种系统保护方法,来说明诺亚(Noah)的优势,以及采用面向结果的声明式解决方案的实战经验。
在线业务系统普遍存在如下的事件与关联关系:
流量进入业务逻辑进行处理;
处理时消耗资源;
资源过载时,引起业务逻辑(服务)可用性问题。
Load、线程数(并发)、RT等指标是对系统处理排队情况的表征,属于系统过载保护原因的范畴,是过程信息。
Ta 们如 QPS 一样,对「因」指标进行判断,
并采取措施:静态 QPS 限流、Load 限流、线程数限流、基于 RT 限流/熔断等。
将「因」作为指标的关键问题在于因与果之间的关系在不断的变化,没有确定性;
比如:
服务器性能差异:有些机器能承载上千 QPS,而有些却处理一半的量都吃力。
业务迭代演进:今天上了个新需求,导致服务资源消耗陡增,临时做静态 QPS 限流;明天做了性能优化,有静态 QPS 限流,资源利用率却提不上去。
业务流量模型变更:大促态/日常态 同一个服务,业务逻辑可能完全不同;不同的节日,A、B 服务的流量也有较大的差异。
而我们认为的自适应/反馈控制等,都是直接控制「果」的指标。
比如我们说要保护系统不过载,指的就是保护系统资源不过载(资源:CPU、内存、网卡等)。
CPU是资源供给的主要信号,针对CPU做声明式的系统保护,即在面向结果做承诺。
再加上反馈控制算法,自适应、实时就地控制流量;越过了因果之间关系变化的不确定性,转为直接面向结果的确定性。
Noah 就是这样一种面向结果的声明式的系统保护方案,是真正意义的自适应。
你还在使用 Load 限流吗?基于 Load 限流的系统保护方法:无法确定性保障系统稳定!
Load 指标有滞后性:对于脉冲流量,系统会被瞬间压垮,还未等Load反应已进入过载状态;
Load限流对系统负载无控制力:在高压时,未被限流的请求超时,服务成功率大幅下跌;
Load覆盖场景受限。而CPU是资源供给的主要信号,覆盖场景更加全面;
对于应用本身资源过载反应不到Load飙升的情况不适用:如导购类,通常RT短、CPU较多使用在序列化开销。
Load指标没有归一化,取值[0,+∞)
,阈值设置不直观,需要有条件逐步压测再人工调整,较繁琐。
简而言之,Load的问题是太慢了(更新频率5秒,变化的响应需要更长时间),系统已进入「反复过载」状态;
而使用诺亚(Noah)自适应流控解决方案,立即响应(小于0.5秒),系统「从未过载」(详见本文)。
由于 Load 的滞后性,Load 限流方案在流量来时,存在 10 秒级 延迟反应(限流)
虽然反应了,但系统并不能稳定,RT 崩溃,系统持续处于过载状态(反复过载),甚至会被压垮,系统过载状态下,无法提供正常服务。
流量过后,系统不能马上恢复服务,甚至无法恢复(压垮的情况)。
而 Noah 自适应流控在流量来时立即反应,
(亚秒级的迅速反应得益于直接使用高频 CPU 采样和反馈控制算法),
在系统负载过程中,系统保持稳定状态,RT无劣化,系统从未过载,与正常时保持一致,
仍能提供正常服务,在本场景中服务成功量为正常时的 90%。流量过后,立即恢复,系统服务成功率立即恢复为100%。
Noah自适应流控右侧有一小段接受QPS跌了是由于施压机器其中有一台压力打不上。
反应时间
加压时(流量来时)
即大流量来了,开始做出限流反应的时长。
减压时(流量下降)
即大流量过后,服务恢复时间
系统负载控制。即在压力下(大的压力QPS下),
服务的RT劣化与波动情况
与服务正常RT(即低负载RT)对比
服务成功QPS的劣化与波动情况
与服务额定QPS(即拐点QPS)对比
上面控制的最差情况是
系统被压挂,而不能处理任何请求(成功QPS为0)
正常服务时,300QPS,CPU 50%,RT 130ms。
详尽对比压测如下,图例中:横轴为时间,左主纵轴为QPS,右次纵轴为RT ms。
▐ 反应时间对比
Load限流方案存在 10秒级 的反应时长(虽然反应了,有限流产生,但系统并不能稳定)。在实际测试场景下,经过11s的反应时长才开始限流,
由于方案使用的Load1的滞后性,必然存在一个大的反应时长,而不能立即反应。
Noah自适应流控方案 与流量到达时刻一致,1秒立即反应。
Load 限流方案流量来时延迟反应
Noah 自适应流控方案流量来时立即反应
Load 限流方案存在 10秒级 的 RT 恢复时间。在本测试场景下,经过10s后,RT才恢复到正常水平,由于系统持续过载,流量下降无法立即恢复正常服务提供,甚至系统被压垮。
Noah自适应流控方案 与流量下降时刻一致,1秒立即反应,系统未过载,立即恢复正常提供服务。
Load 限流方案流量下降时,RT 延迟反应
Noah自适应流控方案流量下降时,立即恢复
▐ 系统负载控制
正常服务时,服务的RT 130ms 左右。大流量时:
Load限流方案 RT崩溃(伴有FGC),系统过载。在本测试场景下,RT平均近 4000ms,是正常RT的30倍,峰值超 6000ms。
Noah自适应流控方案 RT保持稳定,系统未过载,如正常服务时的RT。
在本测试场景下,RT 130ms 左右,完全无劣化。
Load 限流方案负载时,RT崩溃,系统过载
Noah 自适应流控方案负载时,持续稳定如正常服务时,系统未过载
正常服务时,300QPS。大流量时:
Load限流方案 已无法提供有效服务。在本测试场景下,RT平均4000ms,如默认3秒超时,此时已无有效成功的请求,服务成功率几乎跌0。
Noah自适应流控方案 仍能提供有效服务。在本测试场景下,能稳定提供平均270QPS有效服务。
Load 限流方案负载时,RT崩溃,无有效服务,服务成功率几乎为0
Noah 自适应流控方案负载时,仍能提供有效服务,为正常服务时的90%
Load 限流方案,系统会被压垮:
300QPS 调速到 1800QPS,接受QPS 1087。
完成调速至1800QPS,全量超时,错误率100%;系统已被压垮,服务端口、ssh端口 均链接不上。
成功请求的avgRT在1s以上,如果业务超时设置为1s,可以认为此刻几乎没有请求能够正常服务了,服务成功请求 QPS 跌0。
之后系统完全无响应,直到半个小时之后,系统重启前,服务端口、ssh 端口 都依然链接不上。
Load 限流方案被压垮,上图最后一秒数据后,系统已失去响应。
ssh 链接不上
由于会场入口宽泛,入口服务包含的是不同的会场,悬殊的处理能力不可能逐个会场配置静态限流。
完全依赖Noah自适应流控,无静态限流配置,全链路压测/线上无需调整限流QPS阈值。
双11线上与压测都有效保障系统的稳定。
Noah防御大流量,涌入预期的2倍大流量,系统稳定,RT不劣化,大流量过后立即恢复。
由于容量缺失,事后做了23.5%的补充,双11线上保障系统的稳定。
由于网络设备重启演练,导致网络流量卡顿、聚集,15倍于压测模型的流量抵达应用系统,Noah保护系统,防御大流量。
Noah防御大流量,系统稳定,RT不劣化,网络恢复后立即恢复。
由于业务配置错误,导致10倍于压测模型的流量抵达应用系统,Noah保护系统,防御大流量。
Noah防御大流量,系统稳定,RT不劣化,配置修正后立即恢复。
由于中台组件在凌晨做数据升级,加上业务本身的CPU消耗,将CPU打满,Noah保护系统稳定运行。
CPU持续1分钟被打高,期间多次打满,Noah保护系统没有被拖垮;升级完成,CPU恢复后,系统服务立即恢复。
We are hiring
欢迎加入淘宝基础平台基础服务团队,团队成员大牛云集,有阿里移动中间件的创始人员、Dubbo核心成员、更有一群热爱技术,期望用技术推动业务的小伙伴。
淘宝基础平台基础服务团队,推进淘系(淘宝、天猫等)架构升级(代号Tango),致力于为淘系、整个集团提供基础核心能力、产品与解决方案:
业务高可用的解决方案与核心能力(应用高可用:为业务提供自适应的限流、隔离与熔断的柔性高可用解决方案,站点高可用:故障自愈、多机房与异地容灾与快速切流恢复)
新一代的业务研发模式FaaS(一站式函数研发Gaia平台)
下一代网络协议QUIC实现与落地
移动中间件(API网关MTop、接入层AServer、消息/推送、配置中心等等)
期待一起参与加入淘系基础平台的建设~
简历投递至????:
哲良 [email protected] (基础平台基础服务-基础架构Leader)
END
更多好文
点击下方图片即可阅读
双11备战“核武器”,白天态全链路压测技术大揭秘!
淘宝如何保障业务稳定性——诺亚(Noah)自适应流控