网站静态化技术详解
如下图所示的架构方案使用了静态化技术，按照商品维度生成静态化HTML。该方案的主要思路介绍如下。
· 通过MQ得到变更通知。
· 通过Java Worker调用多个依赖系统生成详情页HTML。
· 通过rsync同步到其他机器。
· 通过Nginx直接输出静态页。
· 接入层负责负载均衡。
该方案的主要缺点介绍如下。
· 假设只有分类、面包屑变更了，那么所有相关的商品都要重刷。
· 随着商品数量的增加，rsync会成为瓶颈。
· 无法迅速响应一些页面需求变更，大部分都是通过JavaScript动态更改页面元素。
随着商品数量的增加，这种架构方案的存储容量遇到瓶颈，而且按照商品维度生成整个页面，会存在例如分类维度变更就要刷新一遍这个分类下所有信息的问题，因此，我们又改造了此架构方案，按照尾号路由到多台机器（见下图）。
此方案的主要思路介绍如下。
· 容量问题通过按照商品尾号做路由分散到多台机器，按照自营商品单独一台，第三方商品按照尾号分散到10台。
· 按维度生成HTML片段（框架、商品介绍、规格参数、面包屑、相关分类、店铺信息），而不是生成一个大HTML。
· 通过Nginx SSI合并片段输出。
· 接入层负责负载均衡。
· 多机房部署也无法通过rsync同步，而是使用部署多套相同的架构来实现。
该方案的主要缺点介绍如下。
· 碎片文件太多，导致如无法rsync。
· HDD做SSI合并时，高并发性能差，此时我们还没有尝试使用SSD。
· 模板如果要变更，则数亿件商品需要数天才能刷新完。
· 到达容量瓶颈时，我们会删除一部分静态化商品，然后通过动态渲染输出。动态渲染系统在流量高峰时会导致依赖系统压力大，抗不住。
· 还是无法迅速响应一些业务需求。
我们的痛点包括以下两点。
· 之前架构的问题存在容量问题，很快就会出现无法全量静态化，还是需要动态渲染；不过，对于全量静态化，可以通过分布式文件系统解决该问题，这里介绍的方案没有尝试。
· 最主要的问题是随着业务的发展，无法满足迅速变化的需求，以及一些变态的需求。
本文地址：网站静态化技术详解 _http://longshunzhuangshi.com/wangzhanxitong/31.html 本文tag标签：静态化技术
上一篇：数据量大时JIMDB同步不动
下一篇：软件防火墙与硬件防火墙的比较