本文首先介绍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年大型软件系统研发和架构经验，对跨大洲、高可用、高流量服务端软件架构和研发有深入研究。