天天看点

阿里管控系统靠什么扛住全球最大规模的流量洪峰?

阿里管控系统靠什么扛住全球最大规模的流量洪峰?

双 11 不仅是一场全球消费者的狂欢,也是对中国互联网技术体系的实力检验。一下子几千万人涌进来买买买,这种真实的商业场景全世界一年也只有一次。全球最大的支付平台之一, visa,在实验室取得的测试数据是 5.6w 笔每秒;而双十一这天,支付宝在实战中达到了每秒钟 8.6 万笔,交易订单的创建量更是达到了每秒钟 14 万笔,刷新了网络交易峰值的世界纪录。 从 11 月 10 号深夜日常的交易数量陡然飙升到每秒钟提交 14 万笔订单,这中间经历了一个怎么样的过程?突然爆发的流量洪峰对业务链路的冲击又有多大?除此之外,线上复杂性也是惊人的,仅仅一个购买动作,就包含从关键字搜索,挑选商品,再到购物车结算,优惠抵扣,生成订单,支付宝付款等一系列的流程,涉及上百个应用,链路上的任何一个”零件”出了问题,都有可能导致交易的失败。

其实我们的高可用架构团队是由多个系统组成的,例如强弱依赖,弹性等,他们一定是互相作战的。这个系列会主要介绍和双十一比较密切的阿里管控系统。 这个体系主要是由下面几个系统组成的: 限流,降级以及流量调度,预案开关。

这篇文章里面,我们先来看一下限流。

<a></a>

双十一从一开始,就会有这样的自带属性, 商家会提前1个星期甚至1个月,把自己参加活动的商品放出来;剁手党呢,也会提早把这些商品挑选出来放在购物车里面,但是他们一定是屏住不买,一直到0点0分才会开买。为什么?提前一秒买没有折扣,推迟一秒买可能商品就抢光了。

这个属性,换算成工程师的语言来说,就是前一秒的qps(request per second,每秒到达的请求量)非常低,但是下一秒请求量就会飙高。我们再用数据来看一下双十一当天的流量: 创建订单的峰值时14w笔,天猫天猫移动端销售金额突破1亿仅用了75秒,销售金额破百亿仅用了38分钟…这些数据,只是当天流量的冰山一角。

如果这些流量没有抗住,会出现什么呢?想象一下这样的场景,流量大,承载这些流量的机器负载会增高,如果这个应用的一两台机器没有率先扛不住了,那么本来应该这些机器承载的流量就间接由其他的机器承担了。本来这些机器就处于一种临界状态,这样雪上加霜,那么这些机器也挂了。就这样1变2,2变4,4变8,整个集群就如同雪崩一样,都挂了。这样谁也买不了东西了。

所以我们必须要有限流.

每一年双十一0点0分的流量,对我们来说是宝贵的数据。有了这些数据,我们根据大数据对明年的双十一的峰值进行评估,容量规划。这是第一步。

第二步,就是梳理限流的用户体验了。一般来说,是不同的场景有不同的限流体验。比如说,双十一零点,用户可能看到这个页面,提示用户等待并且重试,从而达到限流的效果

阿里管控系统靠什么扛住全球最大规模的流量洪峰?

刚刚我们描述的情形,其实就属于用户洪峰。对于这种洪峰,我们需要考虑的因素是:

a) 允许访问的速率

b) 系统承受的最大洪峰

c) 洪峰爆发的间隔时间

对于这种流量,我们的处理是: 令牌桶限流

阿里管控系统靠什么扛住全球最大规模的流量洪峰?

a) 允许访问的速率:令牌桶发放的速度 r

b) 系统承受的最大洪峰:当令牌桶满的时候,洪峰到达,这个时候应用会承受最大的qps冲击 桶的容量+该秒令牌桶发放的速度r

c) 洪峰爆发的间隔时间,也就是说,什么时候令牌桶会再次满, m&lt;r,否则洪峰不会到来

除了0点0分的这种流量洪峰,还有系统之间的回调引起的洪峰。想象一下这样的场景,物流系统为了处理发货信息,会隔一段时间调用交易系统来获取交易信息。为了提高效率,它每次批量查询交易系统的数据。这样,对交易系统也带来了流量的冲击。如果对这种回调不加以限制,那么可能交易系统忙于处理这种回调洪峰,对用户洪峰会疏于处理。

对于这种洪峰,有三种特色:

a) 有间隔频率

b) 每次调用量大

c) 允许有延迟

对于这种洪峰,我们的处理方式是使用漏桶算法

阿里管控系统靠什么扛住全球最大规模的流量洪峰?

这种算法也类似一个水桶,随机的往水桶里面放水,但是以固定的速度往下漏水。和上一种的算法不一样,主要是塑形。达到的效果是放给应用的流量,永远是固定的。

那么回答这个场景的问题,一个请求最迟延迟多久得到处理: τ/(𝑇−𝜎) τ是桶的容量,t是请求到来的速度,𝜎是输出的速率

其实上面两种场景,只是限流场景的非常少的部分。对于不同的场景,需要使用不同的算法来进行限流。

例如,根据特定资源,比方说数据库,缓存的运行情况来限流,或者根据线程池的使用情况来限流等等;从保护自己的服务水位的角度出发来限流,从保护自身应用不被不可靠的下游应用托斯的角度来划分,等等。

不同的场景,不同的目的,限流的方式一定是不一样的。

限流框架主要由下面几个部分组成

监控模块

决策模块

规则变更模块

限流模块

监控模块主要用于采集系统的运行状况。有了这些数据,才能对外进行处理。决策模块主要是用于决定什么场景用什么限流方式,例如对待用户洪峰,我们应该用令牌桶算法;对待系统回调,我们应该用漏桶算法。另外,做了决策之后,这些决策要能够快速的推送到各个不同的机器。限流模块则是对超过预期的请求的处理方式,可以简单的限流,也可以排队等。

处理的流程:

阿里管控系统靠什么扛住全球最大规模的流量洪峰?

限流不是一招鲜的,但是限流的原则都是一样的:

不同的场景不同的考虑因素

系统必须能够迅速的对线上的情况做出快速响应

对超出预期的流量的处理方式要根据不同的场景来处理

另外,限流不是一个单独作战的系统,它需要结合其他的系统才能发挥更大的作用,例如强弱依赖,例如容量规划,等等。

我们会在下一篇文章里面介绍其他的系统。

最后给耐心看到这里的读者一个彩蛋,

这张图是我们部门在2015年双十一战斗结束的黎明的合影。请找出其中的若干个技术大牛!说不定你心仪已久的大牛已经在你眼前了,联系我们来验证你的猜想是否正确!

阿里管控系统靠什么扛住全球最大规模的流量洪峰?

欢迎加入我们的团队,请联系: shutong.dy[at]alibaba-inc.com 叔同

继续阅读