基于大数据的全球电商系统性能优化

架构 架构师 ArchSummit 阿里 郭东白

今天第一位讲师是来自阿里巴巴的郭东白老师，为大家分享在跨境出口电商方面基于大数据的电商系统。大家欢迎！

郭东白：我先介绍一下我自己，我之前在美国读书，在美国生活了十几年，前年的时候回到了阿里巴巴。我目前负责阿里巴巴的AliExpress，它是跨境出口的网站，也是现在国内最大的跨境电商平台，在全球范围排名仅在Amazon和eBay之后。

首先我主要会讲基于大数据的全球电商系统性能优化，因为事实上我们是用一个比较标准的系统，所以大数据的内容相对会讲得比较少；在场有不少带团队的架构师同学，因此也会顺便讲一些架构师带团队的内容，然后接下来会介绍我们的Background、理论基础、平台设计、优化实施的具体过程，最后再讲Business Impact。

一、Background

阿里巴巴系统里实质有国内以及国际部分，国内部分大家都听说过了——淘宝、天猫、聚划算，国际部分的“淘宝、天猫、聚划算”合在一起就是AliExpress。AliExpress是B2C做Consumer生意的，还有alibaba.com做B2B生意的。

AliExpress跟国内淘宝、天猫最基本的区别是我们在做跨境生意，什么是跨境生意呢？这一边是我们的卖家、另一边是买家，中间隔了一个International Border，其中大多数卖家是中国卖家，但我们不仅仅局限于中国卖家，现在俄罗斯卖家在我们平台上也卖得非常好，每月几十万美金甚至上百万美金的量级，他们都是做得非常不错的卖家。这些卖家其实面临很多很多挑战，可以想象一下如果一个俄罗斯卖家把他的货卖到土耳其时，他需要什么能力？对应的服务全是中国人，系统是中国人造的，卖家只懂俄文，商品都是俄文说明书，商品要卖到土耳其去，土耳其人可能一句俄文都不讲，这个挑战非常大，而且这个过程的信息流挑战很复杂。我们现在平台支持16种语言，这些语言大多数是我们机器翻译的，翻译得也并不是很好，我们的机器翻译水平也在萌芽状态，我们整个过程面临的挑战如下：

• 语言障碍；

• 信息流，图片可能在本地是合适的，但在全球情况下信息流就有挑战了，例如现在巴西冬天是我们这里的夏天，南北半球情况这些信息听起来像是地理问题，实际上是信息问题，我们怎么把合适的信息送到南半球人上；

• 资金流，我们平台支持的支付币种有16种，大家各自用不同的币种。不仅仅买家会跟钱有关，做电商的还包括联盟、物流商（物流商还不止一个，国际物流分好几段，可能中国有一段，俄罗斯那边有快递又有一段）等等。在整个大系统里怎么分利润，包括你自己、平台、买家、卖家、物流商、站长，而且这里所有的人想拿的币种还不一样，有些人想拿美元，有些人想拿本地货币，遇到退款的话总不能把卢布退给美国人，这资金流存在很大的挑战过程；

• Logistics（物流），物流也是很复杂的过程，怎么确保中国的货运到全球，假设别人不喜欢的话怎么把货退回来，这也是非常大的挑战。

我今天讲的是信息流上的Performance，我先给出一些数字让大家大致知道我们系统做得有多大：

• 我们系统现在在Alexa排名是第25名，第25名是什么概念呢？microsoft.com（微软）排在50名，walmart.com（沃尔玛）排在150名，我们作为电商网上排名非常高了，单日的Order是2200万单，尽管亚马逊很大但它日常也到不了这个量；

• 我们系统的设备有九千多种接近万种型号，每天至少有200个国家的人不管是平时还是周末都会下单，当中有16种语言的人在下单；

• 我们的App launch了一年，虽然从去年才launch但在今年3月份我们已经在47个国家iTunes的App Store里排名第1位，Google中我们在20多个国家排名第一位（Google只有80多个国家有排名数），相当于我们已经占据了1/3国家下载量排名的第一位，从技术上来讲我们支持了非常快速的增长。

