查看原文
其他

【阿里在线技术峰会】郭东白:基于大数据的全球电商系统性能优化

2016-08-15 中生代技术
摘要:本文根据郭东白在首届阿里巴巴在线技术峰会上的分享整理而成。他首先介绍了AliExpress电商系统的理论基础,通过页面间跳出率的计算引出了全栈优化的思路。然后,他介绍了AliExpress平台的设计思路和性能优化过程。紧接着,他分享了AliExpress使用过的几个有效的优化策略:动态加速、静态化+ESI、元素合并请求、CDN调度优化等。最后,他用实例展示了性能优化带来的结果,并对架构设计的过程提出了几点思考和总结。


整个系统的理论基础


这张图代表流量分布和跳出率的关系。一个用户放弃使用一个网站或者APP的行为叫做跳出。上图中,横轴代表延迟区间,纵轴代表流量分布。绿色的曲线代表顾客来网站或者APP的流量分布,可以发现大部分流量分布在几百到一千毫秒,随着时间延迟的增加,跳出率变高。

整个系统计算时,使用转化率公式:转化率=1-跳出率。在发生性能故障的时候,比如有少部分机器出现延迟大大增加的情况,我们会发现高速性能的流量会变少,有很长延时的流量会增加,跳去率也很快地爬升上去。

这个过程表明,如果延迟越大,那么延迟跳出率会变得越来越高,即转化率变得越来越低。我们可以把虚线看作是优化前,实现看作是优化后,其中的部分就是优化得到的新的转化率。


我们做更深一步的讨论。上图中,红色代表转化率,蓝色代表性能区间的分布。假设我们把性能从a秒压缩到3秒时,转化率的回报是图中绿色的部分。这些回报是怎么得到的?随着延迟越大,转化率越低,由于回报是单调减的函数,所以压缩之后得到的回报就是图中绿色的部分。如果我们知道压缩的时间,我们就可以预测出单个页面上得到的回报,这个回报称为Performance Loss。



接下来,我们进行从A页面到B页面的理论跳出率的计算。如上图所示,A是一个页面,0、1、2、3是它的前序页面,end代表跳出页面。我们发现,出口的跳出率=经过补偿后的所有跳出率-自然跳出率。其中,自然跳出率是指自己因为对商品内容不满意、评价不满意而产生的自然跳出。



在此基础上,我们可以将其推广到所有页面。一个大的网站可能有数百个页面,比如上图中的两条链路:搜索——详情——订单商铺——商铺详情——订单

在这种关系下,如果我们把每条链路的跳出率算出来,其实我们就得到了每条链路的理论最大流量,这样我们就知道了最终页面的最大流量。这其实就是一个全栈性能损耗的过程,我们可以知道每个细小的过程对全局的贡献。这对于优化方案的制定非常重要。在做优化方案的时候,我们可以选择一个页面做尝试,准确度量一个页面的回报,这样就可以明确知道一种优化方案对整个系统的贡献,即本次优化对电商系统的订单回报量。


平台设计


平台是独立于业务领域的。针对不同的业务领域,有不同的优化方案,显示在图中左下部分。


平台的功能是:

  • 把当前的性能变得可视化;

  • 实时度量目前的性能水平;

  • 对全链路做一个性能的监控;

  • 所有的领域都可以接到这个平台上;

  • 做一个全量的度量。


平台其实就是将性能优化的回报变成一个可度量的、非常容易看到的结果。在整个试验的过程中,数据是不断积累的,数据会带来准确的度量结果,度量结果则决定是否将优化在全栈进行推广。


性能优化过程


首先,应该有很多业务模块来收集用户的行为数据(请求时间、建联时间等),然后数据经过采集系统进行处理。处理完的数据有两种分析方式:离线分析、实时分析,区别在于离线的处理量比较大一些。分析的结果都会存在一个业务数据库中,最终会送到cache layer中做追溯和同比。后端会支持很多不同的应用场景,比如报警、监控、报表。


优化实施


其实,世界上在DNS层、网络层、CDN层、业内沉淀有很多优化方案。这些优化方案什么最有效呢?下面列举几个使用过的有效的优化方案:


动态加速


优化前,用户的动态请求都在源站,请求链路是:用户——运营商——源站。全世界都要去源站拿数据,这样的请求链路会非常长,过程相当耗时。



优化后,尽量把动态数据推到边缘节点,这些边缘节点不需要去源站进行请求,只需直接在边缘节点做请求。

另外一个优化:请求既可以是同步的,也可以是异步的,可以同时并行请求多个页面内的元素。整体的动态回源的过程是对内容的动态加速。

另外一个动态加速的做法是,如果需要回源的话,把这个回源网络的最优化路径交给CDN来决定,CDN会帮助找到目前一条最优的链路来回源。

动态加速其实是一系列的优化方案,比如包括内容压缩等。整个过程中也有不少的技术挑战:电商需要知道用户的真实IP;源站防止攻击要做请求拦截等等。


静态化+ESI


用户把内容放到边缘节点上,到了机房内其实也是做一个缓存:如果是动态内容则直接回源到数据库,如果是静态的不命中的内容则通过业务逻辑回源到数据库。

请求链路一般是“读链路”,“写链路”会变更db,db被变更消息的消费者消费之后通过业务逻辑更新存入缓存,是缓存内的信息总是最新的。这样的过程相当于用户如果能直接hit到边缘节点就返回(大多数最优的情况),不是最优的情况会hit到缓存层再返回。


元素请求合并


一个页面中会有很多的子元素,如果单独去请求,则每个请求都是回源的调用,那么每个请求都会占用很多时间(包括TCP建联时间等)。元素请求合并就是指把所有的请求合并成一个,统一提供到服务方,然后服务端再将这些请求分发,然后再统一合并再返回。


CDN调度优化


AliExpress在全球的各个国家都有相当多的用户,在巴西是第二大的电商网站,巴西用户可以请求美国的边缘节点,也可以请求巴西的边缘节点。

经过测试,巴西用户请求巴西的边缘节点的相对耗时要少一些,可以认为是4个单位,请求美国节点耗时5个单位,但是请求地理位置离巴西近的阿根廷节点需要耗时7个节点。所以得出结论:不能单纯从地理位置来估计请求节点的耗时,以此为基础可以优化CDN调度。


业务结果

上述理论的分析,平台的搭建,业务的优化,带来了:整套系统的分析能力提升;过去的优化直接为整个网站带来5.07%的订单;性能损耗明显下降;购买力增强。


架构思考总结



  • 这套系统给大家带来的最大价值是:在做这套架构设计的过程中是不是能有新的创新?通过这个创新能否带来业务价值?

  • 把技术变民主,每个有想法的人都可以去尝试优化,每个人都可以做贡献。

  • 所有做的事情能不能量化?能不能做比较?不同的人对性能优化的贡献都应该能准确度量,这样可以把一个人的力量放大到整个团队的力量。

  • 怎么一步一步赢得这个团队的信任?

首届阿里巴巴在线技术峰会,9位大V演讲整理完整资料请点击阅读原文,含视频+PDF下载!

『中生代技术』


连接技术大咖的桥梁促进科技技术的交流


微信号:freshmanTechnology

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存