阿里巴巴网站架构师周涛明：跨境网站的优化与挑战

随着公司业务的扩展，越来越多的企业实现了服务的全球化，但是由于各个地区网络差异，跨境网站的可用性以及性能问题越来越凸显，在今年 QCon 上海的知名网站架构专场上，来自于阿里巴巴的周涛明将会以“跨境网站性能优化挑战和思路”为主题分享阿里巴巴的实践经验。

我们今天也有幸邀请到了阿里巴巴网站架构师周涛明，听他谈谈阿里的一些技术实践以及将要在QCon 上所分享的内容。

InfoQ：简单的介绍一下自己目前负责的工作，以及在自己相关领域做过哪些方面的工作，关注过什么？

周涛明：我目前主要负责阿里巴巴国际站性能优化领域。性能优化是一个完整体系，也是一个生态体系。在生态体系中，有不同的子系统和角色，性能优化之后，随着需求的堆砌，原来性能优华后的成果一般都难以维持，所以性能优化之后一般需要有性能保障子系统，在国际站性能优化体系建设过程中，不仅仅进行了多项具体的性能优化工作，而且为了保障性能优化的成果，建立了性能基线系统，基线系统是对性能的关键指标，如 DNS 解析时间，StartRender、首屏加载时间、Full load 时间、服务端响应时间、应用峰值 QPS 建立了基线，当超过基线的 20%，系统会报警到相关页面的负责人这里，负责人会关注并修复问题。同时在性能优化生态体系中，仅仅有基线是不够的，当系统帮助发现有问题，但是不知道问题出在哪里了，为了快速定位到问题，需要有性能诊断子系统。性能诊断前端部分，我们建立了前端性能服务中心，提供数据服务，模拟浏览器行为访问我们自己的站点，将影响性能的一些因素例如请求数、Dom 节点数、html 大小、图片大小和数量监控起来，当性能变差时，系统会自动给出可能影响性能的因素，列举出来，这样定位问题的效率就简单得多，服务端我们将 URI Profile 的监控做起来了，一个典型的页面流程，调用了哪些方法，这些方法耗时趋势是什么样子的，当 RT 和 QPS 超过基线设定时，通过 URI profile 监控可以知道哪个方法出问题，通过这种方式，能够快速进行性能的定位和专门的优化。

InfoQ： 你目前关注的重点是什么？

周涛明：我目前关注的重点是让性能优化生态体系能够高效运转起来。毋庸置疑，性能优化体系运转起来，首先要进行性能优化，所以性能优化本身是重中之重，对一个新网站来说，性能优化主要关注在业务发展、用户体验，最后才是成本问题。例如对一个跨境电子商务网站，面向的是全世界的买家，流量的引入主要依托各种搜索引擎的收录，通过引擎的推广和搜索，引入流量，爬虫爬取量的多少，在一定程度上影响流量的流入，所以对于搜索引擎比较关心的页面来说，该页面的后端响应时间尤其重要，所以 RT 从 50ms 变成 40ms，节省 10ms，对用户的真实体验其实是完全可以忽略不计的，但是对爬虫爬取量来说，可能就是 20% 的提取量提升，所以针对爬虫类的网站，优化 RT 实际上促进业务的上涨。对于前端性能提升，其实并不复杂，用一些传统的方法实际上可以达到很好的效果，刚才提到了生态体系，其实人为主性能优化体系的核心角色，实际是起到非常关键的作用，还是相信那句话，只要去做了，总会有些收获和你意想不到的问题存在，性能优化本身还是有些规律可以遵循的，找到这些规律并实践非常重要，实践过程中会遇到很多问题。今年的 Velocity 大会上，淘宝、腾讯、百度分享关于性能优化的东西，其实和我今天谈到的性能优化体系是一样的，他们会也会遇到相同的问题，在解决问题过程中，会得到很多体会，而这种体会和实践是提高和深入是性能优化能力提升的根本。

InfoQ： 感觉在过去一年，自己接触到的、关注的领域发生了什么变化？

