【2013双十一技术回顾】网购狂欢节背后的技术阅兵

2013年双十一技术回顾特辑

编者注

双十一已经进入紧张的倒计时啦，你是否正在精心挑选今年双十一的宝贝？小编也为程序员同学们精选了两篇2013年双十一技术文章精华，与大家一起回顾过去的成绩，期待即将到来的辉煌。

本系列文章原载与2014年一月刊《程序员》杂志。

网购狂欢节背后的
技术阅兵

庄卓然/南天

摘要：2013年是阿里双11的第五个年头，当天天猫和淘宝单日成交350.19亿，网站PV过百亿，令人倾慕不已。然而，在疯狂的业务数据背后，无疑是对阿里技术团队的一次整体大阅兵。本文将全面剖析双11带来的技术挑战及应对思路。

从光棍节到网购狂欢节

2013年是双11的第五个年头，从2009年的“光棍节”到现在的“网购狂欢节”，单单是名字上的变化，大家就能从中感受到业务规模发生的转变。

2013年双11，天猫和淘宝单日成交额达到350.19亿元，网站PV过百亿，成就了14个销售过亿的商家。其中，有76%的商家处理工作是在聚石塔云计算平台上完成的，并且无一漏单、无一故障。

支付宝实现成功支付1.88亿笔，再次刷新了2012年同期1.0580亿笔的全球记录，最高每分钟支付79万笔。

手机淘宝整体支付宝成交额为53.5亿元，是2012年的5.6倍（9.6亿元）；单日活跃用户达1.27亿；手机淘宝单日成交笔数达3590万笔，交易笔数占整体的21%。

天猫双11共产生快递包裹1.52亿件，仅双11当天，全国各大快递企业共处理6000多万件包裹，是2012年双11最高峰的1.7倍。

在疯狂的业务数据背后，是阿里技术团队的一次整体大阅兵，从天猫、淘宝到支付宝，从PC到无线，从研发到运维保障，各个环节都面临着巨大的挑战。

双11业务生态

在开始介绍这些挑战之前，我们先用一张图来看一看，作为消费者，你在2013年的双11大促中都会经历哪些业务过程，如图1所示。

图1 双11大促时的业务过程

首先，你会通过各种终端（PC、手机、平板）访问淘宝、天猫、聚划算的导购市场，丰富多样的导购产品会帮助你发现和挑选自己心仪的商品。大数据的基础平台支撑了大量有价值的数据应用，以保证你在这个环节的购物体验。稳定的交易平台确保了优惠价格的准确计算、库存的及时扣减和担保交易的订单有效生成。这时，你就可以通过支付宝安全放心地进行支付宝余额或者网上银行支付，满心欢喜地等待包裹的送达。

这时就开始轮到面向商家的系统忙碌起来了。聚石塔提供的云推送功能在第一时间将交易订单同步到部署在聚石塔云工作平台上的商家ERP、WMS、CRM软件中，并且为这部分软件提供了动态弹性扩容的能力和安全方面的有效保护，以便大商家在大量订单面前，可以像日常情况一样，快速组织商品出库和发货，而不用额外担心自己软件的处理能力。

最后出场的是菜鸟网络打造的雷达预警系统，通过大数据的力量，对商家的备货、消费者购买行为、物流服务能力进行预测，并与国家气象局、交通部实时发布的天气、道路情况进行同步运算，将未来半天至七天的预测结果反馈到13家快递公司，以便快递公司提前调配运力。最终，所有的包裹得以第一时间送到消费者的手中。

挑战和技术准备

业务跨数量级的快速发展对整体架构带来了新挑战

经历了过去几年“去IOE”（IBM小型机、Oracle、EMC高端存储）整体架构改造，整个阿里集团建立了基于中间件、PC Server的轻量级分布式SOA架构，保证了服务器、数据库、网络、机房各个层面无单点，可以以较小的成本支持水平扩展，提升网站的负载能力。但随着这几年双11业务的飞速增长，PV、同时在线用户数、峰值交易和峰值支付等核心指标都开始跨越到新的数量级，架构在更高负载能力要求下的一些缺陷开始暴露出来。

• 第一，大规模访问请求带来的机房网络瓶颈。

双11当天有数亿用户访问天猫和淘宝的系统，高峰期甚至有数千万人同时在线。以天猫的“商品详情”页面为例，集群峰值QPS达到了十万以上的量级，是平时峰值QPS的数十倍。这样的突发性流量增长，使得机房的网络容量面临着巨大压力。如何能够利用合理的成本应对瞬间飙高所带来的网络压力，确保活动完整周期内用户响应时间的稳定性，以及局部出现问题时的高可用性，成了首先需要面对的问题。

着眼于未来，从2011年起，我们就开始了对浏览型的应用进行新的架构改造。历经页面细粒度的动静分离、统一缓存接入、CDN静态化三个阶段。最终，将更新频率不高的内容伪静态化直接缓存到CDN，通过统一的秒级失效机制控制缓存的更新操作，让绝大多数内容请求不需要回流到主机房，直接在用户最近的CDN节点就能够完成。这种方式一方面极大地缓解了主机房网络的压力，另一方面也优化了用户页面的响应时间。徐昭的《天猫浏览型应用的CDN静态化架构演变》将带大家更深入地了解我们是如何经历这一过程的。

