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

简介: 诺亚(Noah) 自适应流控解决方案 基于自动控制算法,解决了人工限流配置疏漏或过时的痛点,大幅提升应用抵抗流量冲击的能力。在刚过去的双11中,诺亚(Noah)保障了大量业务应用系统,有超过 15K 的容器大规模部署;稳定性上最高可提升 20 倍于业务负载流量的上限 QPS ;最高可提升 100% 的资源利用率;同时优化了体验与效率。提升淘系(及更多BU)的稳定性底盘,成为应用稳定性保障的核心能力,推动了业界在大型分布式在线业务系统的高可用/稳定性保障的进展。

image.png
作者|哲良、八风、泽彬
出品|阿里巴巴新零售淘系技术部

诺亚(Noah) 自适应流控解决方案 基于自动控制算法,解决了人工限流配置疏漏或过时的痛点,大幅提升应用抵抗流量冲击的能力。在刚过去的双11中,诺亚(Noah)保障了大量业务应用系统,有超过 15K 的容器大规模部署;稳定性上最高可提升 20 倍于业务负载流量的上限 QPS ;最高可提升 100% 的资源利用率;同时优化了体验与效率。提升淘系(及更多BU)的稳定性底盘,成为应用稳定性保障的核心能力,推动了业界在大型分布式在线业务系统的高可用/稳定性保障的进展。

背景

随着业务的不断发展,应用数量、拓扑依赖与复杂性都在持续增长,流量模型的有效预测也变得更加困难。系统与流量的不确定性都会导致系统容量评估疏漏或评估过时。这些情况在双11、春晚等大型复杂活动中会更加的突显。

面向流量的「意义」

流量会受到业务的影响而发生强变化的,这种变化是不确定的且在频繁发生的。

应对这种不确定性需要基础架构有可靠的、自适应的方式,能够

实时接受与感知变化

作出保护响应来抵御变化,自适应的、柔性的实施系统/架构

然后是弹性,针对基础资源做实时调节

这样才能具备有效的抵抗力、适应力,活着是前提,有了这个前提,才有机会将基础资源驱动起来(弹性),而业务无需耗费心力去关注这种不确定性带来的业务可用性风险。

关于高可用的重新思考

业界在讨论高可用时,主要说的是资源失效的对应方式,比如通过应用集群、主备、热切换等应对单机失效;通过单元化架构、异地多活等应对单机房/地域失效。

image.png

从上面对资源失效的问题与对策可以看出,高可用所要解决的核心问题是保证服务不挂,准确的说是要大大降低服务挂掉的概率。

到了今天我们的应用架构,我们的可用性痛点问题是什么呢?对于你自己开发的应用,或听到某某服务挂了时,你会担心或者想到什么?在可用性方面,相信更多的回答会是『服务压跨了』,典型的是问题场景是『大流量、突发流量』下,比如:直播场景中主播一声吼,后端流量飙升;社交媒体场景中明星官宣结婚,带来热点流量暴涨;电商运营场景中,秒杀活动大流量脉冲;互动玩法场景中持续不断发布互动活动,一个新的活动导致系统整体可支撑的QPS可能下降很多。这些场景与问题在日常应用开发和服务保障过程中,应该是深有痛点吧 :)

在应用架构上,业界对面向流量的可用性,不如像面向资源一样得到充分的关注、有着丰富成熟的思路和广泛有效的实践,我们有意于改变 面向流量的可用性 这个主题的现状,更多的直面问题、探索思路、实践推进。

image.png

传统方案有什么问题?

面向流量的可用性现有的应对方式是静态限流。

image.png

传统的针对 QPS 限制的静态限流方法的问题:

  • 流量/请求

依赖 请求模型的准确评估,即测试流量的请求大小与实际需保持一致。
热点流量,如热点用户被频繁访问/爆冷商品等。运营导致用户动线走了较重的逻辑分支。

依赖 来的流量的准确预估。
但我们要承认,流量一定无法准确被评估,系统会被摸死(即拒绝操作导致的过载)。

  • 业务代码逻辑

依赖 测试之后系统自身和其下游依赖的逻辑不变,性能需保持一致。
但是业务总是在演进,除非全网封网,否则限流阈值一上线就已经过时了。

  • 资源

依赖 各台机器性能完全一致且稳定不变。

机器型号不同,处理能力是不可能做到完全一致的。

虚拟化/容器化之间有影响,你无法控制你的邻居会做什么。

  • 流程

依赖 事先人工准确执行了评估过程
但人总是靠不住的,只要人工来执行就一定会疏漏、出错。

另外对于长尾应用/非核心应用,支持力度没有保障,人力资源总是有限的。

传统方法无法解决人工评估过时导致的流量与容量不一致的问题,我们需要一种能够实时评估系统容量,并就地对流量进行控制的解决方案。

诺亚(Noah)自适应流控

面对系统稳定性问题,诺亚(Noah) 自适应流控解决方案采用不同于业界传统的针对QPS限制的静态限流方法,首次以自动控制算法为核心手段,提供自适应流控解决方案,解决了限流配置过时的痛点,大幅提升应用抵抗流量冲击的能力,极度简化了相关配置工作,同时在系统资源利用率、用户体验、运维效率等方面均有大幅优化提升。

image.png

诺亚(Noah)自适应流控解决方案

在绝大部分情况下,CPU利用率作为资源供给的主要信号是最为直接的。诺亚(Noah) 自适应流控解决方案即是以自动控制CPU资源为核心方法的,其具备了一下3点优势:

在系统稳定性控制效果方面表现为精准和有效的控制,并具备很强的可解释性。

没有提前的人工评估,便没有提前评估的过时与人工评估的疏漏和错误。