我们为什么care Performance呢？我们先看下这张图，这张图显示了Net Promoter Score和Relevance Score的值，Net Promoter Score是净推荐值，在横轴上越往左边越好；纵轴是Relevance Score即相关性，相关性越大越重要，可以看出网站性能相关性是我们所有调研各种不同系统中的No.1重要，甚至比商品都重要，这也是我们当初非常惊诧的事实，这个Performance的满意度不怎么样，我们的商品也有很大的挑战，但是这个Performance满意度竟然比我们商品的满意度还要低，所以我们在（考虑）怎么做商业的时候“性能”是很关键的数字。

性能为什么很重要呢？大家玩过电商就知道了，电商非常重要的是引流，比如在各种搜索网站做SEO，做这个事情别人会量你的性能，用性能作为衡量网站质量的参数，Google也不愿意一点进链接结果一点反应都没有，这样Google自己的生意都坏掉了，Website Performance在接近8年多前Google就将其作为排名的重要指标，现在的确也还是他们的重要排名指标。

性能其实是钱，我们不是为了倒腾性能作为统计数据才做这个事情，作为架构师第一重要的事情还是得创造价值，不创造价值的架构师是没用的。我们把性能优化理解成一场战斗，传统的性能优化是怎么打仗？有点像冷兵器时代打仗——匹夫之勇，什么是匹夫之勇呢？我刚来的时候团队里也有这种人，比如他在网络优化或服务端优化上个人技术很好，有些人比如读了几篇Paper然后来试一下结果很有效然后自己玩。要知道整个网站的Stack是非常深的，从客户端（Android、iOS、Web）然后到整个网络层的请求，然后到接入层，然后到各种接入的Security层，比如各种各样的网关，网关之后比如是Nginx反向代理、安全层、应用层、服务层、数据层一直到底层的基础架构层，这个层级是非常深的，直到底层包括OS，你能想象出世界上会有一个人把所有从上到下全部精通吗，不可能，冷兵器时代很多人就是学了一招好使，然后吹个牛晋个升就完了。

构建大团队的时候不希望出现匹夫之勇来打仗，现在modern打仗不能靠匹夫之勇，你其实是希望设计一套系统能够让所有人一起创新，第一要创新，第二要集体创新，即democratic team，每个同学都应该赋能给他，甚至一个小兵也可以协助你打仗，而不是只有两个将军打仗，现在中美打仗怎么可能是奥巴马单挑习主席呢，你是需要每个人都要打，每个小兵都要参与到战争中，而且你要能够真实衡量他们的贡献，这个东西非常重要，很多情况下大家不患贫而患不均，所谓患不均是怎样的？他对自己的贡献不清楚，别人给他发的奖金他也不舒服。有个joke是80%的程序员认为自己比80%的程序员还要牛，做性能优化也是这样的，以为优化了一点点就觉得自己很牛比别人都牛，其实有时候不是的。

先讲讲相关的技术：

• 大家可能已经看到现在市场上有比如做APM（Application Performance Monitoring）的，这种东西的确是做全栈优化的，但事实上很少做整个系统从任何一个地方归集到全局的指标，它不做这个能力；

• Web performance monitoring，这种就像webMethods，比如之前的Gomez，这些公司它们主要做测量来量客户端的性能，他们会在网上给你发一大堆报表。这有什么问题呢？他们其实不跟你自己的业务数据挂钩，你也不希望把自己的业务数据都给他们，毕竟他们还服务第三方，如果你把数据都给了他们，你的竞争对手可能也会拿到同样的数据，这些数据就会帮助你的竞争对手。一般我们不做这种共享，至少在我待过的大公司不会做这样的共享。

• 最后是一些on-site的Performance Tuning Toolkits，这种一般在Server端做的，它的目的不一样，它往往是为了节省你的服务器成本，比如把你某某端性能优化N倍，使得throughput加了10倍，以前300台机器变成了30台机器，它是减少这个成本的。

但是我们想做的事情还是从用户端来聊，期望能提升比如俄罗斯西伯利亚买家的体验，使他更愿意下单。做这个事情挑战很大，因为搜索空间非常大，做过性能优化的人都知道优化方案是非常多的，空间是以数百计，Stack非常深而且每个地方都有10+个优化方案，那么从上到下在10+个不同的地方做优化最终就有上百个优化方案。一个大的网站，像我们网站页面和元素的数量级已经接近数百了，再算上后台的应用整个复杂性就上千了，你能优化的地方的招数有数百，能玩这个招数的擂台有数百近千，这两个地方乘起来数量级是非常大的，而且你每做一次优化都是有成本，大家如果自己做生意或者你是一个很大团队的leader就会知道，你可能会经常困扰做优化也是有投入的，回报多大非常关键。这个问题其实就是搜寻空间太大，我们试图把这件事情变得非常理智。

