《尽在双11——阿里巴巴技术演进与超越》全书精华摘录

“双 11”，诞生于杭州，成长于阿里，风行于互联网，成就于新经济，贡献于全世界。

从 2009 年淘宝商城起，双 11 已历经八年。每年的双 11 既是当年的结束，又是走向未来的起点。技术的突破创新，商业模式的更替交互，推动着双 11 迈步向前。

《尽在双11——阿里巴巴技术演进与超越》是迄今唯一由阿里巴巴集团官方出品、全面阐述双 11 八年以来在技术和商业上演进和创新历程的书籍。内容涵盖在双 11 背景下阿里技术架构八年来的演进，如何确保稳定性这条双 11 生命线的安全和可靠，技术和商业交织发展的历程，无线和互动的持续创新与突破，以及对商家的赋能和生态的促进与繁荣。

《尽在双11——阿里巴巴技术演进与超越》主要面向广大互联网技术和商业从业者，内容包括基础设施、云计算、大数据、AR/VR、人工智能、物联网等技术领域的剖析，以及在电商、金融、客服、物流等商业层面的洞察；同时，《尽在双11——阿里巴巴技术演进与超越》也可以作为了解科技与商业最新发展的一个窗口，供科研人员和高校在校师生参考。

《尽在双11——阿里巴巴技术演进与超越》也包含丰富的双 11 发展历程中的故事性片段，生动有趣，可读性强，读者可以在由衷感叹双 11 背后艰辛的演进历程之余，更为透彻地体会到阿里人在技术和商业创新上坚韧不拔、矢志不渝的精神。

目录

序一 IX

序二 X

双11大事年表 XII

引言 XIII

全书目录：

序一 IX

序二 X

双11大事年表 XII

引言 XIII

第1章 阿里技术架构演进 1

双11是阿里技术发展的强大驱动力，双11业务的快速发展造就了阿里具备高度水平伸缩能力、低成本的电商架构体系。这个架构体系是如何一步一步形成的呢？在形成过程中阿里遇到了哪些问题，做了哪些尝试，最终用什么样的思路、方法和技术解决了问题？

1.1 五彩石，电商架构新起点 3

1.2 异地多活，解除单地域部署限制的新型双11扩容方式 9

1.3混合云，利用阿里云弹性大幅降低双11成本 17

1.4 OceanBase，云时代的关系数据库 23

1.5 手机淘宝，移动互联网电商新时代 30

1.6 蚂蚁技术架构演进 36

第2章 稳定，双11的生命线 43

双11最大的困难在于零点峰值的稳定性保障。面对这种世界级的场景、独一无二的挑战，阿里建设了大量高可用技术产品，形成了全链路一体化的解决方案，用更加逼真和自动化的方式，去评估、优化和保护整个技术链条，最大化地为用户提供稳定可靠的服务。

2.1 容量规划，资源分配的指南针 45

2.2 全链路压测，大促备战的核武器 51

2.3 全链路功能，提前开始的狂欢盛宴 58

2.4 自动化备战，喝着咖啡搞大促 65

2.5 实时业务审计，从系统可用到业务正确 70

2.6 故障演练，系统健壮性的探测仪 75

2.7 系统自我保护，稳定性的最后一道屏障 82

第3章 技术拓展商业边界 89

双11业务驱动技术发展的同时，技术的创新与发展也不断推动着商业模式的升级与变革，实践着技术拓展商业的边界。

3.1 招商报名，活动基础设施建设 91

3.2 会场，小二与商家共同打造的购物清单 99

3.3 搜索，大促场景下智能化演进之路 107

3.4 个性化推荐，大数据和智能时代的新航路 114

3.5 供应链，从飞速增长到精耕细作 120

3.6 蚂蚁花呗，无忧支付的完美体验 127

第4章 移动端的技术创新之路 133

从2010年开始，国内爆发了从PC向移动端技术和业务的持续迁移，移动深刻地改变着人们的衣食住行和人际交往。阿里的双11始于2009年，正好经历了移动互联网崛起的全程，双11在移动端的主要创新有哪些呢？

4.1 Weex，让双11更流畅 135