• 第二，超大规模系统如何继续保持在不同层面上的水平伸缩性。

首先，服务器需求的增多，导致未来单一地区的IDC资源已无法满足容量增长的需求，机房供电能力成为短期内无法逾越的瓶颈。其次，简单地横向扩展IDC机房，机房之间的网络流量又成为了新的瓶颈。多机房的应用、缓存、数据库等访问的相互穿透，也加剧着跨机房的流量增长。最后，核心服务集群的应用服务器的规模增长，使对应的数据库连接数成为了瓶颈。每增加一台数据库服务器，对应的应用服务器都需要连接上来，数据库的连接数马上就不够分配了。也就是说，在今天的业务规模下，我们无法继续针对核心服务的数据库层再做横向的水平扩展了。

为了解决以上问题，2013年双11我们尝试了新的逻辑机房的架构方案，将数据水平拆分（Sharding）的思路向上提到接入层。以支付宝为例，先将完成某一特定业务需要的系统、核心服务、数据库组合抽象成一个业务单元（Zone）的概念，业务单元从应用服务器、缓存到数据库可以独立封闭运行。然后，从入口处根据用户请求路由到不同的逻辑业务单元，实现了单元级别的可伸缩性。不再依赖同城IDC，让交易、支付这样复杂的业务单元具备了大规模跨地域部署的能力。胡喜的《支付宝的架构变迁》会有更加深入和全面的介绍。

• 第三，如何更大程度地“压榨”单服务器的系统资源。

虚拟化技术已作为各大网站提升物理机资源利用率的基础技术。以天猫和淘宝网为例，2010年我们引入Xen虚拟化技术，1台物理机装3个虚拟机，一定程度上降低了成本。但随着机器规模的快速增长，我们发现其中1/3的虚拟机的Peak load<0.5，这意味着我们的运维成本还是不够低。主要有以下几方面原因：

1. 单台物理机上跑的应用不够多；

2. 分给应用的机型及机器数是静态的；

3. 集群的资源利用率不均衡。

为了最大化物理机的资源性能，从2012年开始，我们大规模地应用了新的基于LXC的虚拟化方案，成功地在每台物理机（16Core/48GB）运行了12个应用实例，物理机的load提升到2~10。这对大促时期的成本控制非常有帮助，也为内部私有云的完整构建，摸索了一条可行的路径。

消费者对用户体验有了更高的要求

• 千人千面的购物体验

有一个很现实的问题摆在了我们面前：大促当天有几亿消费者会来到我们的网站，在上百万商家和过亿商品里面挑选自己心仪的宝贝。光靠运营人肉制作的活动页面和消费者的主动搜索已远远不可能满足需求。因此，需要在产品上转变思路，营造从以业务为中心到以用户为中心的大促体验。双11应该是面向消费者的“我的双11”，而不是“天猫的双11”。

基于此，2013年的双11大促中大面积应用了个性化算法，从PC到无线，从“会场”到“详情”，真正意义上为消费者打造了一个“我的双11”。从最终效果来看，2013年双11的用户购买转化率提高了10个百分点。张奇会在《个性化技术在双11的应用》中介绍在个性化推荐系统架构、机器学习算法应用和算法的快速评测方面的思考。

• 多终端的业务一致性

移动智能终端的快速崛起，让更多的消费者可以随时随地访问天猫和淘宝，但也让我们开始深入地思考，在业务快速发展的前提下，如何在不同终端上快速提供本质相同的服务。2013年我们首次在预热期的大型活动中尝试了基于Canvas的Web App解决方案，极大程度地提升了开发效率。天猫前端团队的鄢学鹍会在《双11的前端实践》一文中分享Mobile First的理念是如何在双11中实践的。

稳定性的极致要求

• 容量预估、依赖治理、监控

这一环节是历年双11技术成功与否的关键环节。中间件团队的《中间件技术的双11实践》除了会介绍在SOA架构体系中扮演重要角色的中间件产品之外，也会就容量预估、依赖治理和监控的双11实践做精彩介绍。

• 业务降级、限流预案

从2010年双11开始，每年都会针对性地准备一些技术预案，在流量超出预期时做好限流保护，在局部系统处理能力出现瓶颈时进行优雅降级，以提升整体的吞吐率，保证核心业务的正常运行。

2013年，我们在技术环节准备了2000多套应急预案，大到遭受骇客攻击、各类业务应急动作，小到服务器机房空调发生故障，均有详细预案。不仅各服务器机房，甚至西溪园区双11大促指挥办公现场都准备了柴油发电机。此外，2013年针对双11进行了上百次的内部演习，其中全网大规模演习就进行了10余次，以确保每一个预案的有效性。

• 全链路压测

压力测试对于评估网站性能的重要性是不言而喻的，但无论是线下模拟的单一集群压测，还是线上引流压测，都只能暴露一些基本的单点问题。对于双11当天高峰期的真实压力模拟，这两种传统的压力测试方式还存在着巨大偏差。

