http://www.jiangjianan.com/?p=133

malldetail静态化改造概述

2012年malldetail（天猫商品详情应用）为了提高性能和应对双十一大促，进行了静态化相关的性能优化改造。malldetail静态化改造分为三个阶段
1. malldetail优化一期，前期代码优化和整理工作
2. malldetail静态化项目，主要的系统架构改造
3. 旺铺装修CDN异步化改造

阶段一 malldetail优化一期

由于历史原因，malldetail一期项目将集市detail和venus进行了合并，但是只是将代码合并到一个工程中，内部的逻辑还是两套，由于venus的代码比较老，是10年的时候从集市detail分支出来的，存在一定的性能问题。PD的一个商城商品详情需求需要提两份，一份在比普通的detail页面，一份在spu页面，这样导致重复劳动，代码维护成本显著提高。项目中通过将spu与item部分包含的页面模块和后端java代码合并，实现了对前端统一的页面接口，业务上一致的地方只保留一份代码，同时给以后业务上的不一致留下可扩展的空间，从实现上来说是将页面上的各个模块分离，对具体模块重用。提升了maldletail的spu部分的性能45%，并且大幅度的提高了malldetail的开发效率。
项目历时一个多月，2月7日启动，3月26日全量上线。
改造后减少了maldletail应用中的大量冗余代码，代码结构更加简洁，大幅度的提高了malldetail的开发效率。代码工程结构变更如下：

spu detail部分性能有了很大的提高，性能测试结果显示提升了45%。测试结果如下所示

主要优化点：
1. spu detail页面和itemdetail页面的统一
大大减少了前端和开发的工作量，降低了性需求的响应时间。删除了大量的冗余代码，使得代码结构更加清晰。

2. 主流程与肥猪流程业务分离
从业务处理上将非主流程业务从首屏中分离，提高页面响应时间，减少风险点。一些不是detail主要业务的逻辑从HSF接口改为调用异步接口的方式实现。阿拉丁下架宝贝推荐从HSF调用改为异步调用。宝贝套餐模块从HSF调用改为异步调用。提升系统抗压能力，主流程业务和非主流程业务分离。同时，将原先在malldetail的部分异步接口移到了tbskip中，避免不重要的业务量增加时影响到交易主流程。

阿拉丁下架宝贝推荐从HSF调用改为异步调用响应时间

3. vm模版模块化
Detail作为一个水平系统，支持了诸多的垂直业务。很多垂直业务都有自己特殊的页面展示模块。此次重构将原有的页面模块细化，提高了代码的可读性和可维护性，同时也便于更好的重用各个现有模块支持不同的垂直业务。

4. 优化原有逻辑实现 随着时间的推移，搜索和其它依赖系统的时效性大大增加。一部分原先由于搜索时效不够，需要单独查数据库的调用变得不再需要。此次重构中，将SPU页面查询UIC判断用户是否被CC的逻辑去除，直接使用搜索引擎返回的结果。去除了对一个C的批量调用，使得SPU页面整体性能大大提高。

阶段二. malldetail静态化项目

malldetail优化一期完成之后，malldetail的压测QPS为200，线上安全QPS为100。为了适应淘宝商城流量快速增长的需求，每年都是呈几倍速率增长，同时双十一等大促时malldtail流量将瞬间爆发式增长，以当时的系统性能每年增加的机器数量非常巨大，成本非常高，所以开始考虑使用商品静态化方式使用很小的成本就能够带来系统性能的提升，同时应对瞬间流量来临。 为了保证项目进度尽量不影响到日常需求的开发，该项目分为两阶段完成，第一阶段是malldetail应用浏览者无关改造，第二阶段为静态化缓存失效建立。项目4月23日启动，最终发布时间为6月28日，七月中旬流量全部切换到静态化后的架构，完成了malldetail静态化的变迁。

