网站后台管理系统进度,图片外链,需要个网站,专门做娱乐场所的设计网站作者|哲良、八风、泽彬 出品|阿里巴巴新零售淘系技术部
诺亚(Noah) 自适应流控解决方案 基于自动控制算法#xff0c;解决了人工限流配置疏漏或过时的痛点#xff0c;大幅提升应用抵抗流量冲击的能力。在刚过去的双11中#xff0c;诺亚(Noah)保障了大量业务应用系统#x… 作者|哲良、八风、泽彬 出品|阿里巴巴新零售淘系技术部
诺亚(Noah) 自适应流控解决方案 基于自动控制算法解决了人工限流配置疏漏或过时的痛点大幅提升应用抵抗流量冲击的能力。在刚过去的双11中诺亚(Noah)保障了大量业务应用系统有超过 15K 的容器大规模部署稳定性上最高可提升 20 倍于业务负载流量的上限 QPS 最高可提升 100% 的资源利用率同时优化了体验与效率。提升淘系(及更多BU)的稳定性底盘成为应用稳定性保障的核心能力推动了业界在大型分布式在线业务系统的高可用/稳定性保障的进展。
背景
随着业务的不断发展应用数量、拓扑依赖与复杂性都在持续增长流量模型的有效预测也变得更加困难。系统与流量的不确定性都会导致系统容量评估疏漏或评估过时。这些情况在双11、春晚等大型复杂活动中会更加的突显。
面向流量的「意义」
流量会受到业务的影响而发生强变化的这种变化是不确定的且在频繁发生的。
应对这种不确定性需要基础架构有可靠的、自适应的方式能够
实时接受与感知变化
作出保护响应来抵御变化自适应的、柔性的实施系统/架构
然后是弹性针对基础资源做实时调节
这样才能具备有效的抵抗力、适应力活着是前提有了这个前提才有机会将基础资源驱动起来弹性而业务无需耗费心力去关注这种不确定性带来的业务可用性风险。
关于高可用的重新思考
业界在讨论高可用时主要说的是资源失效的对应方式比如通过应用集群、主备、热切换等应对单机失效通过单元化架构、异地多活等应对单机房/地域失效。 从上面对资源失效的问题与对策可以看出高可用所要解决的核心问题是保证服务不挂准确的说是要大大降低服务挂掉的概率。
到了今天我们的应用架构我们的可用性痛点问题是什么呢对于你自己开发的应用或听到某某服务挂了时你会担心或者想到什么在可用性方面相信更多的回答会是『服务压跨了』典型的是问题场景是『大流量、突发流量』下比如直播场景中主播一声吼后端流量飙升社交媒体场景中明星官宣结婚带来热点流量暴涨电商运营场景中秒杀活动大流量脉冲互动玩法场景中持续不断发布互动活动一个新的活动导致系统整体可支撑的QPS可能下降很多。这些场景与问题在日常应用开发和服务保障过程中应该是深有痛点吧 :)
在应用架构上业界对面向流量的可用性不如像面向资源一样得到充分的关注、有着丰富成熟的思路和广泛有效的实践我们有意于改变 面向流量的可用性 这个主题的现状更多的直面问题、探索思路、实践推进。 传统方案有什么问题
面向流量的可用性现有的应对方式是静态限流。 传统的针对 QPS 限制的静态限流方法的问题
流量/请求
依赖 请求模型的准确评估即测试流量的请求大小与实际需保持一致。 热点流量如热点用户被频繁访问/爆冷商品等。运营导致用户动线走了较重的逻辑分支。
依赖 来的流量的准确预估。 但我们要承认流量一定无法准确被评估系统会被摸死即拒绝操作导致的过载。
业务代码逻辑
依赖 测试之后系统自身和其下游依赖的逻辑不变性能需保持一致。 但是业务总是在演进除非全网封网否则限流阈值一上线就已经过时了。
资源
依赖 各台机器性能完全一致且稳定不变。
机器型号不同处理能力是不可能做到完全一致的。
虚拟化/容器化之间有影响你无法控制你的邻居会做什么。
流程
依赖 事先人工准确执行了评估过程 但人总是靠不住的只要人工来执行就一定会疏漏、出错。
另外对于长尾应用/非核心应用支持力度没有保障人力资源总是有限的。
传统方法无法解决人工评估过时导致的流量与容量不一致的问题我们需要一种能够实时评估系统容量并就地对流量进行控制的解决方案。
诺亚(Noah)自适应流控
面对系统稳定性问题诺亚(Noah) 自适应流控解决方案采用不同于业界传统的针对QPS限制的静态限流方法首次以自动控制算法为核心手段提供自适应流控解决方案解决了限流配置过时的痛点大幅提升应用抵抗流量冲击的能力极度简化了相关配置工作同时在系统资源利用率、用户体验、运维效率等方面均有大幅优化提升。 诺亚(Noah)自适应流控解决方案
在绝大部分情况下CPU利用率作为资源供给的主要信号是最为直接的。诺亚(Noah) 自适应流控解决方案即是以自动控制CPU资源为核心方法的其具备了一下3点优势
在系统稳定性控制效果方面表现为精准和有效的控制并具备很强的可解释性。
没有提前的人工评估便没有提前评估的过时与人工评估的疏漏和错误。
应用场景更为广泛不受异步场景约束可同时使用于同步和异步场景。
诺亚(Noah) 自适应流控解决方案能够实时自动评估 QPS 在技术方案上使用自适应性来解决业务流量的不确定性。
业务落地
作为淘宝应用架构升级代号TangoTaobao Architecture Next GeneratiOn在稳定性上的核心产品诺亚(Noah)在刚刚过去的双11大促过程中保障大量业务应用系统有超过15K的容器大规模部署涉及淘宝、天猫、聚划算、盒马、猫超、优酷等等众多业务。提升系统稳定性、提升资源利用率、优化体验与效率提升了淘系(及更多BU)的稳定性底盘成为应用稳定性保障的核心能力推动了业界在大型分布式在线业务系统的高可用/稳定性保障的进展。
诺亚(Noah) 自适应流控解决方案目前已上线超过9个月在线上实战和全链路压测中诺亚保护了大促会场、直播、导购等等核心业务场景应用系统在出现容量缺失30%或近20倍超大流量脉冲场景下仍保持稳定运行。
诺亚(Noah)自适应流控的效果收益
可用性提升
压垮QPS上限最高可提升 20倍 于业务负载流量。
在大流量压力下降后1秒 快速恢复服务。
大流量压力下仅需直接扩容机器 一步即可无需紧急调整限流。
用户体验的优化
应用在高负载情况下服务成功率最高可提升 2.7倍同时响应时间维持正常水平不劣化。
成本的优化
资源利用率最高可提升 100%去除为了稳定性/不确定性而留的资源冗余
效率提升
全链路压测/性能压测更顺畅。无需人工限流阈值设置避免人工评估错误导致系统被压垮后需要大量调整时间。 自适应流控的实际控制效果在流量飙升/大流量压力时CPU稳定控制在阈值且服务RT正常
诺亚后续的发展
目前诺亚(Noah) 自适应流控解决方案保障了大量业务应用系统提升稳定性、提升资源利用率、优化体验与效率提升淘系(及更多BU)的稳定性底盘成为应用稳定性保障的核心能力推动了业界在大型分布式在线业务系统的高可用/稳定性保障的进展。
对未来更体系化建设的几点展望
自适应能力由限流拓展到隔离/熔断等更多稳定性能力如
自适应线程资源隔离
自适应服务比例
自适应服务熔断
由单机的自适应限流拓展到链路级尤其是客户端流量入口接入层
与接入层协同让入口流量与应用的处理容量自适应匹配
确定性地保障面向流量的高可用
自适应控制流量拓展到自适应伸缩容
流量控制与处理资源控制伸缩容协同
无论是流量的控制还是资源的控制都是为了让处理流量与资源容量匹配
保障系统不过载提升稳定性与业务请求的成功率
原文链接 本文为云栖社区原创内容未经允许不得转载。
