淘宝业务稳定性保障实战——诺亚(Noah)自适应流控

淘宝业务稳定性保障实战——诺亚(Noah)自适应流控_第1张图片

者|熊政(八风)

出品|阿里巴巴新零售淘系技术部

导读


诺亚(Noah) 自适应流控 是一种面向结果(保护系统资源不过载)的声明式解决方案,基于反馈控制算法,避免了基于Load限流无法确定性的保障系统稳定,解决了人工静态限流配置疏漏或过时的痛点,大幅提升应用抵抗流量冲击的能力。在过去的一年中,诺亚(Noah)保障了大量业务应用系统,已有数万容器大规模部署;稳定性上最高可提升20倍于业务负载流量的上限QPS;最高可提升100%的资源利用率;同时优化了体验与效率。本文通过详细对比诺亚(Noah)自适应流控与基于Load限流两种系统保护方法,来说明诺亚(Noah)的优势,以及采用面向结果的声明式解决方案的实战经验。

诺亚(Noah)自适应流控:面向结果的声明式解决方案


在线业务系统普遍存在如下的事件与关联关系:

  • 流量进入业务逻辑进行处理;

  • 处理时消耗资源;

  • 资源过载时,引起业务逻辑(服务)可用性问题。

淘宝业务稳定性保障实战——诺亚(Noah)自适应流控_第2张图片

Load、线程数(并发)、RT等指标是对系统处理排队情况的表征,属于系统过载保护原因的范畴,是过程信息。

Ta 们如 QPS 一样,对「因」指标进行判断,

并采取措施:静态 QPS 限流、Load 限流、线程数限流、基于 RT 限流/熔断等。

将「因」作为指标的关键问题在于因与果之间的关系在不断的变化,没有确定性;

比如:

  • 服务器性能差异:有些机器能承载上千 QPS,而有些却处理一半的量都吃力。

  • 业务迭代演进:今天上了个新需求,导致服务资源消耗陡增,临时做静态 QPS 限流;明天做了性能优化,有静态 QPS 限流,资源利用率却提不上去。

  • 业务流量模型变更:大促态/日常态 同一个服务,业务逻辑可能完全不同;不同的节日,A、B 服务的流量也有较大的差异。

而我们认为的自适应/反馈控制等,都是直接控制「果」的指标。

比如我们说要保护系统不过载,指的就是保护系统资源不过载(资源:CPU、内存、网卡等)。

CPU是资源供给的主要信号,针对CPU做声明式的系统保护,即在面向结果做承诺。

再加上反馈控制算法,自适应、实时就地控制流量;越过了因果之间关系变化的不确定性,转为直接面向结果的确定性。

Noah 就是这样一种面向结果的声明式的系统保护方案,是真正意义的自适应。


诺亚(Noah)自适应流控 vs. 基于Load限流


你还在使用 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)自适应流控_第3张图片

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秒立即反应。

淘宝业务稳定性保障实战——诺亚(Noah)自适应流控_第4张图片

Load 限流方案流量来时延迟反应

淘宝业务稳定性保障实战——诺亚(Noah)自适应流控_第5张图片

Noah 自适应流控方案流量来时立即反应

减压时

  • Load 限流方案存在 10秒级 RT 恢复时间。在本测试场景下,经过10s后,RT才恢复到正常水平,由于系统持续过载,流量下降无法立即恢复正常服务提供,甚至系统被压垮。

  • Noah自适应流控方案 与流量下降时刻一致,1秒立即反应,系统未过载,立即恢复正常提供服务。


淘宝业务稳定性保障实战——诺亚(Noah)自适应流控_第6张图片

Load 限流方案流量下降时,RT 延迟反应

淘宝业务稳定性保障实战——诺亚(Noah)自适应流控_第7张图片

Noah自适应流控方案流量下降时,立即恢复

▐  系统负载控制

服务的RT劣化与波动情况

正常服务时,服务的RT 130ms 左右。大流量时:

  • Load限流方案 RT崩溃(伴有FGC),系统过载。在本测试场景下,RT平均近 4000ms,是正常RT的30倍,峰值超 6000ms。

  • Noah自适应流控方案 RT保持稳定,系统未过载,如正常服务时的RT。
    在本测试场景下,RT 130ms 左右,完全无劣化。

淘宝业务稳定性保障实战——诺亚(Noah)自适应流控_第8张图片

Load 限流方案负载时,RT崩溃,系统过载

淘宝业务稳定性保障实战——诺亚(Noah)自适应流控_第9张图片

Noah 自适应流控方案负载时,持续稳定如正常服务时,系统未过载

服务成功 QPS 的劣化与波动情况

