在大型网站中,访问者看到的页面基本上是静态页面。为什么都要把页面静态化呢?把页面静态化,好处有很多。例如:访问速度快,更有利于搜索引擎收录等。目前主流的静态化主要有两种:一种是通过程序将动态页面抓取并保存为静态页面,这样的页面的实际存在于服务器的硬盘中,另外一种是通过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主机。
![](https://i-blog.csdnimg.cn/blog_migrate/3d90198def1a90a5376b8f239d677a56.jpeg)
对于一个大型网站来说,生成的页面数据会非常多,管理这些页面文件又是一个问题。例如有的页面被删除了,而已经生成的页面数据还会存在各个 web服务器上。这时就需要通过后台系统记录这些页面文件的部署位置,以便今后统一管理。同时业务组件的量也可能会比较多,特别是存在多版本的情况下,所以也需要把业务组件的配置情况记录到数据库中,便于统一管理。