二、理论基础

怎么做呢？如果大家用过performance monitor就会知道，图中绿色曲线是网站流量根据延迟的区间分布，横轴是延迟区间（以毫秒计，一般网站也不会等到64秒这么长时间），这图显示了大多数请求发生在1秒左右即800毫秒到1.2秒的这个区间，这是请求的延迟分布；纵轴（红色的轴）代表跳出率，代表在这个请求过后你决定不再继续使用这个网站了就跳出了的概率，跳出率是随着请求延迟越来越高的，相当于你在这儿等不及了烦死了最后即使这个请求返回来了你也放弃了继续浏览的欲望了。这个力度可以有粗有细，你可以是整个页面的跳出率也可以是某个元素加载的跳出率，也可以是某个步骤的跳出率，比如说白屏加载、首屏加载到全屏加载，这是一个有顺序的过程，白屏到首屏也可以来量跳出率。

有了有些数字的话，这个东西是可以量出来的：上图公式中的P代表绿色的线，C代表红色的线，一个页面的转化率是绿色曲线乘以红色曲线的一个积分，有了这个东西你就能观测到一些现象：下图深绿色虚线是假设你的集群的部分机器出现问题，出现问题以后你的请求流量会发生变迁，为什么发生变迁？高性能的请求变少了，在性能很差的地方（延迟很长的地方）请求数会变多，这就相当于产生了一个新的请求分布，相当于集群出问题了，很不幸的那部份流量落在出问题的机器上了，整个集群的跳出率会随着时延出现明显的增长，正常情况下这条曲线是平的，但是例如有一个人平时如果在这个快速的地方被移到高延迟的地方，他一不高兴不能等就走了。如果你们量自己的网站就会发现曲线一般都是类似的，当然每个曲线是不一样，因为你自己的客户是被你训练出来的，有的人可能耐性很好，你网站本身就很烂很Low，他天天在那儿等等习惯了也无所谓；有的是你的网站非常快，他根本不能等，这个曲线就会变得非常陡。

上图是很多人都知道，是比较著名的图，但是现在我们需要反过来想，假设虚线是你的正常情况，实线是你的理想情况，反过来把性能优化以后会得到一个回报，转化率会上升（因为跳出率会减少），怎么算呢？具体计算公式在下图中写着，正常情况下的分布如图，优化以后相当于把整个请求压缩了，假设以前要15秒现在降成3秒，一旦压进去之后流量不在慢的转化率上发生而是在快的转化率上发生，那么绿色的区间就是做优化后你能得到的回报。这只是一个理论值，这里还有一个很强的假设：一个人群以前用15秒去下载一个页面，如果把它降到3秒的话他们的购买率和3秒是一样的，这仍然是假设还没有证实。

如果这个假设成立的话，就可以认为性能是跳出的唯一因素，在这种情况下你能算出来任何一个页面因为性能不好而造成的损失我们叫Page Loss，一个页面就有一个Page Loss，你知道一个页面Page Loss的时候就能做更重要的事情：你能知道从一个页面跳到下一个页面这个损失是多大，如果把损失的东西都补回来，补到下一个页面的话价值有多大。什么意思呢？大家可以想象一个江河，它的水一直流到大海里，假设哗一下下大雨了，从小溪流汇到河流然后到大海，这个小溪流的水可能会被分流到农田、麦田里或者被蒸发掉，河里的水也有可能被人消耗掉，最终汇到大海的水假设你把所有损失都补偿上的话，就是理论期望得到的总值。

具体的公式推导不做了，假设是有N个输入，每个输入都做刚才那个补偿的话，A就得到了理论流量，理论流量扣除自然损失，什么叫自然损失呢？在任何一个页面上，跟你的性能无关也有自然损失，说白了人家到你网站去了本来想买一个LV的包包，但是一看到你这儿都是没见过名字的"VL"包包，他就不想买了就走了，这是自然流失，因为他是不满意内容而不是不满意性能。这个自然流失扣掉以后你得到的结果就是你的理论补偿，这个公式实际上把真实页面采集到的数做理论补偿，做完理论补偿然后扣除你之前算出来的自然跳出率，这个值就得到理论上的补偿过的流量。