周涛明：过去一年，业界技术创新应该不是特别多，也有一些变化：

1. Java 重回编程语言第一宝座。Java8 由于存在安全漏洞的问题，原本计划 13 年 9 月份发布，推延到明年 3 月，Java8 开始支持 Stream 集合类，支持 fork 和 join 并行方式进行任务的分解和加速处理过程，非常值得期待。
2. Java 启动新的项目 Nashorn ，开发人员可以在 Java 代码中写 JavaScript。
3. 使用 tengine 的网站达到全球网站数量的千分之一，Tengine 的高并发处理能力和越来越丰富的模块支持，受到越来越多工程师的欢迎。当然 Tengine 是基于 Ngnix 改装的，Ngnix 同样值得尊敬
4. Taobao Tsar 工具开源，监控的多维度支持更加丰富
5. Google 推出免费的 cdn 加速服务——Google’s PageSpeed Service，
6. Google 推出的 SPDY 协议，目前还处在实验阶段。

InfoQ： 我们知道雅虎有著名的14条军规，是否可以谈下在阿里你们所总结的实战经验？

周涛明：前端性能优化，按照经常使用的频率和效果上来看，在前端性能优化上经常用到的点如下：

第一，减少http请求是非常有效的措施

减少 http 请求是非常有效的性能优化手段，例如常用的 css sprite 技术将背景图片进行合并来减少网络开销，阿里巴巴主页就用到这个手段，合并 ajax 请求，也是减少 http 请求的手段，请求的发起和接收，比一个请求的网络开销要大得多，从目前线上的效果可以看到，减少 http 请求数是非常有效果的方式。

第二，减少重定向

重定向意味着两次连接，用户在访问一个页面时，意味第二次需要重启发起连接（keepalive 会重用连接），第二次请求由于存在网络开销，会出现短暂的白屏，在跨境电子商务网站来说，由于各个地区的网络差异非常大，所以网络的开销是非常大的，在阿里巴巴跨境网站业务，会针对新老用户，做不同的页面展现逻辑，重定向是非常普遍的，也很容易被开发忽视，在某种程度上来说，重定向编程相对容易，所以在下单关键流程上出现了非常多的重定向的跳转，在 Google Analysis 上面可以明显看到重定向时间达到 1s 以上，去年做了一次全面的整改，把重定向全部去掉，改成 forward 内部跳转，减少网络开销，成效十分明显，关键页面性能 onload 时间减少 1s 左右。

第三，预加载

预加载是预见性用户行为的性能优化方式，根据用户的操作行为，在 CPU 处于闲置状态时，进行预先的资源加载，当应用达到预测的页面时，部分资源已经预先加载，所以性能就提升了。在阿里巴巴 B2C 网站 Aliexpress.com 的 Detail 页面进行性能优化时，就在用户搜索页面进行预先加载用户搜索的前 6 个商品，目前支持的浏览器有 Chrome 和 Firefox.

其实超级简单了，就是加一个类似的链接，href 可以是任何资源，HTML， JavaScript， CSS， 图片：

复制代码

 
<link rel=”prerender” href=”" > (Chrome)
<link rel=”prefrech” href=”" > (Firefox)

第四，尽量减少cookie的大小

大量的 cookie 会加重请求的发送网络开销，http 规范对头是不压缩的，对于跨境网站来说，网络差异非常大，所以过大的 cookie 的网络 latency 是非常大的，当然为了满足业务需求，cookie 的大小大也没有更好的方法，所以只能尽量减少，毕竟满足业务需求前提下，才能满足性能。

第五，延迟加载

延迟加载，将资源延迟到需要的时候的加载，例如 detail 页面，相关产品推荐，当用户浏览更多的信息往下拉动滚动时，才进行加载，异步加载可以大幅减少对后端资源的使用，在需要的时候加载，是资源合理使用常用的方式，但是也带来一个问题，当往下拉才去加载，如果性能不够好，用户的体验其实是不好的，“菊花”转动的时间会比较长，同时异步加载对前端性能的作用也是非常明显的，渲染的节点数量大幅减少。

