2018年，淘宝网双11迎来了十周年。
十年间，依赖于迅速崛起的互联网技术以及各项新兴技术的沉淀，阿里巴巴缔造了全球数字经济时代的第一“操作系统”。在这个操作系统上，让全球消费者和商家买、卖、逛、听、看、游得顺心、放心、舒心。
十年间，阿里巴巴的技术同学和全球开发者们，一起把互联网前沿技术转化为全球消费者、全球数字经济参与者可以感知的便利。
它如今已经不仅仅是全球消费者的狂欢节，更是名副其实的全球互联网技术的演练场。
第十个双11即将来临之际，阿里技术推出《十年牧码记》系列，邀请参与历年双11备战的核心技术大牛，一起回顾阿里技术的变迁。
今天，天猫技术质量部资深总监、双11大队长霜波，将带领大家，细数每一年双11的重要节点和突破，遗憾与不足。我们相信，无论是双11，还是你正在经历的项目，都需要敬畏和细致的态度。所有的成功，一定是每个人极致努力的结果。
双11大队长霜波
淘宝之初：湖畔花园小区里诞生的巨人
2003年4月7日，马云在杭州成立了一个神秘的组织。他叫来十位员工，要他们签了一份协议，这份协议要求他们立刻离开阿里巴巴集团，去做一个神秘的项目。这个项目要求绝对保密，老马戏称“连说梦话被老婆听到都不行，谁要是透漏出去，我将追杀到天涯海角”。这份协议是英文版的，匆忙之间，大多数人根本来不及看懂，但出于对老马的信任，都卷起铺盖离开了阿里巴巴。
他们去了一个神秘的据点–湖畔花园小区的一套未装修的房子里，房子的主人是马云。这伙人刚进去的时候，马云给他们布置了一个任务，就是在最短的时间内做出一个个人对个人（C2C）的商品交易的网站。这 里出一个问题考考大家，看你适不适合做淘宝的创业团队：亲，要是让你来做，你怎么做？
在说出这个答案之前，我们先介绍一下这个创业团队的成员：三个开发工程师（虚竹、三丰、多隆）、一个UED工程师（二当家）、三个运营工程师（小宝、阿珂、破天）、一个经理（财神），以及马云和他的秘书。
项目代号：BMW
淘宝最初的网站架构模型，来源于一个购买的网站：LAMP(Linux+Apache+MySQL+PHP)，这个网站系统来自美国，名字是PHPAuction（拍卖）。这是一个到现在也很常用的网站架构模型，优点：无须编译、发布快速、PHP语言功能强大，能做从页面渲染到数据访问所有的事情，而且用到的技术都是开源的、免费的。（当前自己在做的网站架构是？）主要做的修改是数据库，将一个进行所有读写操作的 数据库，拆分成一个主库、两个从库，并读写分离。优点：存储容量增加；有了备份，使安全性增加；效率提高。
为避开强大的对手eBay，淘宝以“个人网站“的名义出山，以允许买卖双方留下联系方式、允许交易这种轻松简单的操作过程，搭配优秀的市场开拓可运营团队，迅猛发展。到2003年底吸引注册用户23万个，每日31万个PV，成交额3371万元。03年7月宣布淘宝是阿里旗下网站，展开市场推广。TB1.0中包含的基本功能包括：商品发布、管理、搜索、商品详情、出价购买、评价投诉和我的淘宝。03年10月新增功能点“安全交易“（支付宝的雏形）。
随着访问量和用户的增加，03年底MySQL撑不住，换成Oracle。（oracle容量大、稳定、安全、性能高，而且阿里有很强大的DBA【database administrator】团队。）。更换数据库不只是换个库，其访问方式和SQL【structured query language】语法都要跟着变，最重要的一点，oracle强大的性能和并发能力得益于一个关键性的设计“连接池”，一直在用的PHP语言对于连接池的使用有缺陷，于是开始了技术团队在这方面的研究和探索。（技术大牛，牛！）
微博上有人说“好的架构是进化来的，不是设计来的”，的确，加上一句“好的功能也是进化来的，不是设计来的”。（网站的定位对了，业务也在不断的发展。对于电商来说，线上交易的安全性是用户非常关注的问题，今天使用的支付宝，就是在03年结合PayPal、QQ币等多上线上交易方式，想出来的。11年支付宝的交易笔数已经是PayPal的两倍。另外，在网站的发展史上除了技术人员、产品人员之外 ，运营团队也是功不可没，像是网站推广时的拉新、后期的促活和留存，也像是淘宝、淘宝旺旺、支付宝等名称皆来自于运营人员。）
黄裳：“好的架构图充满美感”。
04年数据库必须要用oracle，SQL Relay解决不了问题，只能换开发语言。把一个庞大网站的开发语言换掉，无异于脱胎换骨。（工欲善其事，必先利其器。要更换成jara语言，就要用jara的专家，那就是创造Jara的Sun公司的人。而且当时Sun工程师刚给eBay从c++改造成Jara，所以他们不仅懂Jara，而且更懂eBay。）
2004年
我们使用一个叫做ESI（Edge Side Includes）的缓存（Cache）。在决定采用ESI之前，多隆试用了Java的很多Cache,但都比较重，后来用了Oracle Web Cache,也经常挂掉，Oracle Web Cache也支持ESI,多隆由此发现了ESI这个好东东。ESI是一种数据缓冲/缓存服务器，它提供将Web网页的部分（这里指页面的片段）进行缓冲/缓冲的技术及服务。以往的数据缓冲服务器和信息传送服务器以“页”为制作单位，复制到数据缓冲服务器中，这用于处理静态页面很有效，但在面对 动态内容的时候，就很难得到高效率。在ESI中是部分的缓冲网页，使用基于XML的标记语言，指定逍遥缓冲的页面部分。由此，页面内分为动态地变更部分和静态的不变部分，只将静态的部分有效地发送到服务器中。淘宝网的数据虽然是动态产生的，但页面中的静态片段也有很多，例如页面的投、尾，商品详情页面的卖家信息等们这些都是从ESI缓存中读取的。
2005年
2005年，商品数1663万个，PV有8931万个，注册会员有1390万个。这给数据存储带来很大的压力，这种情况下除了搜索引擎、分库分表，还有什么办法提高系统性能？川村和CDN（内容分发网络）。刚接触缓存时，常犯的错误：更新数据库的内容是，忘记通知缓存系统，结果在测试的时候发现我改过的数据中在页面上没有变化。（所以，我在项目中经常遇到的需要客户清缓存的情况，是否是技术人员多留心一下就可以解决了呢？页面上的代码做修改时，用户本地的缓存信息应该还是需要用户来清缓存Ctrl+F5.）
2006年
2006年底，阿里巴巴提出了Work at Alibaba的战略，二十多个人就被拉到湖畔花园马云的公寓里开始一个叫阿里软件的公司创业。当时对于Work at Alibaba有一个朦朦胧胧的感觉，就是要为中小企业提供一个工作平台，但是工作平台又需要是一个开放的平台，因为卖家的需求是长尾的。当时火热的Salesforce给了阿里人一些启示，那就是做一个支持二次开发的工作平台，半开放式地满足各种卖家的长尾管理需求。此时，软件市场上就开始培养起uizao的一批TP（淘宝开放合作伙伴）。迄今为止，很多非常成功的TP就是从那个时候开始进入淘宝卖家市场的。
但经过一年的平台建设，发现开发者非常难利用平台做二次开发，只有阿里软件内部的团队构建了三个不同的CRM软件。这时候淘宝来了一个业界的技术牛人王文彬（菲青），这位淘宝新近的首席架构师找到阿里软件的平台架构团队，谈到了当时业界还非常新颖的一种技术平台–开放平台。
例如缓存、CDN等优化手段；运转状况监测、功能降级、资源劣化、流控等可用性手段，自建机房、硬件组装等成本控制手段。 因此，构建一个互联网网站确实是不容易的，技术含量十足，当然，经营一家超市也不简单。
架构
讲到阿里的开发大牛没有技术创造技术，减少服务器个数，节约存储成本的那部分。只想说：创造成就生产力。在商用系统和自主研发之间的经济效益方面，章文嵩博士列举的经验：
1、商用软件很难满足大规模系统的应用需求；
2、研发过程中，将开源和自主开发想结合，会有更好的可控性；
3、在一定规模效应的基础上，研发的投入都是值得的。
淘宝对图片的存储需求概述：
文件比较小；并发量高；读操作远大于写操作；随机访问；没有文件修改的操作；要求存储成本低；能容灾、能备份。
应对这种需求时要有分布式存储系统；由于文件大小比较同意，可以采用专有文件系统；由于并发量高，读写随机性强，需要更少的I/O操作；考虑到成本和备份，需要用廉价的存储设备；考虑到容灾，需要能平滑扩容。
很多技术都是在产品的推动下得到发展的。那些年做过的产品：团购，由于种种原因，在开发的时候对产品的功能做了建材，与最初的设想比起来偏离了一点，最终这个产品沦为了促销工具。这个产品让研发人员对“产品”这个概念有了深刻的认识。
基于对“我的淘宝”进行优化，尝试Gmail上AJAX的交互方式。新技术对用户操作习惯的改变，在应用时一定要慎之又慎。
2007年
2007年，日均PV达到2.5亿，注册会员5000多万个，全网成交额433亿元。
在系统发展的过程中，架构师的眼光至关重要。作为程序员，只要把功能实现即可，但作为架构师，要考虑系统的而扩展性、重用性，对于这种敏锐的感觉，有人说是一种“代码洁癖”。（作为IT部门的常客，从工作开始至今，依然觉得做系统架构的几个前辈有独特的侠士气质。）
品牌、款式、材质等都可以叫做“属性“，属性是蕾西Tag（标签）的一个概念，与类目相比更加离散、灵活，缩减了类目的深度。（来自淘宝产品经理一灯，应该就是我们平时用的SKU吧？）
业务总在后面催，开发人员不够就继续招人，招来的人根本不懂原来的业务，只好摸索着在“合适的地方”加一些“合适的代码”，看看运行起来像那么回事后，就发布上线。（这感触太深了，有时候给新来的开发说需求，得追溯到这个需求的老祖宗，完了人家还只能勉强认识直属亲戚，七大姑八大姨还得慢慢来。历史文档留存的重要性，在这里就显现出来了。）
08年底，淘宝把功能模块化，TC（Trade Center）、IC（Item Center）、SC（Shop Center）,这些中心级别的服务提供原子级的业务逻辑，再网上是业务系统TM（trade manager）、IM（item manager）、SM、 Detail（商品详情）。拆分后每个系统可以单独部署、业务简单、方便扩容，也能做到专人专事。但各系统之间相互调取信息就比价麻烦。（现在在做的网站，也是讲原来一个系统拆成六个板块，当时是为了将其中某些模块与要做的其他网站共用。）
在这些产品和功能的最底层，其实还是商品管理和交易管理。
2009年
2009年是淘宝商城成立的第二年，这一年的秋天，运营的同学想搞一场营销活动，逍遥子喜欢四个一，而11.11又是网民创造的“光棍节”，所以就选择了这一天。谁也没有想到，这样一个带着点随意的选择，竟然在若干年后成为影响中国乃至全球的大事件，造就了电商行业最具影响力的品牌——双11。
第一届双11的活动口号是全场五折，拉了几十个商户参加，未曾想效果惊人，淘宝商城的成交额是平时的十倍。幸运的是，在2009年初，“五彩石”项目，将淘宝和商城的系统底层架构统一了，虽然商城的成交额增加十倍，但由于基数还比较小，这个成交额和淘宝的日常成交额比起来并不大，因此系统上没有出现特别重大的事故。
尽管如此，暴增的流量还是让工程师们措手不及。采访当年第一届的工程师四虎时，他回忆说：“第一年双11，作为交易系统的owner，接到老板指示，光棍节要搞个活动，你值一下班。那年我们啥都没做，就坐在那看服务器的情况。0点一到，发现服务器流量暴增，一下子服务器就挂了。我们就手忙脚乱地去重启服务器，恢复系统。系统起来后，发现店铺和商品图片又出不来了。第一次双11，可以说完全是意料之外，没有做任何准备的，不仅仅是把我们的交易和商品系统压挂了，同时把很多商家的外部图片空间也给压挂了。服务器容量、网络带宽容量、系统保护都是没有的。”
2010年
吸取了上一年的经验，2010年双11之前技术部门专门成立了大促小分队，负责保障稳定性的同学在创业大厦10楼集中办公。那一年，高峰不在0点，而是出现在第二天白天，早上10点左右CDN的容量很快达到上限，图片展示越来越慢，眼看就要出不来了。大家紧张起来，激烈地讨论还有什么办法。有人提出搜索的图片展示占了很大的容量，可以将搜索的大图降级为小图。然后给搜索的负责人打电话，通知他：“对不起了，我们要对搜索的图片降级了，双11结束就给你们恢复过来。”这一招帮助当年的双11渡过了容量的最大风险。
之后，每一年的搜索大图降级小图都成了双11的必备降级方法之一，虽然后面再也没有启用过。同时，每一年双11之前CDN都会拉一个大会，让所有业务评估自己双11当天的CDN使用量，提早2个月就开始扩容的准备。“所有的苦难都是用来帮助我们成长的”，这句话用在双11当中特别合适。
四虎回忆第二年的情景：“第二年，我们开始有了心理准备，预计流量是平时的3倍5倍，但是实际流量远远超出我们的想象，达到了平时流量的十几倍。不过基于前一年的经验，这一年我们做了很多工作，分布式系统的防雪崩、核心系统的自治，这些技术改进让我们的系统比上一年好了很多，虽然0点高峰还是出现大量的购买失败，但是服务器没有大面积宕机，流量下降后能够继续良好地服务。”
2011年
2011年淘宝商城成为独立的事业部，双11对于刚刚成立的淘宝商城技术部已经是一件相当重要的大事，各团队提早几个月就开始准备，并且上线了第一期的价格申报系统，完成了双11的商家商品报名的工作，一切似乎都很顺利，可是……
11月10日晚上23点，有人反馈设置的优惠价格写错了，3折的商品写成了0.3折。
23点32分确定砍掉折扣0.5%以下的商品，然后需要推送到整个商品库。执行到一半的时候，越来越多的人反馈商家把优惠理解错了，担心影响太大，决定砍掉1.1%以下的商品，但是由于之前的操作已经执行，所以先要回滚，然后再全部推送。
23点45分，开始回滚。
23点55分，回滚完成，开始重新推送。
11日0点10分，所有推送完成，同时开始收到大部分商品属性丢失的问题反馈。属性丢失意味着买的衣服没有颜色，意味着买的鞋子没有尺寸，当时用户由于很多商品都已经在购物车中准备良久，所以并不仔细观察就下了单，可是商家却没有办法发货。这是一个非常严重的系统Bug。当时唯一能做的事情就是通知所有有问题的商家下架商品，等待系统修复。
11日凌晨1点，定位到错误代码是回滚程序的Bug。决定发布新的系统解决问题。
11日早上5点，系统Bug修复，通知商家重新上架商品。
时隔5年，回忆起那一晚，依然心有余悸。外界往往认为双11那一晚是精心准备的，技术是游刃有余的，可是每一年，我们都在匆忙中解决各种临时的突发事件。实际上真正痛苦的远远不止技术人员，还有那些被影响的商家。
在商家沟通会议上，我们问商家：“对双11最大的期望是什么？”反馈最多的期望就是：“系统稳定。”一个商家站起来说：“去年双11的0点我们被通知下架所有商品，当时团队10多个人，从0点到早上6点，没有一个人敢离开。我们借了款，备了平时十倍的货，如果这个双11卖不掉，我们回到家，对家人唯一能说的可能就是 ‘对不起，我破产了’，或者‘对不起，我失业了。’”
那个晚上，很多人无眠。
痛定思痛，我们在接下来的一年做了大量的稳定性相关的工作，我们上线了新的招商、价格管控、商品申报和优惠系统。我们做了csp的压测平台。我们做了系统限流sysguard自我保护系统。我们在2012年准备了接近3000的降级开关，做了4次大规模功能演习，确定了双11当天的指挥和决策流程。我们以为2012年我们能做到万无一失。
2012年
这一年双11的项目5月就启动了，当天晚上整个集团的核心技术几乎都all in在双11，我们准备了一个很大的房间，每个核心人员做好各种预案手册，当天晚上全神贯注就等着0点的到来。可是，那个0点，流量来得比以往更猛一些。
0点的时候，系统显示交易成功率不到50%，各种系统报错，立刻下单报错，购物车支付报错，支付系统报错，购物车的东西丢失。系统排查的大部分指向都是一个错误，取不到商品信息了。再进去看，商品中心系统的网卡被打满了，无法再响应请求。情况紧急，商品中心开启了事先准备的几乎所有降级方案，但效果并不明显。大约在1点左右，系统流量峰值慢慢缓和，我们的系统成功率才重新恢复到90%以上。
另一个发生问题的是支付宝的健康检查系统，和所有系统的自我保护系统一样，这个健康检查系统会定时扫描线上机器，根据机器应答返回时间判断是否正常，将超时严重的机器在应用列表中剔除，当时用了自研发的ssl 卸载 spanner 负载均衡算法有问题，导致服务器负载不均，应用那时候用的是apache ，连接数只有1K 多的性能瓶颈，在双十一的流量之下雪崩了。发现问题之后，我们快速启动了应急预案，同时做了流量切换，支付成功率重新回到了正常值。在1点之后，我们看到系统各项指标都恢复了，心情稍稍轻松了一些。但是白天新的问题又来了。
白天的时候，各种商家开始来电反馈一个严重的问题，系统超卖了。就是本来应该卖完下架的商品，在前台展示依然有库存，依然不停地被卖出。我们理应给商家一个正确实际的库存，可是由于0点的各种异常、降级和超时导致库存的状态已经不对了。由于数据过于凌乱，系统已经无法当场完成纠正，除了通知商家自己检查库存，尽快下架商品之外，我们已经无能为力了。那年的双11，很多商家由于我们的超卖不得不紧急重新采购，加工，补货。那年的双11，应该有不少用户要等很久才能收到购买的商品。
之后的双11技术复盘会上，所有技术同学达成了一个共识，我们一定要有一套系统能够最真实地模拟双11当天的流量，能够及时发现大压力下线上系统的所有问题和风险，保障双11的0点体验。所以2013年，集合了各个BU的力量我们创造了一套全新的压测系统：全链路压测。
一个全新的系统，从产生到全面实施从来不是一帆风顺的。刚开始，大家根本不敢到线上压，担心影响用户，直到有人大胆地承诺：“出了故障我来背！”到9月时，刚开始两次大规模的压测都失败了。有人开始怀疑方案的可行性，思考要不要回到之前的压测模式，直到有人坚决地前行：“我们这次一定要成功，让所有的开发一起来加入!”有人在打趣：“摩擦了一晚上都没有动静。”有人在宽慰：“第一次从来不会一把成功，我们多磨合几次。”我清晰地记得第一期的那些开发同学，在一个小小的会议室里面，晚上12点我回家的时候他们在，早上8点我来公司他们还在。眼睛里经常有血丝，但是说起话来还是中气十足。每次给我的答复都是：“我们会成功的。”感谢这些同学，无论现在是否依然在双11的岗位上奋战，但双11的功臣中一定会有你们的名字。
针对库存的问题，我们在2013年做了独有的超卖审计系统，会实时对账所有库存，一旦有超卖马上能收到报警，这个系统在这些年的库存保障中发挥了很大的作用。
2013年
10月全链路压测终于成功了，几次压测中发现了600多个Bug。参加的技术同学纷纷感慨称之为“神器”。但是在0点开始之前还是出现了一个小插曲。通常双11之前所有日志都会清理一遍，但是那一年这个常见的操作却遗漏执行了，技术同学就在10号晚上发现问题时，临时手工写了一个简单脚本处理日志清理，可是脚本发生了一个小问题导致日志文件被删掉，由于害怕日志输出找不到文件会影响性能，所以决定分批重启机器，重启时又发现已经执行的提前预案中有一个Bug，在启动初始化时有报错，导致应用启动失败。最后只能紧急发布修复了Bug。所有机器重新启动完成的时间是10号晚上11点55分。当时大家盯着时间，盯着系统一台机器一台机器地发布，和时间赛跑的感觉历历在目。再后来每次大促之前我们会提前准备一份作战手册，写好所有的内容，细化到时间点和执行人，防止再出现任何的意外。那一年，有惊无险。0点的成功率满足期望。而且系统容量和0点的峰值差不多吻合。用户体验刚刚好。
2013年的时候由于各个系统的预案加起来已经超过2000个，无法靠人来控制和梳理了，我们做了一个所有预案的控制系统，提前降级的开关可以准时执行，准备好的预案可以录入并且做好权限和通知管理。
2014年
2014年，由于用户和数据的急剧增长，杭州的机房已经容纳不下我们的系统扩容了。于是我们在上海建立了新的机房，双11当天，真正启动并且实现了异地多活的梦想。那一年是最顺利的一次双11，系统和用户体验都没有问题。但是在双11的总结中我们发现了一个特别明显的趋势，就是无线的占比越来高，双11当天0点已经超过50%，如何在手机这么小的屏幕上推荐给用户他真正想要的商品也成为技术必须解决的难题。
2015年
2015年，第一次有了双11晚会，晚会现场可以压团队，可以现场抽奖，技术部的同学实现了线上和线下的同期互动。效果超出期望的好，然后我们的客户端注册系统当场就被用户的热情打爆了，紧急扩容解决。
0点无线端导购的流量大大超过了我们的预期，而我们的物流系统和导购部署在同一批物理机之上，机器资源发生争抢，有10%的物流机器被打死，无法响应，那么落入这批机器的用户就会购买失败。在0点10分的时候，我们做了一个决策，直接剔除了这批死掉的机器，系统的成功率重新恢复到正常值。当时的决策有点风险，因为0点10分的时候流量依然很大，我们无法推测剔除这批机器的风险，那90%的机器如果扛住了，我们就成功了，如果扛不住，可能所有交易就会跌到零。我想一定是用户的热情创造了奇迹。我们幸运地扛住了那个0点。
2015年我们在会场页面实现了全面的个性化，每个用户看到的会场推荐都带入了自己的喜好和偏向，这一变化，让无线的点击和购买率得到了大大的提升，也为下一年的全面个性化打下了基础。
2016年
2016年开始，我们的全链路压测加上了导购的流量，而且在2016年我们的导购峰值也从之前的10号10点转移到了11号的0点，和交易的峰值完全重合，0点峰值的压力进一步加大。
为了能快速释放和节省双11的成本，我们实现50%的云化，在双11之后一周内就将机器资源释放出来，提升机器循环使用的效率。
我们手机客户端自己做起了直播。晚上就可以在手淘和天猫客户端一边看晚会一边参加抽奖和互动游戏。
产品玩出了跨店的红包和购物券，可是由于0点的限流产生，就发生了这些组合下单的商品一单被限流支付失败的情况下其他一起下单的商品由于享受了组合的优惠所以也一起无法下单。双11前一天已经评估出了这个风险，所以准备了一个后台程序帮助回补没有使用的红包和购物券。可是由于流量的长时间的持续，限流时间超出预期，我们的后台程序也在大压力下挂掉了。技术的同学只能对后台程序进行扩容，从准备的几十台机器扩展到几百台机器，终于在早上6点完成了红包和购物券的回补。
2017年
2017年的零点是过往历史上最顺畅的一年，包括我们新上的混布系统都在零点很顺利的扛过了我们零点的高峰。
可是一点预售付尾款的那一刻，我们却发生一个功能的bug。飞猪预售订单无法支付尾款，这也导致飞猪发出的很多红包无法使用，从而大量的用户开始投诉。无法回滚，因为回滚意味这很多功能要缺失，不敢切开关，不知切换开关之后对其他bu会不会有影响，我们只能小心地修改代码，重新测试上线，所以直到早上6点，这一问题才被解决。而导致这一bug的根本原因是11月8号晚上的一个紧急发布引入的一个问题，由于太晚发布没有赶上功能回归的时间节点，于是遗漏到了线上。最终，变成2017年双11的最大遗憾。
总结
2018的双11越来越近，第十个双11，一定要做到十全十美，以史为镜，每一年的问题都不同，但是阿里的技术人绝不会让同样的错误重复两次，我们一起加油！
来源：阿里技术，子柳《淘宝架构技术这十年》
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/257528.html