4.2 互动，让购物变成狂欢 143

4.3 VR&AR，移动端创新体验 153

4.4 奥创&TMF，让双11多端业务腾飞 163

第5章 繁荣生态，赋能商家 171

双11从阿里内部员工的一个点子到全球购物狂欢节，其背后支撑是服务、物流、大数据、云计算、金融服务等，是商家自身业务结构的调整、消费者消费习惯的转变、第三方开发者的大量入驻，以及整个生态的变迁。

5.1 聚石塔，开放的电商云工作台 173

5.2 菜鸟电子面单，大数据改变物流 179

5.3 生意参谋，数据赋能商家的“黑科技” 184

5.4 阿里小蜜，用智能重新定义服务 191

5.5 阿里中间件，让传统企业插上互联网的翅膀 198

5.6 蚂蚁金服，金融机构间协同运维的探索和实践 205

展望 213

索引 216

书摘：

中间件的意义就像阿里技术采用了相同的铁轨宽度、电器采用了相同的电压、沟通采用了同一种语言一样，持续地降低了学习、研发和运维的成本。

引自 五彩石

五彩石项目是分三期来实施的，三期项目都带有明显的业务目标，以业务目标为驱动的架构演进方式也成为阿里后续很多项目实施的参考。... 第一期打通商品，第二期打通交易，第三期打通店铺。另外一条项目主线是架构重构，通过不断抽取共享服务，形成服务化架构的电商平台。

引自 五彩石

我们希望研发人员仍然像以前开发单机版的软件一样开发系统，把分布式的问题控制在一些通用的组件里面。这就需要引入解决分布式问题的中间件技术。

引自 五彩石

五彩石项目第一次大规模地使用了中间件。系统分布式之后，需要有一套统一的组件来解决分布式带来的共性技术问题。比如提供服务的发现机制、提供服务的分组路由机制、同机房优先机制等，我们把这些能力沉淀在了一个框架里，这个框架就是 HSF。为了解决单库性能瓶颈问题，使用分库分表的技术，这个计数被沉淀在了 TDDL 框架上面。为了解决分布式事务的性能问题，把原本一个事务里的工作拆成了异步执行，同时必须要保证最终数据的一致性，我们采用了异步发布订阅的方式来解决，这个消息框架就是 Notify。

引自 五彩石

客观上说，出现如此大规模水平伸缩能力问题的业务并不很多，目前只有在交易业务上出来了，所以我们把这轮改造又称为“交易单元化改造”。

引自 异地多活

经过详细分析论证之后，我们认为交易是必须做到单元化的，其他的非交易业务（例如卖家业务等）在伸缩和容灾上所面临的挑战尚不需要采用单元化如此复杂的方案来支撑。根据这样的分析，我们把做到了单元化的交易成为交易单元，把其他没做单元化的业务称为中心——中心只能在同城部署，交易单元则可以在异地部署。

引自 异地多活

基于买家数据划分单元，将卖家/商品数据从中心同步到所有单元。

引自 异地多活

第1章 阿里技术架构演进

五彩石项目对阿里技术主要有两个影响：第一，通过抽取电商公共元素，沉淀了共享服务，降低了创新和试错的成本；第二，形成了一套支持互联网业务的中间件，因为分布式所以要用中间件，而中间件的意义就像阿里技术采用了相同的铁轨宽度、电器采用了相同的电压、沟通采用了同一种语言，持续地降低了学习、研发和运维的成本。

共享服务层的建立很好地对横向业务提供了统一的数据和服务收口，比如手机淘宝、安全、商家服务（TOP），这三个横向的业务就非常依赖共享服务。

第2章 稳定，双11的生命线

全链路压测

系统保护体系主要由五大子系统构成：限流、自动降级、流量调度、负载保护和预案。

第3章 技术拓展商业边界

招商报名，活动基础设施建设

* 价格申报系统价格管控系统

会场，小二有商家共同打造的购物清单

* 主会场、行业会场、标签会场、直播会场

* 会场页面基础搭建、赛马机制优胜劣汰、会场页面平台化建设

搜索

* offline、nearline、online三层体系

