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

作者|熊政(八风)

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

导读

---

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

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

---

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

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

• 处理时消耗资源；

• 资源过载时，引起业务逻辑（服务）可用性问题。
  

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自适应流控右侧有一小段接受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劣化与波动情况

正常服务时，服务的RT 130ms 左右。大流量时：

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

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

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

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

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

正常服务时，300QPS。大流量时：

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

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

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

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

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

Load 限流方案，系统会被压垮：

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

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

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

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

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

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

简历投递至????：

哲良 ding.lid@alibaba-inc.com （基础平台基础服务-基础架构Leader）

END

更多好文

点击下方图片即可阅读

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

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