第六，Ajax异步化减少DOM的节点数，加快渲染时间，first byte时间

异步化通常是首屏加载优化，加快 dom 渲染速度（减少 dom 数量），异步化带来了 firstbyte 性能提升，用户感知页面有内容更快了，异步化同样也会带来用户体验的问题，大量的异步化，js 的阻塞渲染（下载）的概率越大，所以适度的 ajax 很重要，用户体验是第一位的。

第七，CDN加速

Cdn 加速其实是大型网站都要用的手段，cdn 消除了地区间的用户访问差异，让用户就近访问，cdn 需要注意的是需要尽量减少回源（不命中 cdn），资源的过期时间尽量长，合理的 cdn 架构也很重要，回源之后，文件处理过程也很重要，坚持一个原则，那就是尽量短的 latency。

第八，延迟渲染

异步加载带来的问题是，需要发起请求到服务器拿数据，如果网络条件差，用户体验影响是非常大的，延迟渲染就是在需要的时候渲染 dom，渲染 html 片段。例如搜索 list 页面，有 32 个搜索结果，前 6 个商品（首屏），是同步渲染出来的，其它的商品列表的 html，用 textarea 进行包装，浏览器会把这种带有 text area 标签的 html 片断当做一个节点来看，所以渲染速度大幅提高，这种方式是提高首屏的渲染速度，达到了性能和用户体验的平衡。

第九，DNS预解析

Dns 解析容易被人忽视，对于跨境网站，local dns 位于世界各地，离机房的 dns server 是非常远的，解析成本实际上是非常高，特别是域名多的情况下，提前预加载 dns，相当于在 a 页面提前把 b 页面的所有的域名提前加载进来，这样到达 b 页面时，dns 几乎不需要解析了，dns 解析的提前加载，提高了首屏 full load、firstbyte，用户体验明显增加。

第十，js放在头部阻塞浏览器并行渲染

JS 尽量不要放在上面，尽管现代的浏览器已经做了充分的优化 - 大部分情况下，已经不阻塞并行下载了，但是在很多情况下仍然会阻塞并行渲染

InfoQ： 看到你对SPDY协议比较关注，如果畅想下这个技术得以普及，会对你现在负责的系统会有哪些影响？你怎么看待这个技术？

周涛明：Google 的 SPDY 协议是 HTTP 的增强，它主要出发点是为了减少网络延迟，ngnix 已经支持，个人觉得它最大的几个优点:

1. 多路 IO 复用 http 协议的并行下载是利用客户端和服务端建立多个连接进行并行资源的下载，创建连接的开销和维护连接的成本是不低的，spdy 运行一个连接，并行进行资源的下载，并且可以对请求划分优先级，对 css 等重要资源安排更高的优先级，在连接处理的效率应该说有比较大的增强。
2. 对 HTTP 请求头和响应头的压缩 这个在 cookie 非常大的情况下，非常有用，压缩头部能够带来更小的网络延迟
3. 冗余的请求头信息 在 http 协议的交互过程中，user-agent，还有其它的很多信息每次传输基本上不会变，这个细节的优化同样是非常好的。

但是 spdy 协议和 http2.0 协议并没有达成一致，spdy 限制必须使用 ssl，这个是个问题，可能这个是限制 spdy 协议发展的限制之一，毕竟不是所有的网站都需要那么高的安全标准。

Spdy 目前还在实验阶段，加上和 http2.0 协议的不一致，所以对 spdy 协议还需要观察，tengine 是基于 ngnix 的，我们现在网站大多都是基于 tengine 的，一旦 spdy 准备就绪，我们随时需要准备着，这个是变革性意义的协议，也希望 http2.0 协议早日和 spdy 协议求同存异，互相汲取优点，让 http 真正快起来。

InfoQ：对于一个业务刚开始起步的系统来说，性能优化的时机和度怎么把握？从你的实际经验出发，推荐大家多从哪几个角度出发做优化？要尽量避开哪些方面（比如优化难度大，性价比不高的）？

