优化实施
其实，世界上在DNS层、网络层、CDN层、业内沉淀有很多优化方案。这些优化方案什么最有效呢?下面列举几个使用过的有效的优化方案：
动态加速
优化前，用户的动态请求都在源站，请求链路是：用户——运营商——源站。全世界都要去源站拿数据，这样的请求链路会非常长，过程相当耗时。
优化后，尽量把动态数据推到边缘节点，这些边缘节点不需要去源站进行请求，只需直接在边缘节点做请求。
另外一个优化：请求既可以是同步的，也可以是异步的，可以同时并行请求多个页面内的元素。整体的动态回源的过程是对内容的动态加速。
另外一个动态加速的做法是，如果需要回源的话，把这个回源网络的最优化路径交给CDN来决定，CDN会帮助找到目前一条最优的链路来回源。
动态加速其实是一系列的优化方案，比如包括内容压缩等。整个过程中也有不少的技术挑战：电商需要知道用户的真实IP;源站防止攻击要做请求拦截等等。
静态化+ESI
用户把内容放到边缘节点上，到了机房内其实也是做一个缓存：如果是动态内容则直接回源到数据库，如果是静态的不命中的内容则通过业务逻辑回源到数据库。
请求链路一般是“读链路”，“写链路”会变更db，db被变更消息的消费者消费之后通过业务逻辑更新存入缓存，是缓存内的信息总是最新的。这样的过程相当于用户如果能直接hit到边缘节点就返回(大多数最优的情况)，不是最优的情况会hit到缓存层再返回。
元素请求合并
一个页面中会有很多的子元素，如果单独去请求，则每个请求都是回源的调用，那么每个请求都会占用很多时间(包括TCP建联时间等)。元素请求合并就是指把所有的请求合并成一个，统一提供到服务方，然后服务端再将这些请求分发，然后再统一合并再返回。
CDN调度优化
AliExpress在全球的各个国家都有相当多的用户，在巴西是第二大的电商网站，巴西用户可以请求美国的边缘节点，也可以请求巴西的边缘节点。
经过测试，巴西用户请求巴西的边缘节点的相对耗时要少一些，可以认为是4个单位，请求美国节点耗时5个单位，但是请求地理位置离巴西近的阿根廷节点需要耗时7个节点。所以得出结论：不能单纯从地理位置来估计请求节点的耗时，以此为基础可以优化CDN调度。
业务结果
上述理论的分析，平台的搭建，业务的优化，带来了：整套系统的分析能力提升;过去的优化直接为整个网站带来5.07%的订单;性能损耗明显下降;购买力增强。
架构思考总结
这套系统给大家带来的最大价值是：在做这套架构设计的过程中是不是能有新的创新?通过这个创新能否带来业务价值?
把技术变民主，每个有想法的人都可以去尝试优化，每个人都可以做贡献。
所有做的事情能不能量化?能不能做比较?不同的人对性能优化的贡献都应该能准确度量，这样可以把一个人的力量放大到整个团队的力量。
怎么一步一步赢得这个团队的信任?