架构概述:
1. 采用nginx最为web服务器层
2. 通过tair保存商品的静态化页面
3. 通过malldetailadmin来主动失效商品，保证主动更新和被动失效方式相结合来保证业务数据的一致性。
4. 通过将变化频繁的数据和与用户个性化需求相关的数据采用异步方式获得来摆正malldetail页面的动静分离。

改造数据依据：天猫商品详情页面热点明显

上述分析数据时采集了线上malldetail应用的access log文件加以统计分析而获得的。通过上述对比分析可以看出，天猫商品详情detail页面的访问中热点商品的访问非常集中，根据多天数据统计，Top1W访问的商品占到了商品malldetail应用总PV的33%。Top20000访问的商品占到了malldetail应用总PV的40%以上，而这些商品知识占到了malldetail应用每天访问商品数的1%不到，热点分布非常集中，如果能够处理这部分热点商品缓存起来而不需要每次请求都动态生成页面，那么就能够极大的提高maldletail应用的整体性能。

改造前的maldletail应用实现方式
malldetail应用对于每次用户请求都是动态从后台各个center取得数据，在过滤、处理相应数据，渲染vm模板，最后将生成的数据发送给请求的用户。对于很多用户来说，生成的页面主要部分都是一致的，而且后台提供的很多数据在很短的时间内更新变化很小。这就为malldetail页面静态化提供了前提条件。

静态化实施后的应用架构图

maldletail静态化系统部署图

各部分名词解释：
LB：负载均衡设备，沿用现有的淘宝主站硬件负载均衡设备。

Nginx：Web服务器。替换现有web服务器apache。通过性能测试结果，将Apache换成Nginx以后大约有8%的性能提升。所有的请求首先去tair中寻找是否有静态化的页面缓存，没有的话将访问malldetail应用动态生成detail页面。

Malldetail：商城商品详情应用。提供即时生成的商品详情页面。静态化之前所有的请求都是访问malldetail应用来动态即时生成html页面。静态化改造以后会将与浏览者相关的功能放到malldetailskip中去异步请求提供。

malldetailskip：malldetial应用中所有的与浏览者相关的功能请求都将放到这个应用中进行异步请求。包含session、库存、邮费信息等。

tbskip：现有malldetai的异步接口。

malldetailadmin: malldetail静态化的缓存控制中心。用于主动缓存失效，缓存信息查询等功能。

Tair：单机缓存，与nginx和jboss部署在一台机器上。用于保存静态化页面。

静态化后成果
1. 浏览者无关改造后malldetail安全QPS由130上升到177左右，性能提高了36.2%。


改造前后非缓存情况下系统性能对比

2. 抽取出malldetailskip应用，将优惠、运费、库存、服务、用户相关信息、交易类型等通过异步封装。
提高了系统的可测试性，原来测试只能通过手工测试，现在可以对malldetailskip进行基于接口的自动化测试。重新梳理的malldetail的业务逻辑，按照水平业务方式进行划分。更加容易的定位问题。

挑战点
1. 跨域问题：tmall.com和taobao.com的cookie同步问题
淘宝的解决方案是基于tbpass的解决方案。需要跨域同步cookie时，用户请求应用，在应用服务器jboss端tbsession filter来判断是否需要同步。同步逻辑如下 
进行静态化改造后缓存的请求直接从tair去除缓存页面后就直接返回，请求不会发送到jboss端，因此原有cookie同步逻辑不适用与现有架构，于是将判断是否需要同步的逻辑移至nginx端。

2. 缓存问题，是使用待机缓存还是使用分布式缓存来存储缓存页面
使用分布式缓存的问题是会造成大量的网内流量，detail页面大小均值150K，如果是分布式缓存的话就需要去其他缓存机器获取页面，这样流量太大，对淘宝内部网络造成影响，所以最终选择使用单机版缓存，jboss、nginx、tair 3者部署在一台机器上。

