1、概述

在大型网站中，如京东和当当商品详情界面，看到的页面基本上是静态页面。为什么都要把页面静态化呢？把页面静态化，好处有很多。例如：访问速度快，更有利于搜索引擎收录等。

目前主流的静态化主要有两种：
（1）一种是通过程序将动态页面抓取并保存为静态页面，这样的页面的实际存在于服务器的硬盘中；

（2）另外一种是通过WEB服务器的 URL Rewrite的方式，它的原理是通过web服务器内部模块按一定规则将外部的URL请求转化为内部的文件地址，一句话来说就是把外部请求的静态地址转化为实际的动态页面地址，而静态页面实际是不存在的。这两种方法都达到了实现URL静态化的效果，但是也各有各自的特点。

（3）还有一种是把页面划分成子数据块，每个数据块可能是一个inc文件，也可能多个数据块包含在一个inc文件中。具体的数据块划分根据页面的业务结构来处理。比如：网站头尾等公共数据块可以独立成一个文件。

2、实时生成静态页面

使用freemarker实现生成静态页面，将页面的实际存在于服务器的硬盘中，然后通过nginx反向代理服务器访问资源；

将动态页面转化为实际存在的静态页面这种方法，由于静态页面的存在，少了动态解析过程，所以提高了页面的访问速度和稳定性，使得优化效果非常明显。所以这种方法被广泛采用。但是它的局限性同样存在。对于大型网站而言，这种方法将带来不可忽视的问题。
一、由于生成的文件数量较多，存储需要考虑文件、文件夹的数量问题和磁盘空间容量的问题；
二、页面维护的复杂性和大工作量，及带来的页面维护及时性问题，需要一整套站点更新制度。

虽然静态页访问速度快，但实现起来毕竟还是比较麻烦了，维护也是一个麻烦事情。如果您的站点更新速度快那么就需要在你的后台数据更新部分调用相应的createHTML方法实时的生成静态页面。如果更新速度不慢可以在后台手动更新或者利用操作系统的定时任务功能去执行你的静态页面生成程序。

3、实战商品详情页面静态化

输出文件的名称：商品id+“.html”
输出文件的路径：工程外部的任意目录。
网页访问：使用nginx访问网页。在此方案下tomcat只有一个作用就是生成静态页面。
工程部署：可以把生成页面服务部署到多个服务器上。
生成静态页面的时机：商品添加后，生成静态页面。可以使用Activemq，订阅topic（商品添加）
这里写图片描述

（1）商品添加时，发送topic消息给消息队列服务器；
（2）消息队列服务器收到topic消息后，将消息发送给订阅topic的静态页面生成服务，生成静态页面；
（3）有多个静态页面生成服务器订阅商品添加topic，因此保证了多台服务器都一致保存了商品信息，实现了备份；
（4）外界通过nginx反向代理根据并发量和任务强度访问不同的静态页面服务器；
（5）通过nginx的http服务器访问静态资源实现网站页面静态化。

Freemaker生成静态页面的时机
添加商品后使用activemq广播消息,freemaker监听到消息去数据库查询商品生成静态页面
为什么不去redis中获取商品信息,添加商品时还没有存到redis中
为什么不直接使用商品信息还要到数据库中查询:不在一个项目中传输数据麻烦,也起不到提高效率的作用;而且修改数据时也要修改静态页面

3、WEB服务器的 URL Rewrite的方式

URL Rewrite方式特点同样鲜明，由于是服务器内部解析的地址，所以内容是实时更新的，也不存在文件管理和硬件问题，维护比较方便。在服务器级URL Rewrite重写技术并不影响页面的执行速度。但是URL Rewrite的门槛比较高，国内虚拟主机大多不支持，而且虚拟主机是目录级的URL Rewrite,通过遍历目录读物URL转发规则的方式将大大降低页面的执行速度。

4、将页面分成子数据块

把页面划分成子数据块，每个数据块可能是一个inc文件，也可能多个数据块包含在一个inc文件中。具体的数据块划分根据页面的业务结构来处理。比如：网站头尾等公共数据块可以独立成一个文件。

5、总结

对于一个大型网站来说，生成的页面数据会非常多，管理这些页面文件又是一个问题。例如有的页面被删除了，而已经生成的页面数据还会存在各个web服务器上。这时就需要通过后台系统记录这些页面文件的部署位置，以便今后统一管理。同时业务组件的量也可能会比较多，特别是存在多版本的情况下，所以也需要把业务组件的配置情况记录到数据库中，便于统一管理。

在web开发里，除了需要浏览器处理的，其他技术都可以当做服务端来理解，如果我们网站使用到了CDN，使用到了静态web服务器例如apache，以及服务端的web容器例如jboss，那么按请求的行进路径，我们结果处理越早那么网站响应效率也就越高，所以当请求在CDN返回了，那么肯定比在apache返回效率高，在apache就返回了肯定比jboss返回的效率高，再则服务端的web容器本身因为服务端程序运行要消耗部分系统资源，所以它在处理请求的效率会比CDN和apache差很多，所以当我们按照动静分离策略拆分出了静态资源后，这个资源能不放在最底层的服务端的web容器处理就不要放在服务端的web容器里处理。