* 从2013年起，淘宝搜索就进入千人千面的个性化时代，搜索框背后的查询逻辑，已经从基于原始Query演变为Query+用户上下文+地域+时间

个性化推荐

* 2015年双11主会场个性化算法，即天坑一号，包括三个层次：楼层顺序个性化、楼层内坑为个性化、坑位素材个性化

* 个性化推荐，在内容方面分为商品推荐、店铺推荐、品牌推荐、评论推荐等；从目标方面，分为点击率预测、转化率预测、成交量预测

供应链

* 消费者付款后到最后收到货，有很多个影响消费者体验的环节：截单、赠品、分仓、合单、仓库发货、退款、退换货、发票、流水

第4章 移动端的技术创新之路

Weex

奥创

TMF（交易模块化框架）：改造交易平台核心链路系统，实现业务与平台的分离、业务与业务间解耦、业务可视化配置与发布。

第5章 繁荣生态，赋能商家

聚石塔

菜鸟电子面单：

* 智能分单

* 数据改变物流：基于电子面单的二段码和三段码、全自动化分拣、全网动态路由调度等基础服务，菜鸟创建了一个数据驱动的社会化物流平台

生意参谋

* 阿里数据及产品部在2013年规划建设、2014年落地的公共数据称one data，对数据进行规范化和数据建模，从根本上避免数据指标定义不一致、重复建设的问题。

* 门户方面，实现了多岗多面、多店综合。数据内容方面，强调全渠道和全链路。产品形态方面，把数据披露、浅度分析作为基础，拓展增值产品，为商家提供深度分析、诊断、建议、优化和预测服务。

阿里小蜜

阿里中间件

以下是书中一些信息的摘抄。#后面是kindle电子书的页码：

1：2009年我们技术部门只有几个人临时安排值班，高峰每秒只有400个请求，到2016年阿里有23个事业单位、几千位技术人员一起加入了双11的备战。杭州西溪园区1号楼的7楼、6楼和5楼都成为了双11的集中作战室，实现了每秒处理1.7万条请求的技术奇迹。#51

2：HSF、TDDL、Notify这“三大件”，有效地解决了应用分布式后带来的技术扩展性问题，同时让整个系统的技术架构变得依旧如当初一样简单。#342

3：五彩石项目将阿里电商交易的架构从2.0升级到3.0，大幅提升了系统的水平伸缩能力，异地多活则在五彩石项目之上，将阿里电商交易的水平伸缩能力再次提升为单元粒度级，架构版本也相应从3.0升级为4.0，这次架构升级从2013年开始，到2015年双11时已形成三地四单元架构（如图1-5所示）。#367

4：3.0版本之所以在更大规模时出现了水平伸缩能力问题，主要在于一个庞大的分布式系统中尚有若干集中式的节点存在，而要去掉这些集中式节点基本是没办法做到的。经过分析和讨论，我们认为一个比较好的解决办法是限制分布式系统的规模，当这个分布式系统达到一定的规模后，例如5000台机器，就再搭建一个新的。#382

5：2015年的双11意味着阿里交易架构从本地升级到混合云，具备了弹性使用云计算资源的能力，这个能力为阿里双11的成本控制提供了巨大的帮助。#531

6：OceanBase（中文名“海钡云”）是阿里巴巴/蚂蚁金服集团自主研发的面向云时代的关系数据库，从2010年6月份立项开始已经发展了六年半的时间。#598

7：OceanBase的第一个业务是淘宝收藏夹，之所以选择这个业务，是因为传统关系数据库无法满足收藏夹两张大表进行关联查询的需求，之前的解决方案无法对用户的收藏按照商品的价格或者热度进行排序。OceanBase抓住了这个业务痛点，并在底层存储引擎层面对这种场景进行针对性设计，消除了传统关系数据库最为耗时的磁盘随机读操作，巧妙地解决了这个问题。#613

8：因此，OceanBase在技术架构上做了一个折中，将写入操作全部放到一台服务器，从而规避分布式数据库中技术难度最高的事务处理。#622

9：淘宝直通车报表是OceanBase投入精力最大的一个项目。广告主通过直通车报表分析投放效果，最大的广告主需要分析的数据量有几千万行，要求在10秒以内返回结果。#639