得到补偿以后就能干最后一件最重要的事情：从一个页面补到下个页面然后持续不断地进行补偿，我们就算不谈元素仅仅大页面就近百，在近百页面的情况下在List（例如搜索页面）有补偿，然后到Detail（详情）有补偿，然后到下单有补偿，这个链路是很长的，整个链路一点一点补偿回来最终到了大海——Order，为什么用Order这个点呢？选择这一个点的理由是你真真正正需要care的东西。比如你是做内容网站的，其实你也有目标函数，你也有一个最最重要的东西，假设从你的网站做导流，你是一个联盟网站，你想导到另外一个真实的下单页面，例如当年的蘑菇街导到淘宝，只有点击生效以后才赚到钱了，这一点就是你最终要优化的东西。这个过程其实就是让你把所有之前的要补偿的东西一直算到你的回报有多大。这个过程就相当于我们刚才量List的补偿、Detail的补偿、Store的补偿等，这个公式在你知道这个页面关系图的情况下就可以把整个理论的补偿流量算出来。

这个过程完成了就到最后一步，任何一滴水即大家可以把一个小优化，比如说是注册页面上的小小优化，比如把验证图片的速度提升了3个毫秒，这3毫秒优化到底对最终客户下单产生了什么回报，这一滴水从注册的页面流到搜索然后流到Detail，整个补偿的这一滴水全部最终汇到你的订单上，这样就可以让每个人（之前提到的要赋能全部的人）的能力都能体现出来，把个人所做的对性能的这一点点优化体现到全局上去，这是我们要做的事情。

其实我们没必要搜寻这个伟大的空间的，事实上我们甚至还没开始优化之前我就能知道回报有多大，为什么？举这么个例子——DNS优化，任何时候你要做一个DNS lookup，比如说俄罗斯远东地区DNS lookup很慢，比如要25毫秒，你在没有做这个优化之前你就知道这些人不管怎么优化，只有少部分的俄罗斯远东流量可以从25毫秒优化15毫秒，这15毫秒结果是什么呢？你把25毫秒设置成15毫秒代到前面的公式去，总的公式上就会告诉你优化从25毫秒变成15毫秒最终会得到多少订单回报，全局会得到多少订单回报，比如说俄罗斯远东订单最终得了0.1%的回报，投入是多少呢？后来发现在俄罗斯远东地区盖一个专属的DNS服务器根本不比盖在法兰克福便宜，太贵了不愿意盖。这就是核心的东西，它给了你事先做决策的工具，刚才讲我们搜索空间上千，上千的搜索空间没等你干活就知道值不值得做。

接下来一旦找到好的优化点，理论优化量你只要在这个页面上做一次就知道它的真实回报是多少，因为一开始那个值是算出来的，一旦你做了优化之后你就得到真实的值，你就能量出来，那么你就知道差值了，这个值就可以选择性在其它页面上推广，因为你已经知道预计的回报是多少，比如说做DNS寻址的优化，看了平均回报是5毫秒，铺到20个页面以后，虽然你有100多个页面，但是你铺到最大的20个页面流量以后剩下的就不值得再看了。

最终怎么样了？你有很多优化方案和流量，上来先诊断量出来的预估回报，这个回报就进入度量平台，告诉你这个结果会有多少，如果结果不好你就放弃掉，如果结果好你出一个通用方案再推广，并非对所有上千页面推广，你只是对回报足够大的地方做推广，这就变成足够理性的决策，从现在开始性能优化不再是你牛逼你单挑，你要知道挑了以后是有成本的，要掉血的，如果那个人很烂不值得我掉血，跟他单挑有啥意思？最终结果是做最明智的打法，过去冷兵器时代的战争就变成现代战争，我们海陆空可以一起打，有的人可能做网络端性能优化的，有的人可能是做服务器端性能优化的，这些不是同一行的人是可以比的，我们构建了一个平台使得每个人打的结果实时都看得到。

三、平台设计

