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

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

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

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

限流的必要性

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

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

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

所以我们必须要有限流.

如何限流

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

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

限流场景

1. 用户洪峰

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

a) 允许访问的速率
b) 系统承受的最大洪峰
c) 洪峰爆发的间隔时间

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

a) 允许访问的速率：令牌桶发放的速度 r
b) 系统承受的最大洪峰：当令牌桶满的时候，洪峰到达，这个时候应用会承受最大的qps冲击 桶的容量+该秒令牌桶发放的速度r
c) 洪峰爆发的间隔时间，也就是说，什么时候令牌桶会再次满, m<r，否则洪峰不会到来

2. 回调洪峰

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

对于这种洪峰，有三种特色:
a) 有间隔频率
b) 每次调用量大
c) 允许有延迟

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

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

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

3. 其他场景

其实上面两种场景，只是限流场景的非常少的部分。对于不同的场景，需要使用不同的算法来进行限流。
例如，根据特定资源，比方说数据库，缓存的运行情况来限流，或者根据线程池的使用情况来限流等等；从保护自己的服务水位的角度出发来限流，从保护自身应用不被不可靠的下游应用托斯的角度来划分，等等。
不同的场景，不同的目的，限流的方式一定是不一样的。

限流框架

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

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

处理的流程:

总结

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

1. 不同的场景不同的考虑因素
2. 系统必须能够迅速的对线上的情况做出快速响应
3. 对超出预期的流量的处理方式要根据不同的场景来处理

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

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

联系我们

最后给耐心看到这里的读者一个彩蛋，
这张图是我们部门在2015年双十一战斗结束的黎明的合影。请找出其中的若干个技术大牛！说不定你心仪已久的大牛已经在你眼前了，联系我们来验证你的猜想是否正确！

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

企业级互联网架构Aliware，让您的业务能力云化：https://www.aliyun.com/aliware