我是怎么做详情页静态化的

项目背景：我们是一个资讯时尚媒体app，运营国内和两个海外站点，通过智能dns分别解析到离用户最近的机房提供服务。海内外环境运维、网络、部署结构等不在本次文章中讨论，本文主要讨论下资讯详情页我们是怎么做静态化的。

详情页静态化驱动原因:目前我们资讯内容是存储在CDN上，前端通过csi客户端技术渲染，用户每次访问详情页，前端通过ajax向后端发起一个请求获取资讯详情动态数据，其中也包含cdn存储的内容片段地址url，然后通过返回内容片段url地址从cdn节点上下载内容，最终渲染给客户端，整个过程是串行的，渲染时机比较靠后，最直观的感受用户一直看到一个"菊花"图标一致在loading...

初步方案:优化前端交互结构、后端模版渲染、cache扛峰值、提高访问速度。

前端交互优化：主要是html模版不再从静态服务器下载，依赖cache提前将cdn html片段渲染(本文后面有讲到)，从cache中拉取html模版，解决前端串行请求，提前html加载时机，缩短blank页时间。

后端模版：后端我们技术使用java，结合freemarker很方便处理模版渲染，这里不多说，这里唯一要考虑的就是后端选择的模版要要与前端模版兼容，否则渲染数据的时候会出错。

cache服务器选择：在做cache服务器选型的时候，对比了squid,varnish,trafficserver(ATS,后面简称ATS)

suqid:属于单核架构，现在服务器多核已经普遍，如果要利用多核的优势，需要自己做多进程部署。

varnish:纯内存服务器，需要借助外围手段自己做持久化，且esi支持非常弱

ats:支持持久化，提供了对ESI full feature的支持

由于对于后来动态数据的静态化需要支持ESI，且ATS的性能对比仅次于squid，且京东、新浪微博、小米等大公司都在使用，我们也选择了ATS

静态化之前流程：

静态化之后访问流程：

模版渲染容器流程(用于ats cache服务器回源)：

ats cache方案：

1.cache永不失效，模版需要更新时需要单个push或全量push每个都推一遍覆盖旧模版

优点：不需要准备回源机器，没有短时高峰

缺点：更新速度慢，目前一个页面推送完成需要2ms(测试数据)，当然这个是并发的，时间不是串行的

2.传统回源方案：

优点：缓存清理彻底，速度快

缺点：每台ATS需要手工操作(使用ATS原生命令)，需要准备回源机应对短时高峰

我们使用的是传统回源方案，由于业务还没趋于稳定，模版更新的频率比较高，使用cache永不失效，需要频繁的去手动清空缓存，成本比较高，且用户不能及时看到更新。

总结：做详情页静态化，技术只是实现手段，上面赘述的比较多，要结合业务，明确优化目标，有针对性的优化，对于优化结果要有衡量指标