3. 分桶问题
天猫detail现在的分桶测试功能，可能会要求20%，甚至50%的分桶测试，现在的分桶策略是基于trackId进行hash来决定哪个桶，对于不同的桶在应用端进行不同的逻辑处理，在请求中无法判断落在什么桶，也就是说在nginx服务器端无法判断。 解决方案是将判断的逻辑放在客户端js中判断，当浏览器发现返回的页面是静态化页面的时候就是就对trackId进行hash来计算是否落在测试桶中，如果是的化就在发起请求中加特殊标记，直接访问应用动态生成detail页面。 这种方式的一个问题是分桶的测试桶的流量不会走静态化页面，这样的话会有性能损失。所以需要严格控制分桶流量的切换，原则上不应超过10%。

4. 商品失效问题。
当用户或者小二编辑与商品相关的信息时，可能导致缓存的页面过期，需要对这部分商品页面进行失效。 采用主动失效和被动失效相结合的方式来保证数据的实时性和一致性
1) 被动失效：通过设置商品大约半个小时失效，这样可以保证在主动失效机器出故障的时候仍然能够通过用户仍然能够获得正确的详情页面。

2）主动失效：人工触发单一商品或者单机缓存失效，应对线上问题排查处理。

3）IC更新失效：通过接受IC的notify消息来获得失效信息。现在一天平均有2亿的notify消息，这个是全网的，该消息可以区分是集市或者是商城的。商城的商品数量大概集市的5%左右。IC提供了notify消息能够判断B卖家商品，并且能够根据变更类型（下架、库存变更等）提供特定通知。同时对于大型秒杀商品需要跳转到集市秒杀页面，接受diamond的大型秒杀消息进行失效。

阶段三 旺铺装修CDN异步化改造

静态化改造后仍然有问题，detail页面过大，统计平均为150K大小，将这150K的页面存入tair中，对于40G内存左右的tair缓存服务器，大约能存放26W的item，线上的数据缓存命中率大致在40%左右，而且页面在传给浏览器之前需要在nginx端进行gzip压缩，测试统计如果页面过大的话，gzip压缩非常消耗cpu性能，所以减小页面大小势在必行。

现在天猫商品使用的线上装修占比，统计装修数据大致占到线上数据的40%-50%左右，如果这部分直接放到CDN上面而不走malldetail应用的话，就能够减小50%放入tair的页面大小，相应的会增加放入tair的商品数量，从上面统计可以看出，增加放入tair的商品数量的话可以提高缓存命中率。如果这部分页面大小能够节省下来的话，将能够更好的提高malldetail静态化系统的gzip的压缩性能，提高缓存命中率，提高页面的响应时间及用户体验。

原先的旺铺处理流程：每次请求都会从旺铺tair中去获取旺铺信息，旺铺页面片段造成了静态化缓存利用率不足。

旺铺CDN化以后的流程：浏览器请求malldetail返回没有包含装修信息的页面，然后去取CDN返回装修信息，CDN将源地址设置为malldetail，当CDN上面没有相应店铺的装修信息时，去malldetail获取旺铺装修信息，并存入CDN上面。这样可以大幅度的减少的流量为CDN替换，CDN的流量成本会比主站流量成本低，大约会减少50%左右的malldetail出口带宽。

失效处理
现有的淘宝CDN的机制不能很好地确保过期旺铺页面能够很好地失效删除，所以采用以下两方面做失效处理
1、采用加时间戳的方式来处理旺铺变更问题。
用pid、sellerId以及时间戳releaseTime来标明从CDN上请求的旺铺装修内容。如果装修信息有变，从DesignCenter的releaseTime也将随之而变，当第一个访问连接进来时，CDN将回源到malldetail的fetchDc接口获取变更后的旺铺内容并放到CDN上，以后的访问将取到这个新记录；
2、在服务端设置FetchDc接口的浏览器缓存时间来解决CDN过期信息失效
由于fetchDC接口是供给CDN调用的，因此实质上设置的是CDN的缓存时间到缓存时间后CDN会删除这条记录
3. 旺铺失效消息
卖家编辑旺铺以后mdadmin会接受到旺铺变更notify消息，然后通过搜索查询相应卖家的商品id，对malldetail的tair缓存进行整体失效。