周涛明：性能优化有一点非常重要，那就是顺势而为，这个势其实就是业务本身的发展趋势，例如需要提前对业务的发展数据作出预估，商业上一般都有这个数据，例如网站半年以后的增速大概是 3 倍，那就需要提前考虑 3 倍的访问量增加对用户体验对机器成本，对业务有没有可能的阻碍。业务发展初期，为了促进业务的发展，需要满足各种需求，例如提升用户购买率的需求，各种转化率的需求等等，基本上大型的网站的发展过程都是在满足功能的情况下，等网站发展到足够大的时候，才会花更多的精力去考虑性能的事情，例如为了减少机器成本，需要做单机峰值 qps 提升的性能优化，个人认为下列情况下需要做考虑性能优化：

1. 优化到什么情况是最合适的？

这个是根据网站的特点来，每个网站的转化率，流量和用户的特点是不一样的，在一定的性能情况下，性能的提升，一定会转化成对商业数据的影响上，这和理论上的数据还是有些差距，性能优化无极限，把商业数据拿出来看，可以度量我们什么时候才算是把性能优化的事情可以告一段落，例如我们曾经做过测试，将首屏时间优化到 3s 以内，发现转化率和流量处于停滞状态，这个时候性能上发力其实是无济于事的。

2. 优化从哪几个角度优化？

网站首要的考虑的是对用户体验的影响，影响网站的体验，性能只是一个方面，纯从技术上来说，个人认为可以从以下几个角度：

2.1. 确定重点

优化对用户体验影响大的点，例如，detail 页面，需要确定哪块是重点，例如首屏，关键数据区的优化。重点关注用户关键流程上的点，对于电子商务型网站来说，购买流程中的页面时关键的。在时间有限的情况下，理清重点很重要。

2.2 确定相关重点页面的关键性能指标

• 首要考虑用户能够感知的指标，例如首屏加载时间，如果没有首屏，需要考虑分屏。
• 关注用户操作过程中关键点的性能指标，例如跨境网站的物流运费计算，一定要足够快，用户最好是能够很快看到内容，而且是关键内容。

2.3 需要常态化优化的跟踪机制

性能优化不是一次性的行为，一定要有常态化的机制去保障，例如我们是把关键页面的性能建立了基线，优化了之后，把优化之后的结果作为基线，超过基线的多少，需要有机制保障触发再次优化。所以性能优化一般需要有强有力的监控系统，对于前端来说，可以结合前端性能监控系统，可以自己做，也可以借助第三方。对于后端，可以结合后端的关键性能指标例如 RT，QPS，对这两个最基本的关键指标建立基线，超过多少，触发优化。

2.4 需要有完善的配套的性能诊断体系

个人还是认为，性能优化是一个体系，性能优化不是一次性的东西，是一个完整的生态体系，这个体系包含，做性能优化的人，性能基线体系 - 保障性能优化成果，提升性能优化效率的性能诊断系统，和流程机制保障。性能超出了基线设定，需要快速告诉开发人员那里出了问题，例如后端一个关键页面的 RT 从 100ms 变到 200ms，仅有整个页面的 RT 不能高效低排查问题，所以最好是有方法级别的监控，告诉开发人员，哪里的方法有衰减。对于前端，可以把影响前端性能的关键数据例如 http 请求数，页面大小，图片大小和数量等监控起来，进行数据分析，建立基本的诊断系统，非常有必要。

3. 应该避免哪方面的优化？

一， 需要防止伪性能优化

伪性能优化指的是不考虑用户体验，只注重看似重要的性能指标而做的性能优化，这是掩耳盗铃式的优化，例如关键页面的首屏，用户看到的关键数据需要等待很长时间，看起来首屏是很快，但是关键数据需要等待，其实对用户体验提升完全是没有用的。所以 ajax 的异步优化要特别注意这一点，非常容易造成用户体验不佳。

二， 需要防止过度优化