首先是业务处理链路的复杂性，对于像天猫这样一个分布式处理平台，一笔交易的创建会涉及多个应用集群的处理，在能力评估时也应该考虑的是一个处理链路而不仅仅是单一应用集群的处理能力。其次是应用之外的风险点，像网络、数据库等，很难在传统压测中体现出来。

为了精确评估核心交易集群中各个环节的能力瓶颈，2013年我们实现了一套新的全链路压测评估体系。通过线上真实用户数据与人为测试数据相结合的方式，首次成功地在生产环境中模拟出相对真实的超大规模访问流量，将前端系统、网络、数据库等一整套系统环境完整地纳入压测范围，贴近实际的应用场景，为评估淘宝和天猫交易核心链路的实际承载能力提供有说服力的数据依据。这一方面可以验证交易核心链路上各种限流和预案的准确性，另一方面也可以充分暴露全链路上的各种瓶颈和隐藏的风险点，让压力测试的工作真正落实到了确定性的层面上。

基础运维能力提升的预研

在支撑好现有业务的同时，如何将基础运维能力（高稳定性、弹性调度、低能耗、快速交付等）提升到新的量级，成了阿里技术团队未来面临的新挑战。为了迎接这方面的挑战，2013年双11我们也小范围做了一些面向未来的基础运维预研工作。

首先，可以预见的是，随着业务的不断发展，阿里会有越来越多IDC布点。虽然逻辑机房的方案已能解决交易支付环节场景下的跨机房调用问题，但随着云计算的推广，我们依然面临着大量跨机房调用的场景。现阶段，交换机的网络路由主要是基于IP做简单识别，并不会通过识别应用类型提供智能调度。当大规模出现多个IDC时，跨机房的用户体验问题会越来越成为瓶颈。为了解决这一问题，我们2013年在交换机的OS层面做了大量自主研发工作，定制自主的交换机OS，实现软件定义网络（SDN），对管控和成本两个层面都有较大的改进。庞俊英的《阿里的SDN实践》将简单介绍我们如何让应用流量通过SDN识别出来，从而实现不同流量的长途链路和短途链路调度。

其次，在未来的3~5年，阿里的服务器将扩大到几十万甚至百万级的规模，如果延续以前按服务器进行交付的模式，交付速度和能耗都会很快出现瓶颈。因此，我们2013年尝试了整机架服务器解决方案，通过标准化、流程化、定制化，解耦各个交付环节在IDC现场部署的时间串行关系，提升交付的质量和效率。除此之外，其中例如统一机架Backbone模块这样的设计，将整体的耗电量降低了接近10%。放在百万级服务器的规模下，无疑会节省一笔极大的开销。武鹏的《阿里整机架服务器解决方案》会展示我们在低能耗、快速交付上的思考和方案。

经验小结

对于技术人员而言，双11绝对是一次奇幻体验，在这里有丰富的场景可以实现个人技术上的奇思妙想，同时也经历着最极致的技术考验。经历了5年双11，我来小结一下技术准备上的一些经验心得。

提前明确架构目标。架构和基础技术的调整往往带来应用系统的伤筋动骨，前面介绍的一些大架构改造，周期往往需要2~3年，试错成本非常高。因此对于架构师和技术核心决策者而言，要有足够的前瞻性，在选型设计上一定从全局发展和核心问题出发，准确定位、明确目标，才能统一团队的整体方向。

不过度追求过程中的完美。我们在内部总把系统架构的过程类比为建造水坝——上下游级联，同时兼顾对于全局生态的影响。但落实到实施层面才是挑战的开始，大家总是会倾向于考虑是否优雅完美，从而让方案的复杂度不断提升。架构师需要能够兼顾成本、资源、时间等各方面的因素，敢于做取舍，勇于舍弃一些收效甚微的优化。到准备后期更是如此，发生问题不可怕，可怕的是解决问题的时候又引入新问题。没有100%完美的方案，能满足业务现阶段发展需要的方案就是好方案。

细节决定成败。分布式系统的好处在于松耦合、灵活性和可快速扩展，但同时也带来了一系列麻烦，包括数据的一致性、分布式事务、各种应用在服务层的数据相互干扰等。在大促这样的峰值压力下，这些小问题都会被无限放大。因此，前期准备过程中要谨记不能放过任何微小的细节，侥幸心理更是万万要不得，担心出问题的角落往往一定会出问题，最没问题的地方或许会是风险最大的地方。另外，尽可能工具化一切人为操作环节，在架构上做好约束，同时时刻确保留有“Plan B”，只有这样才能够确保对最终结果有把握。

最后，350亿绝对不是终点，数字本身并无特殊意义，也不会是我们的终极需求，阿里“让天下没有难做的生意”的使命还在继续。用技术的力量重构整个电商生态，改善更多人的生活，还有很多路要走，让我们一起共同期待更多的技术奇迹。

MTT是手机淘宝技术团队（Mobile Taobao Tech team）的英文缩写，欢迎关注手机淘宝技术团队，一起交流分享无线技术，共创移动开发无限未来！扫描微信二维码关注我们！我们将分享更多的双十一技术细节！