用户体验改进
在旺铺异步CDN方案中，当使用前端异步方式加载旺铺信息时发现，如果首屏使用异步方式，用户体验非常差，店铺头和左侧卖家档案能感受到明显的显示延迟。 因此使用了同步方式来渲染这两部分内容。

容错处理
容错处理有两方面： 1、取不到旺铺装修信息：跳往faultRate.vm页面，自己渲染左侧卖家信息和店铺头，摒弃其他的装修模块(注意：页面div节点和正常detail页面有点不一样的)； 2、取不到店铺头和左侧卖家信息：使用shopArchive.vm模板同步填到相应div中。shopArchive.vm模板的渲染结果会被放到Tair中供下次读取

开关控制
在DetailSwitcher类中的开关和变量配置信息： 1、dcAsyn：是否走异步化接口，默认为true 2、dcCacheTime：店铺装修异步化浏览器缓存时间，默认1天 3、shopArchiveCacheTime：旺铺卖家信息缓存时间，默认4小时 4、shopArchiveForTair：卖家信息是否走tair，默认为true

静态化架构应对双十一

容量规划
平时malldetail是2亿左右的PV，QPS在6000+左右，本次双十一前预估峰值QPS在11W左右，所以按照现在malldetail机器的处理能力（malldetail QPS 1200，80%命中率，malldetailskip QPS 500）做了扩容。由于双十一期间卖家不能编辑商品，所以对于malldetailamdin没有扩容。
扩容后的机器状况为：
Malldetail：20台（实体机）-> 96台（实体机）
Malldetailskip：38台（虚拟机） -> 266台（虚拟机）
Malldetailadmin：4台（虚拟机）->4台（虚拟机）

服务降级
1）双十一优惠方案不依赖UMP，使得双十一优惠价格和卖家申报优惠价格直接从IC中取得。同时大促商品不走delivery，减小了对delivery的压力。
2）双十一高峰前关闭了部分不太重要的功能。（提前降级）
3）为了应对双十一高峰时malldetail依赖的后端系统变慢而导致的线程超时而产生load变高，对部分后端系统的依赖做了降级开关，在双十一当天发现后端系统变慢后及时关闭。

Malldetailskip弱依赖。
通过弱依赖保证了当后端部分系统不可用时能够仍能够尽力保证detail系统的稳定性。比如IC双十一凌晨出了问题，malldetail仍能够访问。

安全准备
1) TMD限流（限流条件：detail->1600qps skip ->500qps）
2) JBoss限流。使用stable switch对整个请求和各个依赖的系统都做了限流。当malldetailskip部分请求被限流时候直接使用弱依赖方式，保证detail页面仍然能够正常访问。

过程回顾
Malldetail系统数据

QPS从10日下午6点开始攀升，11日0点是到达中的最高峰，由于0点时哈勃故障，0点左右十几分钟的qps日志没有统计。通过单机查询后大概在600+左右，部分机器到达780。

从统计结果上来看，由于使用了静态化，大部分访问请求命中缓存（0点是缓存命中率在80%左右），所以detail的rt很平稳，一般不超过25ms。

由于使用了静态化，malldetail的load也非常低，一般不超过1.5（安全值是15），离安全值非常远。

热点数据
热点商品跟踪，统计了前一个小时的热点分布情况（单机统计），如下
单台机器估算（00:00-00:15）15分钟单台热点统计
总PV 549249，总商品数191080
统计结果top 5w的商品占到总的pv量的71.03%，相对于所有的商品来说，热点还是非常集中的。。

静态化缓存效果明显，双十一当冬天的缓存命中率普遍在65%左右，最高峰达到80%。