应用场景更为广泛,不受异步场景约束,可同时使用于同步和异步场景。

诺亚(Noah) 自适应流控解决方案能够实时自动评估 QPS ,在技术方案上使用自适应性来解决业务流量的不确定性。

业务落地

作为淘宝应用架构升级(代号Tango:Taobao Architecture Next GeneratiOn)在稳定性上的核心产品,诺亚(Noah)在刚刚过去的双11大促过程中,保障大量业务应用系统,有超过15K的容器大规模部署(涉及淘宝、天猫、聚划算、盒马、猫超、优酷等等众多业务)。提升系统稳定性、提升资源利用率、优化体验与效率,提升了淘系(及更多BU)的稳定性底盘,成为应用稳定性保障的核心能力,推动了业界在大型分布式在线业务系统的高可用/稳定性保障的进展。

诺亚(Noah) 自适应流控解决方案目前已上线超过9个月,在线上实战和全链路压测中,诺亚保护了大促会场、直播、导购等等核心业务场景;应用系统在出现容量缺失30%或近20倍超大流量脉冲场景下仍保持稳定运行。

诺亚(Noah)自适应流控的效果收益:

  • 可用性提升

压垮QPS上限,最高可提升 20倍 于业务负载流量。

在大流量压力下降后,1秒 快速恢复服务。

大流量压力下,仅需直接扩容机器 一步即可,无需紧急调整限流。

  • 用户体验的优化

应用在高负载情况下,服务成功率最高可提升 2.7倍,同时响应时间维持正常水平不劣化。

  • 成本的优化

资源利用率最高可提升 100%(去除为了稳定性/不确定性而留的资源冗余)

  • 效率提升

全链路压测/性能压测更顺畅。无需人工限流阈值设置,避免人工评估错误导致系统被压垮后需要大量调整时间。

image.png

自适应流控的实际控制效果:在流量飙升/大流量压力时,CPU稳定控制在阈值,且服务RT正常

诺亚后续的发展

目前诺亚(Noah) 自适应流控解决方案保障了大量业务应用系统,提升稳定性、提升资源利用率、优化体验与效率,提升淘系(及更多BU)的稳定性底盘,成为应用稳定性保障的核心能力,推动了业界在大型分布式在线业务系统的高可用/稳定性保障的进展。

对未来更体系化建设的几点展望:

  • 自适应能力由限流拓展到隔离/熔断等更多稳定性能力,如

自适应线程资源隔离

自适应服务比例

自适应服务熔断

  • 由单机的自适应限流拓展到链路级,尤其是客户端流量入口接入层

与接入层协同,让入口流量与应用的处理容量自适应匹配

确定性地保障面向流量的高可用

  • 自适应控制流量拓展到自适应伸缩容

流量控制与处理资源控制(伸缩容)协同

无论是流量的控制还是资源的控制,都是为了让处理流量与资源容量匹配

  • 保障系统不过载,提升稳定性与业务请求的成功率

One More Thing

淘系技术部依托淘系丰富的业务形态和海量的用户,我们持续以技术驱动产品和商业创新,不断探索和衍生颠覆型互联网新技术,以更加智能、友好、普惠的科技深度重塑产业和用户体验,打造新商业。我们不断吸引用户增长、机器学习、视觉算法、音视频通信、数字媒体、移动技术、端侧智能等领域全球顶尖专业人才加入,让科技引领面向未来的商业创新和进步。

请投递简历至邮箱:ruoqi.zlj@taobao.com

了解更多职位详情:2684亿成交!每秒订单峰值54.4W!这样的团队你想加入吗?

image.png

相关文章
|
运维 监控 算法
稳定性保障6步走:高可用系统大促作战指南!
年年有大促,大家对于大促稳定性保障这个词都不陌生,业务场景尽管各不相同,“套路”往往殊路同归,全链路压测、容量评估、限流、紧急预案等,来来去去总少不了那么几板斧。跳出这些“套路”,回到问题的本质,我们为什么要按照这些策略来做?除了口口相传的历史经验,我们还能做些什么?又有什么理论依据?
稳定性保障6步走:高可用系统大促作战指南!
|
数据采集 监控 安全
优酷质量保障系列(一)—服务端稳定性保障实践
质量保障贯穿全部研发流程,测试作为质量的构建者和守护者,需要保障的不仅仅是提测后的功能质量,而是整个研发过程的质量和效率。分享优酷通过质量保障建设提升研发效率和质量的实践过程。
795 0
优酷质量保障系列(一)—服务端稳定性保障实践
|
7月前
|
缓存 运维 监控
|
消息中间件 运维 应用服务中间件
5分钟轻松打造应对流量洪峰的稳定商城交易系统实验场景
本实验通过SAE极速部署一个微服务电商商城,同时结合RocketMQ异步解耦、削峰填谷的能力,带大家体验面对流量洪峰仍旧稳定可靠的商城交易系统!
361 0
|
监控 测试技术 UED
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(1)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(1)
303 0
|
域名解析 网络协议 数据可视化
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(2)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(2)
214 0
|
SQL 监控 关系型数据库
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(3)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(3)
206 0
|
编解码 监控 算法
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.2 直播业务稳定性保障——5.2.2 直播业务监控最佳实践(1)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.2 直播业务稳定性保障——5.2.2 直播业务监控最佳实践(1)
141 0
|
存储 编解码 监控
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.2 直播业务稳定性保障——5.2.2 直播业务监控最佳实践(3)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.2 直播业务稳定性保障——5.2.2 直播业务监控最佳实践(3)
138 0
|
监控
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.2 直播业务稳定性保障——5.2.2 直播业务监控最佳实践(2)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.2 直播业务稳定性保障——5.2.2 直播业务监控最佳实践(2)
138 0