过度优化的特征是投入产出已经不高，而且效果非常不明显，其实性能的调整和提升，会造成一些负面的问题，性能提升，往往需要通过架构上的调整，一旦架构上调整、排查问题、系统的可维护性都会变差，看投入和产出：为了用户体验，把负责留给网站自己来解决是权衡；为了不必要的性能，引起架构的可维护性变复杂，是没有必要的。下列情况属于明显的过度优化：

• 用户体验无明显提升，用户没有感知
• 投入大，收效小，例如系统第一次优化 qps 从 100 提高到了 400，第二次优化从 400 提高到 402，节省机器 2 台，投入 30 人日，这个属于明显的不合理的性能优化。

需要防止过度优化！

InfoQ**：简单介绍一下你计划在本次QCon上分享的话题？**

周涛明：跨境网站的业务特点是买家是来自于世界各个地区，网络环境差异大，而卖家来自于国内，既然跨境了，在外部环境上，需要考虑的东西会比较多，例如网络被墙等问题，使用 cdn 加速时，由于加速地点非常分散，所以资源加速的效果可能没有像一个地区那样那么好，一旦回源，资源访问的 latency 将会非常大，在处理这些问题过程中，需要充分考虑成本，有时候必须要做些舍弃，把最优的资源用在最需要的地方。另外一个问题是，买家分散，为了让买家了解并通过网站购买商品，首先要让买家知道我们网站在哪里，而对一个新兴电子商务网站而言，需要靠搜索引擎的流量导入来提升网站的访问量，为了让引擎爬取到页面更多的内容，我们的网站的内容需要同步输出给爬虫，相对 ajax 的异步来说，关键性能指标的性能会比后者差很多，例如商品 detail 页面，为了让爬虫爬取到推荐商品的内容，需要在后端将推荐商品列表信息同步输出，推荐商品列表这块的 html 是非常大的，如果在服务端同步输出，无论是 first byte、start render，还是 onload 时间，rtt 都比 ajax 异步化推荐要大，所以跨境网站的另外一个特点是对爬虫有比较重的依赖的，如何在业务促进和优化体验做到平衡是一直以来我们想突破的东西。所以本次分享重点 focus 在跨境网站优化的两个点上，一个是爬虫的依赖对性能优化手段的影响以及如何去克服，另外一个是具有跨境特点的 cdn 架构，是什么样子的，以及我们碰到了什么问题，以及如何解决的。

InfoQ： 为什么你认为这个话题是重要的、值得关注的？听众可以从这个分享中获得什么？？

周涛明：这个话题比较新颖，其实解决方案并不是显得十分有难度，不需要看起来那么高难复杂的技术，但是确实能给人带来新的思路和一些不为人知的一些事实。例如 Google 爬虫兼容方案是一种 Google 推出的爬虫兼容方案 - 它允许对爬虫访问同步，而对用户访问可以采用异步的方式，它只需要你告诉爬虫的快照页面在哪里就可以了。实际上不仅仅是 Google 支持这种方式，俄罗斯搜索引擎 yandex 也支持这种方式，注意，如果你不遵循它的规范，一旦爬虫发现爬虫访问的页面和真实用户的页面不一样，它会认为你是在作弊，页面就会有降权的风险，页面在搜索引擎搜索结果排名会大幅降低，seo 流量将会受到很大的影响。

关于周涛明

周涛明，阿里巴巴网站架构师（ @周涛明）， 11 年加入阿里巴巴，在阿里巴巴之前，曾在思科工作 5 年，目前负责国际事业部性能领域，专注国际事业部 B2C 国际技术部的性能优化工作，网站性能优化领域专家，在大型网站性能架构有丰富的经验，致力于性能生态系统和跨境电商网站性能解决方案的研究，对性能相关的知识体系如操作系统内核，网络，服务器性能调优，架构优化，前端相关性能知识体系有浓厚的兴趣。未来两年的愿望是想把性能方面的经验和实践，汇成一本对一线工程师有实际帮助的书籍。业余时间他喜欢羽毛球运动，坚持 5 年每周两次羽毛球运动从没有间断过。