web访问-静态化

   在大型网站中，访问者看到的页面基本上是静态页面。为什么都要把页面静态化呢？把页面静态化，好处有很多。例如：访问速度快，更有利于搜索引擎收录等。目前主流的静态化主要有两种：一种是通过程序将动态页面抓取并保存为静态页面，这样的页面的实际存在于服务器的硬盘中，另外一种是通过WEB服务器的 URL Rewrite的方式，他的原理是通过web服务器内部模块按一定规则将外部的URL请求转化为内部的文件地址，一句话来说就是把外部请求的静态地址转化 为实际的动态页面地址，而静态页面实际是不存在的。这两种方法都达到了实现URL静态化的效果，但是也各有各自的特点。

将动态页面转化为实际存在的静态页面这种方法，由于静态页面的存在，少了动态解析过程，所以提高了页面的访问速度和稳定性，使得优化效果非常明显。所以这种方法被广泛采用。但是它的局限性同样存在。对于大型网站而言，这种方法将带来不可忽视的问题。

一、由于生成的文件数量较多，存储需要考虑文件、文件夹的数量问题和磁盘空间容量的问题；

二、页面维护的复杂性和大工作量，及带来的页面维护及时性问题，需要一整套站点更新制度。

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

除了抓取动态页面和URL Rewrite的方法外，在这里我们再看一下另外的一种方法。此方法的核心思想就是：把页面划分成子数据块，每个数据块可能是一个inc文件，也可能多个数据块包含在一个inc文件中。具体的数据块划分根据页面的业务结构来处理。比如：网站头尾等公共数据块可以独立成一个文件。这种方法需要考虑以下几个方面：

1、用什么方式生成页面及里面的数据块

2、页面的更新机制；

3、大量的页面文件的维护工作；

4、页面数据块的及时性。

这种方式的话，通常可以在后台增加一个服务程序，专门生成某个频道或栏目的页面。这样虽然可行，按照频道分的话，逻辑结构也清晰。

【单服务模式】

这样会带来一些问题。例如：当频道修改后，相应的服务程序都要重新翻一遍。如果频道栏目很多，对应的服务程序也会很多，导致程序的维护工作量大。前台开发人员不仅要去做页面，也要考虑后台的服务程序结构，给他们增加了不必要的开发难度，降低了开发效率。


【多服务模式】

而在多服务模式下，会出现多台服务去争抢指令数据的情况。动作指令的状态必须在多个服务之间同步。服务升级了，也要一个一个去更新，出现错误了也要一个一个去排查。。。。。。

那么有没有一种方法能把生成页面的功能独立抽象成一个平台，同时提供一个程序接口，前台开发人员只需要按照这个接口，开发业务组件即可。现在前台开发人员只需要把写好的业务组件，部署到指定的地方即可。剩下的事情交给这个平台去做，这样就简化了系统发布，维护工作，减轻了前台开发人员的工作量，提高了他们的开发效率。



【平台集中处理模式】

       动作指令是指页面更新的动作，当页面数据有变化时，会根据业务规则从某个地方发出一个动作。它的来源大致可以分为三种：前台页面触发，后台内容管理系统触发，后台自动定时触发。

静态数据生成系统与业务组件的接口设计。通过反射的方式调用业务组件，接口的参数在指令结构的基础上扩展即可。比如增加一些错误描述，数据库链接对象等。

数据分发是一个独立的数据传输系统，它负责根据预先设定好的配置，把生成的页面数据传输到指定的web服务器上。

为了使系统在随着网站访问量的上升的同时做到水平扩展，加快指令的处理速度。所以需要把系统部署到多台服务器上，这样以来各个子系统就要统一通信协调。可以用MQ消息作为子系统之间的通信手段。子系统的部署模式变为Master-Slave的形式。Master主机上的系统负责读指令，然后把指令发送到MQ。各个Slave主机系统负责接收MQ消息指令，调用业务组件并更新某条指令的状态，这样就把处理业务逻辑的压力平均的分配到了各台slave主机。


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