正常服务时,300QPS。大流量时:

  • Load限流方案 已无法提供有效服务。在本测试场景下,RT平均4000ms,如默认3秒超时,此时已无有效成功的请求,服务成功率几乎跌0。

  • Noah自适应流控方案 仍能提供有效服务。在本测试场景下,能稳定提供平均270QPS有效服务。

淘宝业务稳定性保障实战——诺亚(Noah)自适应流控_第10张图片Load 限流方案负载时,RT崩溃,无有效服务,服务成功率几乎为0

淘宝业务稳定性保障实战——诺亚(Noah)自适应流控_第11张图片

Noah 自适应流控方案负载时,仍能提供有效服务,为正常服务时的90%

▐  Load 限流系统被压垮的典型 Case

Load 限流方案,系统会被压垮:

  1. 300QPS 调速到 1800QPS,接受QPS 1087。

  2. 完成调速至1800QPS,全量超时,错误率100%;系统已被压垮,服务端口、ssh端口 均链接不上。

  3. 成功请求的avgRT在1s以上,如果业务超时设置为1s,可以认为此刻几乎没有请求能够正常服务了,服务成功请求 QPS 跌0。

  4. 之后系统完全无响应,直到半个小时之后,系统重启前,服务端口、ssh 端口 都依然链接不上。

淘宝业务稳定性保障实战——诺亚(Noah)自适应流控_第12张图片

Load 限流方案被压垮,上图最后一秒数据后,系统已失去响应。

ssh 链接不上

诺亚(Noah)业务稳定性保障实战



▐  19双11大促会场系统完全依赖 Noah 保护

  • 由于会场入口宽泛,入口服务包含的是不同的会场,悬殊的处理能力不可能逐个会场配置静态限流。

  • 完全依赖Noah自适应流控,无静态限流配置,全链路压测/线上无需调整限流QPS阈值。

  • 双11线上与压测都有效保障系统的稳定。

▐  19双11造势期零点保护淘宝直播防御大流量

  • Noah防御大流量,涌入预期的2倍大流量,系统稳定,RT不劣化,大流量过后立即恢复。

  • 由于容量缺失,事后做了23.5%的补充,双11线上保障系统的稳定。

▐  19双11全链路压测保护淘金币防御15倍超大脉冲流量

  • 由于网络设备重启演练,导致网络流量卡顿、聚集,15倍于压测模型的流量抵达应用系统,Noah保护系统,防御大流量。

  • Noah防御大流量,系统稳定,RT不劣化,网络恢复后立即恢复。

▐  19双12全链路压测营销平台入口系统防御10倍超大脉冲流量

  • 由于业务配置错误,导致10倍于压测模型的流量抵达应用系统,Noah保护系统,防御大流量。

  • Noah防御大流量,系统稳定,RT不劣化,配置修正后立即恢复。

▐  今年3月大促期间天猫农场完全依赖Noah保护

  • 由于中台组件在凌晨做数据升级,加上业务本身的CPU消耗,将CPU打满,Noah保护系统稳定运行。

  • CPU持续1分钟被打高,期间多次打满,Noah保护系统没有被拖垮;升级完成,CPU恢复后,系统服务立即恢复。

We are hiring

欢迎加入淘宝基础平台基础服务团队,团队成员大牛云集,有阿里移动中间件的创始人员、Dubbo核心成员、更有一群热爱技术,期望用技术推动业务的小伙伴。

淘宝基础平台基础服务团队,推进淘系(淘宝、天猫等)架构升级(代号Tango),致力于为淘系、整个集团提供基础核心能力、产品与解决方案:

  • 业务高可用的解决方案与核心能力(应用高可用:为业务提供自适应的限流、隔离与熔断的柔性高可用解决方案,站点高可用:故障自愈、多机房与异地容灾与快速切流恢复)

  • 新一代的业务研发模式FaaS(一站式函数研发Gaia平台)

  • 下一代网络协议QUIC实现与落地

  • 移动中间件(API网关MTop、接入层AServer、消息/推送、配置中心等等)

期待一起参与加入淘系基础平台的建设~

简历投递至????:

哲良 [email protected] (基础平台基础服务-基础架构Leader)

END

更多好文

点击下方图片即可阅读

淘宝业务稳定性保障实战——诺亚(Noah)自适应流控_第13张图片

双11备战“核武器”,白天态全链路压测技术大揭秘!

淘宝业务稳定性保障实战——诺亚(Noah)自适应流控_第14张图片

淘宝如何保障业务稳定性——诺亚(Noah)自适应流控

你可能感兴趣的:(淘宝业务稳定性保障实战——诺亚(Noah)自适应流控)