10：最终，团队充分讨论后一致决定，坚持OceanBase的未来就是通用关系数据库。而作为通用关系数据库，OceanBase必须坚持强一致性，坚持关系数据库的SQL语义，像关系数据库一样易用。#655

11：相比传统的IOE架构，OceanBase能够将成本降低一到两个数量级，并提供更好的扩展性及高可用能力。另外，OceanBase支持平滑迁移，无须业务改造，就可以将原先使用MySQL的业务迁移到OceanBase。#685

12：全链路压测被誉为大促备战的“核武器”。如果之前关注过阿里双11相关的技术总结，对全链路压测一定不会陌生，这个词的出场率几乎是100%，从对双11稳定性的价值来看，用“核武器”来形容全链路压测毫不为过。#1099

13：经过反复讨论，最终我们找到了一个既不污染线上，又能保障压测结果准确性的方案：在所有写数据的地方对压测流量进行识别，判断一旦是压测流量的写，就写到隔离的位置，包括存储、缓存、搜索引擎等。#1149

14：为了减少熬夜，提升压测幸福度，我们启动了白天压测的项目：将线上运行的机器动态隔离出一部分放到隔离环境中，这部分机器上只有压测流量可以访问，白天在隔离环境的机器上进行压测。#1182

15：经过不断研发与测试，2016年我们在整个过程中解决了弹性服务池动态伸缩、跨地域调度、机房级容量探测与评估、故障自动隔离、全链路业务功能验证等问题，整体备战工作稳如预期。1383

16：第一个随之而生的是用于订正的数据修复平台，它是一个提供对脏数据进行快速订正并规范化用户流程的系统。#1471

17：第二个就是数据链路排查工具——全息排查平台。在阿里内部原本有一个非常著名的trace产品叫鹰眼，而让我们数据问题排查最头疼的就是到底是哪个环节改坏了，全息排查就是起这个作用的。#1471

18：2016年的双11，虽然BCP上的规则数比2014年翻了百倍，但当天大家反而对它的关注少了，因为双11前夕BCP已发现了上百个问题，而且被全部解决完毕。#1502

19：从2012年到2015年，依赖治理经历了4个版本的演进。从依赖分析、故障模拟、故障环境、故障分析等方面进行改良。保证结果准确的同时，大幅度降低实现成本，过去需要几个人做一个月的稳定性工作，现在一个人两个礼拜就够了。#1549

20：如果说故障重现是为了实现故障周期的闭环，那么故障演练则为用户提供一种定向演练的能力。#1595

21：故障突袭是一种以黑盒测试的模式验收稳定性的演练策略。#1606

22：在洪峰限流中我们采取的是令牌桶限流，在这个场景下，限流的实现通过漏桶算法来解决。漏桶算法思路很简单，水（请求）先进入漏桶里，漏桶以一定的速度出水，当水流入速度过大时会直接溢出，通过这种方式来调节请求的处理速度。#1660

23：流量调度，就是要屏蔽所有机器的软硬件差异，根据机器的实时服务能力来分配机器的实时流量。实时服务能力好的机器，多分配流量；实时服务能力差的机器，减少流量分配；实时服务能力不可用的机器，迁移流量。#1688

24：支撑这样一个花呗产品的团队你觉得会有多少人？2000人？或500人？No，我们还不到100人，包含产品、运营、技术、风险的所有花呗团队人员。几十人的团队能够实现几乎不可想象的普惠金融，促进新消费的快速发展，最核心还是在于大数据的力量。与其说花呗是一个金融产品，还不如说它是一个数据产品。#2503

25：回想过去几年，无论是移动网络速度、手机的内存容量、硬盘容量、CPU速度、屏幕分辨率，都在遵循或近似遵循“摩尔定律”。#2557

26：Weex利用H5的优势解决了Native的痛点：解决了iOS、Android等平台需要开发多套功能重复代码的问题；解决了Native无法做到即时发布及响应市场变化周期较长的挑战；提升了大规模团队在复杂集成系统平台上开发App的效率。#2605