这个平台长什么样子？我到阿里的时候阿里已经有完整的系统，就是下图中最上面的Business Domain这个圈子，这已经是完整的电商系统，在完整电商系统之外我们再加了Performance Command Platform，这个系统能让你看到你的性能回报是什么，并且能实时知道性能上是不是有问题，出了问题可以做报警、做监控，这个是覆盖全链路的。我们没有强制每个Business Domain都加到链路里面，因为你要让所有的人上来就相信你的性能优化平台，即使你是美国回来的我也不一定相信你。我们做这个事情根本没有强制，我们先找最容易发力的地方发力，我以前听一个讲座：“你做这个东西避免大风险，从小风险做出来”，这是非常扯淡的，我们做架构师的人要搞清楚要玩就玩大风险高回报的事情，别从什么小风险低回报的事情做起来。如果你玩有大风险的地方你要控制你的风险就找最高回报的时候打，拿出结果以后你才有希望活下来，一旦挂了没用了你弄小风险的东西人家一看觉得这个人没什么水平一点结果都没有，这是很重要的。

我们有这套东西干什么？你在每个域里做度量、分析、实验，把这个实验做好以后再推广，比如在这个域里推广结果好了，大家信服了，然后从一个域到下一个域然后到所有的域哗啦啦地推出来，这是一个持续不断的过程。这里就是我所说的有三板斧的人，很多人各有一板斧，有的人很牛例如做DNS优化，阿里有自己的DNS Team，他们有DNS优化的能力，有些人是玩TCP优化知道TCP优化怎么做，还有些人是做网络端做Ajax的，这些人都可以同时在这平台上玩了，而且玩的过程中是全部平行的过程，因为你的东西跟其他人的东西关系不大，你自己做自己的优化，到时候大家一起打擂，这个结果是完全可以度量的。这个过程就是把整个数据输入到这个系统里，一旦好使就把这个技术在整个系统上做推广。

具体这个设计是怎样的？刚才前面讲的我们有一个打点系统，相当于把数据都采集进来，这是我们本身原有的系统，后面我们做Event Tracking系统埋点，然后做EventCollection做数据搜集，然后有Offline Performance Data Analysis做离线和在线分析，而且我们有小数据库Business DB定义所有的页面之间的关系，然后到了我们网页，网页上会给你看到Reporting、Monitoring、Alarm这些能力，然后最后是我们有Cache会告诉你做同比（周同比、年同比等）或者拉到历史数据时看看结果，这就是我们整个系统。

这个系统长什么样？有些曲线是统计性能的，这条线是我刚刚讲过的性能区间分布的曲线，这条线是转化率的曲线，这边有些实时的东西用来查性能问题的，有时候会发现有些系统性能不一定有问题，但是性能是很好的表征，他一看这个请求哗啦啦地上涨了可能是性能出问题了，所以这套东西做完了之后可以做监控帮助你提升稳定性，尽管目标是为了拿到钱拿到ROI，但事实上还有site-benefit——用来提升系统稳定性。

还有一个东西做什么呢？对全球性的监控，性能来的打点数据是全球覆盖的，任何一个IP，比如说俄罗斯远东地区真实的请求的值是多少可以重新投影到这个世界地图上，你就可以知道任何一点实时的全球的可用性怎么样，网络可用性怎么样，还可以知道这个国家的平均值，这些值还可以跟些业务数据相关，这里有很多插件的功能，比如你可以看到全球的性能和转换率之间的相关性都可以在这里做到。

做了这个东西其实还只是开始，我说过了单打独斗是不行的。实质上培养一个做性能的高手是很花钱的，我们说做网络优化是干什么的，比如哗一下想试验一个什么东西但很多东西是要花钱买来的，比如一条专线得花钱部署，或者盖个pop点、盖机房或在CDN上买流量，这些全部是要花钱的，没有一样免费，而且最怕这些人培养好了他们就跳槽了，你们也不希望发生这些事情。实际上这个事情就把一个人普通的能力最后沉淀到一个系统里去，而且这个系统会给你推你最需要优化的点在哪里，从这里继续往前走。

四、优化实施

优化怎么实施？实施性能优化有成千上百个手段，我就不单独一个个介绍了，我们也不曾把所有的优化手段都用过，但我们试过的真正管用的招数我接下来都会说一下，这些都是我们花钱打出来的。

