阿里资深技术总监:基于大数据的全球电商系统性能优化

郭东白 2016-07-23 09:33:00
本文首先介绍AliExpress电商系统的理论基础,通过页面间跳出率的计算引出全栈优化的思路。然后,介绍AliExpress平台的设计思路和性能优化过程,以及AliExpress使用过的几个有效的优化策略:动态加速、静态化+ESI、元素合并请求、CDN调度优化等。最后,用实例展示了性能优化带来的结果,并对架构设计的过程提出了几点思考和总结。

1整个系统的理论基础



这张图代表流量分布和跳出率的关系。一个用户放弃使用一个网站或者APP的行为叫做跳出。上图中,横轴代表延迟区间,纵轴代表流量分布。绿色的曲线代表顾客来网站或者APP的流量分布,可以发现大部分流量分布在几百到一千毫秒,随着时间延迟的增加,跳出率变高。整个系统计算时,使用转化率公式:转化率=1-跳出率。在发生性能故障的时候,比如有少部分机器出现延迟大大增加的情况,我们会发现高速性能的流量会变少,有很长延时的流量会增加,跳去率也很快地爬升上去。这个过程表明,如果延迟越大,那么延迟跳出率会变得越来越高,即转化率变得越来越低。我们可以把虚线看作是优化前,实现看作是优化后,其中的部分就是优化得到的新的转化率。



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



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



在此基础上,我们可以将其推广到所有页面。一个大的网站可能有数百个页面,比如上图中的两条链路:搜索——详情——订单;商铺——商铺详情——订单。在这种关系下,如果我们把每条链路的跳出率算出来,其实我们就得到了每条链路的理论最大流量,这样我们就知道了最终页面的最大流量。这其实就是一个全栈性能损耗的过程,我们可以知道每个细小的过程对全局的贡献。这对于优化方案的制定非常重要。在做优化方案的时候,我们可以选择一个页面做尝试,准确度量一个页面的回报,这样就可以明确知道一种优化方案对整个系统的贡献,即本次优化对电商系统的订单回报量。


2平台设计



平台是独立于业务领域的。针对不同的业务领域,有不同的优化方案,显示在图中左下部分。平台的功能是:把当前的性能变得可视化;实时度量目前的性能水平;对全链路做一个性能的监控;所有的领域都可以接到这个平台上;做一个全量的度量。平台其实就是将性能优化的回报变成一个可度量的、非常容易看到的结果。在整个试验的过程中,数据是不断积累的,数据会带来准确的度量结果,度量结果则决定是否将优化在全栈进行推广。


3性能优化过程



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


4优化实施



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


  • 动态加速



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



优化后,尽量把动态数据推到边缘节点,这些边缘节点不需要去源站进行请求,只需直接在边缘节点做请求。另外一个优化:请求既可以是同步的,也可以是异步的,可以同时并行请求多个页面内的元素。整体的动态回源的过程是对内容的动态加速。另外一个动态加速的做法是,如果需要回源的话,把这个回源网络的最优化路径交给CDN来决定,CDN会帮助找到目前一条最优的链路来回源。动态加速其实是一系列的优化方案,比如包括内容压缩等。整个过程中也有不少的技术挑战:电商需要知道用户的真实IP;源站防止攻击要做请求拦截等等。


  • 静态化+ESI



用户把内容放到边缘节点上,到了机房内其实也是做一个缓存:如果是动态内容则直接回源到数据库,如果是静态的不命中的内容则通过业务逻辑回源到数据库。请求链路一般是“读链路”,“写链路”会变更db,db被变更消息的消费者消费之后通过业务逻辑更新存入缓存,是缓存内的信息总是最新的。这样的过程相当于用户如果能直接hit到边缘节点就返回(大多数最优的情况),不是最优的情况会hit到缓存层再返回。


  • 元素请求合并




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


  • CDN调度优化



AliExpress在全球的各个国家都有相当多的用户,在巴西是第二大的电商网站,巴西用户可以请求美国的边缘节点,也可以请求巴西的边缘节点。经过测试,巴西用户请求巴西的边缘节点的相对耗时要少一些,可以认为是4个单位,请求美国节点耗时5个单位,但是请求地理位置离巴西近的阿根廷节点需要耗时7个节点。所以得出结论:不能单纯从地理位置来估计请求节点的耗时,以此为基础可以优化CDN调度。

 


5业务结果

 

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

 


6架构思考总结

 


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

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

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

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

作者介绍  郭东白

  • 阿里巴巴AliExpress(速卖通)技术部总监,16年大型软件系统研发和架构经验,对跨大洲、高可用、高流量服务端软件架构和研发有深入研究。

 

经平台同意授权转载

来源:云栖社区

 

 
 
精选专题(点击蓝色标题可阅读全文)

活动预告