网站静态化技术详解
如下图所示的架构方案使用了静态化技术,按照商品维度生成静态化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同步不动
下一篇:软件防火墙与硬件防火墙的比较