最有用的招数是动态加速，通过用户把所有动态的内容提到边缘节点，使得动态内容很快到用户手里，同时再把所有页面元素做异步请求，没拿到的内容做异步请求，然后再通过CDN网络返指到源站。几个挑战要注意：

1. 获取用户真实的IP，这变成非常复杂的事情，以前你可以直接拿IP，用户是直接请求你的，现在通过CDN这个请求不一样了

2. 源站的请求拦截，做安全的人都知道，如果之前拦截突然发现来自CDN的请求一大堆，你可能会把它拦截掉，你要想办法把这个跳过，还有跨域调用CDN会调你的东西等等。

接下来的优化手段就不详细讲了，按顺序来讲接下来的优化是静态化+ESI。其实很多优化手段光使一个不好使，我给大家讲的东西是组合拳，得把一套的东西一起用。有些人说动态加速很好用结果自己一试不好用，为什么呢？因为组合拳没有用到，你少了很多东西比如静态内容放到CDN上动态内容却没放，用户看不到价格就不会下单，静态化+ESI就是一个组合拳;

接下来的优化是元素请求合并：

权威DNS优化：

图片DNS优化：

CDN调度优化：说到CDN调度，这个挺有意思的，举个例子，你开始觉得边缘节点放在巴西当然最快，但如果放在巴西之外，放在美国反倒比放在离巴西很近的阿根廷和墨西哥还要快，网络距离和真实能力带宽相比反倒是离得比较远的美国结果更好。

五、Business Impact

最后一部分Business Impact，我们做了这件事情带来了什么？分析性能变得非常快，之前要好几天，现在只需要1分钟，并且还有一个很重要的事情：我们把订单增加了10.5%。一年之内这是白花花的银子相当于白来的（例如一年的GMV是10亿美金，现在变成了11亿），直接回报是非常大的，这个项目给整个AliExpress每年带来了数亿美金的回报。

我们通过第一次量这个值后要做校准，我们预先有预测值，但是预测值要不停的用真实数据校准，我们发现第一次做完了我们的指标量出来发现损耗理论预计值下降36%，再看业务回报，我们的Direct购买率增长13.2%，全站的购买率反倒比Direct购买率增加更多，对网站不熟悉的用户他更受性能影响，所以性能的拉新作用非常大，新用户因为等不上一旦机器性能不好就跳走了，现在有了性能优化以后新用户+老用户总体的转化率增加了26.9%，这是瞬间的转化，随着时间又会降下来，降下来最终的值是10%+，这10%+我们验证了好几次，有时候我们会有抖动等我们把这个优化关掉了，这个转化率又降下去了，我们有一次连续3天关闭了主要的性能优化以后网站的转化率降低了8%，所以我们对这个还是很有信心的。

双11的性能保障流程也是这样的，现在可以突然间做很强的压测，在压测阶段你就知道你期望的性能是什么。

怎么看呢？我们先预计双11期待的性能做离线分析，双11之前的一周是绿色的曲线，双11那天因为扩容了所以性能变好，但是双11那一刻大流量来了性能又降下来了，但是降到我们的期望值，也就是我们之前的平均水平。假设这个值降的太低了，我们就要立即紧急扩容，花钱买更多的带宽，但是我们现在正在期望值上所以不用扩容，我们的流量还是估得非常准的。

我们还可以做新页面的性能分析：

很多人做业务的会指责我们做技术的性能变化导致订单下降，但是我们一看转化率——性能区间分布，这两天曲线的是完全重叠的，也就是性能一丁点都没有变化，看头一天和最近一天的转化率曲线不重合——转化率降低了，但是我们1秒钟后100%告诉你这和性能无关，因为这曲线是完全重叠的，应该是其他业务原因导致的订单变化。

总结一下，因为我也是做架构师开始，首先第一件事情是你的架构能让大家创新，并且让所有人创新。虽然我们做的这个架构很大，但是整个这套系统我自己的团队只投了一个全职的同学，另外两个专门做前端的同学，总共相当于三个人不到半年的时间搭起了整个平台，我们拿到的GMV回报绝对值将近10个点，一套架构真正地Optimalize Team，让大家都很兴奋，能够准确无误测量你的商业回报，这个商业回报会使你一步一步赢得你的客户的信任。

这是我的演讲。谢谢。