淘宝业务稳定性保障实战——诺亚(Noah)自适应流控-阿里云开发者社区

开发者社区> 新零售淘系技术> 正文

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

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

image.png
作者|熊政(八风)
出品|阿里巴巴新零售淘系技术部

导读

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

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

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

  • 流量进入业务逻辑进行处理;
  • 处理时消耗资源;
  • 资源过载时,引起业务逻辑(服务)可用性问题。

image.png

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%。

image.png

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

image.png

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

image.png

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

减压时

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

image.png

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

image.png

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

▐ 系统负载控制

服务的RT劣化与波动情况
正常服务时,服务的RT 130ms 左右。大流量时:

  • Load限流方案 RT崩溃(伴有FGC),系统过载。在本测试场景下,RT平均近 4000ms,是正常RT的30倍,峰值超 6000ms。
  • Noah自适应流控方案 RT保持稳定,系统未过载,如正常服务时的RT。
    在本测试场景下,RT 130ms 左右,完全无劣化。

image.png

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

image.png

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

服务成功 QPS 的劣化与波动情况
正常服务时,300QPS。大流量时:

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

image.png

限流方案负载时,RT崩溃,无有效服务,服务成功率几乎为0

image.png

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

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

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

  1. 300QPS 调速到 1800QPS,接受QPS 1087。
  2. 完成调速至1800QPS,全量超时,错误率100%;系统已被压垮,服务端口、ssh端口 均链接不上。
  3. 成功请求的avgRT在1s以上,如果业务超时设置为1s,可以认为此刻几乎没有请求能够正常服务了,服务成功请求 QPS 跌0。
  4. 之后系统完全无响应,直到半个小时之后,系统重启前,服务端口、ssh 端口 都依然链接不上。

image.png

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

image.png

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、消息/推送、配置中心等等)

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

简历投递至📮:
哲良 ding.lid@alibaba-inc.com (基础平台基础服务-基础架构Leader)

关注「淘系技术」微信公众号,一个有温度有内容的技术社区~

公众号二维码.jpg

版权声明:本文中所有内容均属于阿里云开发者社区所有,任何媒体、网站或个人未经阿里云开发者社区协议授权不得转载、链接、转贴或以其他方式复制发布/发表。申请授权请邮件developerteam@list.alibaba-inc.com,已获得阿里云开发者社区协议授权的媒体、网站,在转载使用时必须注明"稿件来源:阿里云开发者社区,原文作者姓名",违者本社区将依法追究责任。 如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:developer2020@service.aliyun.com 进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

淘系技术部隶旗下包含淘宝技术、天猫技术、农村淘宝技术、闲鱼、iHome等团队和业务,是一支是具有商业和技术双重基因的螺旋体。 我们致力于成为全球最懂商业的技术创新团队,打造消费者和商家一体化的新零售智能商业平台,创新商业赛道。随着新零售业务的持续探索与快速发展,我们不断吸引用户增长、机器学习、视觉算法、音视频通信、数字媒体、端侧智能等领域全球顶尖专业人才加入,让科技引领面向未来的商业创新和进步。欢迎投递简历至ruoqi.zlj@taobao.com

官方博客
淘系开源,欢迎star哟