作者|熊政(八风)
出品|阿里巴巴新零售淘系技术部
导读
诺亚(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有效服务。
限流方案负载时，RT崩溃，无有效服务，服务成功率几乎为0
Noah 自适应流控方案负载时，仍能提供有效服务，为正常服务时的90%
▐ Load 限流系统被压垮的典型 Case
Load 限流方案，系统会被压垮：
- 300QPS 调速到 1800QPS，接受QPS 1087。
- 完成调速至1800QPS，全量超时，错误率100%；系统已被压垮，服务端口、ssh端口 均链接不上。
- 成功请求的avgRT在1s以上，如果业务超时设置为1s，可以认为此刻几乎没有请求能够正常服务了，服务成功请求 QPS 跌0。
- 之后系统完全无响应，直到半个小时之后，系统重启前，服务端口、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）
关注「淘系技术」微信公众号，一个有温度有内容的技术社区~
