谈谈网站静态化

／＜　０～ｏＬ』［ｕ　～　

谈谈网站静态化　

现在的Ｗｅｂ开发已经进入了各种技术大整合的时代，本文论述了．Ｎｅｔ下的系统架构问题。　

一文／朱娥　

写在前头　

・回复数每次回复后都要更改，更新频率高。　

静态化是解决减轻网站压，提高网站访问速度的　

・设计时要注意细节，如上图中圈出来的部分，这些　

常用方案。但在强调交互的Ｗｅｂ２．０时代，对静态化提　

部分是怎么修改的，频率有多大，一个都不能放过。　

出了更高的要求，静态不仅要能静，还要能动。下面我　・确定生成方式：　

通过一个项目，谈谈网站静态化后的架构设计方案，同　

在上面帖子一例中，每次更改都重新生成页面是不可　

时和大家探讨一下，在开源产品大行其道，言架构必称　

取的，一篇回复数多的帖子，需要的数据量是巨大的（每　

ＭｅｍｂｅｒＣａｃｈｅ，Ｎｇｉｎｘ的时代，微软技术在网站架构设计　层楼的用户信息，回复内容），任何修改，都需要重新取　

中的运用。　

出数据进行生成是不能允许的，一般除非你的页面基本不　

用更新，或者更新开销极小（比如一段嵌入的广告代码）　

静态化的设计原则和步骤　

才能采用整体更新的方式，不然就需要我们找到合适的更　

静态化是解决减轻网站压力，但是静态化也会带来一　

新页面局部区域的方法。　

系列的问题，包括开发上复杂度的增加，维护难度的增加，　般有下面两种方法：　

运用不得当，更可能适得其反。而许多替代方案，比如页　１）正则修改法：　

面缓存，如果运用得当，也能起到很好的效果，所以在开　比如，如果帖子中的回复数，ｈｔｍ　Ｊ代码是这样　

始之前，必须进行详细的考察，确定是否适合静态化，并　

制定适合的静态化方式。下面先介绍一下：　

・考察读写比：读写比，准确的说是读写负荷比，是　

否值得静态化的最终考虑，由于一般写入的压力明显大于　

我们可以通过用下面正则来查找并替换计数　

读出的压力，如果写入太频繁，或者每次写入消耗的资源　

太多，都不能达到效果，我觉得读写比例１０：１应该是个上　

限，具体情况需要根据自己的业务逻辑判断。　

・确定页面呈现的内容是否适合静态化：　

２）页面区域分块：　

在设计方案时，必须详细考虑每个原型页面，找到页　

把页面分成很多小块，在显示时组装起来，比如　

面上展示的信息和他的更新方式、更新时机、更新频率，　

露圜黧黧璺璺圈　ＤｏｔＴｅｘｌ就采用这个方法。　

定要注意那些不起眼的信息，它们可能左右你的设计。　

ｆ‘　…　｛　…………　……鎏ｉ篓　登　ｊｉ　　＿一这是一篇典型的Ｄｏｔ，一　＿ｌｌ…—…　ｔｅｘｔ　ｂｌｏｑ页　、　

比如，我们以ＣＳＤＮ的论坛的任意一篇帖子为例，进行分　

囊墓熏鬻蠢　面，其中红色标定部分是一个独立　

析：　

塞塞　蕊　一　！的文件，而黄色框内的是脚本动态　

呈现的内容主要是这样几　

譬ｉ　加载，这些部分在最终显示的ｔ１，－候　

块，帖子内容，回复内容，发帖人，　

≥蘸　墨　组合起来，最终构成了一篇Ｂｌｏｇ，　

回复人的用户信息。　

ｌ　…………　具体的组合方法也有多种，可以使　

・帖子内容和回复内容在发　

用Ｉｎｃｌｕｄｅ，也可以自己来实现，ＤｏｔＴｅｘｔ就自己实现了一　

帖时更新，发帖后用户可以修改　

套加载机制。　

其内容，更新频率高。　

上面的两种方法并不孤立，可以根据需要，配合使用。　

・用户信息，用户修改个人信息时可能会发生更改，　

・确定需要动态加载的信息：　

用户等级增加时也可能发生更改，比如加星，更新频率低。　

页面上总有一些内容看起来不太适合静态化，最典型　

９６　程序员　

的是一些统计结果，比如做一个图书介绍页面，可能就会　

Ｒｎ　Ｐ，Ｒｎ为资源数，Ｐ为每个资源的页面数。所谓资源，　

可以看做一个生成单位，其页面数可以简单看做发布一个　

资源，就需要生成其所有相关页面数量。比如，发布一个　

ｂｌｏｇ，就需要生成一个Ｂｌｏｇ页，同时还需要生成或者更　

需要展示图书的当天综合评分，或者书籍排名，这些内容　

需要用脚本进行动态加载。　

既然做了静态化，就是希望减少服务器负载，动态加　

载的数据总是不得已而为之，有的时候在需求允许的情　

况下，我们可以在数据的实时性和性能之间做一些权衡。　

比如上面帖子中的用户星级和昵称，从数据实时性上说，　

当用户的星级增长，他发的所有帖子都应该发生变化，所　

以应该用动态加载，其实这些信息如果不发生变化，也无　

新个人主页的ｂｌｏｇ列表。算上个人主页右侧的分类文章数　

的小块，也就是最多１０来个页面或者区域，但是发布一　

个电影，其相关的页面至少有５０个以上，而且有的页面　

还带有分页，一个信息比较丰富的电影，其页面竟可以达　

到千个以上，空间１Ｏ－２０Ｍ，而且资源总数也不少，电影　

８００００左右，电影人虽然Ｐ值较少，但是总量确有几十万　

伤大雅，用户反而能够看到自己在多年前发帖时的级别和　

昵称。　．　

之巨，估计静态页面磁盘占用量几百个Ｇ。　

・向下兼容　

现实中的项目　

Ｘ网站是大型的电影资讯，电影社区，向外提供电影　

这是一个已有系统，旧系统的框框需要突破，但又没　

有时间，或者不能完全突破。ｌ：Ｌ￣ｎ　Ｕ　ｒｌ，已经被收录到搜索　

引擎，就不能随便调整，还有一些地方，原本没有为静态　

生成考虑，另～些地方又需要兼容旧的设计。　

・多台前端Ｗｅｂ　・　

这种结构要求生成的文件可能需要分布到多个服务器　

相关信息服务，以及用户社区，其中信息服务部分，大部　

分页面属于信息呈现页，读取量比较大，百万级别ｐｖ，最　

高并发（ｈｔｔｐ连接数，能达到三位数（ｗｉｔｈｏｕｔ　ｋｅｅｐａｌｉｖｅ），　

信息主要由编辑在后台发布，更新较少，但其页面上有大　

量的交互性的内容，比如评论、收藏列表，同时许多内容　

允许用户创造，比如上传图片、添加注释，交互内容的数　

量和交互的频繁程度，都超过了普通的咨询页面，这次调　

（另一个方案是放在几台专用的机器上，等前端来取）。　

・任务紧迫　

架构讨论结束仪式六月初，离奥运开幕上线只有两个　

月，也就是说所有底层框架实现，页面模板开发，调试测　

试，动作的整理，必须在７月底全部完成，按我原来估计，　

实现这几块的上百个页面模板和填充方法，也需要那么长　

的时间。　

整，准备将其中访问量最大的几块，电影资料页、影人资　

料页进行静态化。如果成功，还将运用到更多的频道，基　

本实现全站静态化。　

通过对页面设计和前一版本的分析，下面是在做静　

态化时具有挑战性的地方，这些特点基本适用于大多数　

Ｗｅｂ２．０的站点，很具有典型意义。　

・页面生成的触发条件复杂　

一

综合考虑上述因素，架构必须要有以下几个　

方面的特点：　

・动作可以灵活扩展配置，某个动作对应哪些生成，　

应该可以配置，并且可以分组。　

・文件必须有分发机制。　

・分发和生成必须独立出来，并且支持分布式。　

・各种的动作，必须转化为消息，发送到生成和分发　

服务器进行处理。　

・针对同意资源频繁动作，在变量相同的情况下能够　

具有合并的能力。　

般论坛中的帖子或者ｂｌｏｇ，更新方式比较单一：主　

要是由回复进行触发，还有少量的修改动作，然而该网站　

一

个页面的触发条件就有２０多个，比如光二级菜单：用　

户发布图片、删除图片，发布或者删除影片信息、发布或　

者修改视频、后台修改电影信息，都有可能触发。　

・一个动作触发生成的页面可能很多而且相互交叠　

每一个动作都会触发一系列的生成，并且不同动作可　

能都会涉及同～个页面或者区域的生成。比如：用户给一　

部电影评分，需要生成评分更多页，评分统计更多页，首　

・动作必须有记录。　

・尽量考虑使用已有成熟技术，节省开发时间。　

页右侧谁还关注此影片小区域，等等，用户收藏一个影片，　

也需要更新首页右侧谁还关注此影片小区域。　

・触发频繁　

下面是设计的第一个架构　

用户的动作经过　帆　

虽然不及某些更大规模的网站，但是由于涉及众多用　

ＭＳＭＱ传入到生成　

箭头）进行处理，处　

理中心接受到消息　

９　

：　

户参与的内容，评论，收藏等等，触发点多，发生频度相　

当频繁。　

分发中心（途中绿色　穗替　ｊ　ｉ　

・页面多，结构复杂，空间占用大　

通常，需要生成的页面规模是这样粗略估算的，　

后，负责生成对应的页面或者页面区域，　并将页面分发到　

２００８　１Ｏ　９７　

＞、　

ｏ　

ｏ　

［　

Ｕ　

各个服务器，负载均衡沿用以前的架构，采用微软的ＮＬＢ。　

之所以用ＭＳＭＱ，就是看上了他提供的完整的消息存　

下图是文件生成分发中心的工作流程图。　

生成服　

务对外只有　

一

储恢复机制，这样我们能确保即使服务器ｄｏｗｎ掉重启后，　

消息依然能正常处理，碰巧我们ｃｍｓ组的同事ＭＳＭＱ　

非常熟悉，并且正准备在另外一个项目中使用类似的架　

构——于是一拍即合。　

页面采用分块存储，这样能保证生成时目标小，开销　

小，也能重用。然后再藉由ＳＳＩ（ｓｈｔｍＩ　ｉｎｃｌｕｄｅ）进行整合。　

之所以采取这样的方案，而不采用Ｄｏｔｔｅｘｔ的整合方式，是　

个输入，　

就是消息，　

一

卜　

个输出：　悬　

蹦　

静态文件。　

内部根据消　

息，从配置　

龋翔　　　０；‘　群一　

因为如果采用Ｄｏｔｔｅｘｔ的方式，就必须走ＩＩＳ和．Ｎｅｔ的管道。　

而据测试，经过管道和直接返回ｈｔｍＩ性能有非常大的差异，　

而使用ＳＳｉ，在性能上是一个折中，　并且可以Ｌｉｇｈｔ　ＨＴＴＰｄ　

等高性能Ｗｅｂ服务器。　

模板生成方式，采用了ＸＳＬＴ和另外一种自定义的模　

板，生成的最终产物是ｓｈｔｍｌ，之所以生成ｓｈｔｍｌ是为了使　

用其ｓｓｉ（Ｓｅｒｖｅｒ　Ｓｉｄｅ　Ｉｎｃｌｕｄｅ）的特性，保证一定的灵活性，　

并实现热点数据的分离。某些页面上的部分可能会频繁更　

新和生成，而其它地方不变，或者某个部分是所有页面通　

用的（比如页头和页脚）。　

但是这个设计的问题是动态内容和静态内容没有分　

开，生成的ｈｌｍｌ页面和动态页面都放在前端服务器上，通　

过负载均衡访问，也造成了分发服务器需要分发到多台服　

务器，网络ｆＯ效率较低，而且静态内容需要的磁盘空间　

很大，且小文件非常多，和动态页面混在一起不便于优化，　

所以第二个方案对生成的静态内容与动态内容使用不同的　

服务器。　

方案二：　

我们把　

生成的静态　＆　

文件单独放　

置，可以看　

到，前端增　

加Ｎｇｉｎｘ，作为跳转，把电影，影人资料库的页面转向静　

态服务器，其他的请求转向动态服务器，这样我们就可以　

单独为静态服务器进行优化，比如采用更高效的服务器等　

等。　

同时，由于减少了文件分发的次数，分发效率能显著　

提高。　

更进一步，可以把图片服务分到另外一组机器上，使　

用独立的域名，比如ｉｍｇ．ＸＸＸ．ｃｏｍ，这样可以有效地减少　

带宽。　

最终完整架构：　

文件生成分发中心　

９８　程序员　

文件中找到　

对应的生成　

方法，取出　

相应的模板，进行数据填充。　

分发服务主要把生成服务产生的文件进行分发，分发　

到前端的Ｎ台服务器上，开始考虑得比较复杂，希望分发　

服务可以跨越协议（本地文件系统，局域网，ｈｔ

蓼　

ｔｐ协议），　

跨越多种存储介质（文件系统，数据库），实际最后定下　

来基本是本地文件系统或者局域网传输。　

注：上图中文件分发的部分也可以通过定制ＭｏｇｉｌｅＦＳ　

来实现分布式文件系统。　

马后炮：　

总结起　

来，静态化除　

了对架构方面　

囊　≤圉　

，…～一．．．　　～一一　、　

的影响，对开　

发和测试流程　

重　

也有影响。　

对测试提出更高的要求　

因为一旦上线后，某个页面发现问题，即使是文字的　

修改，也需要重新生成许多页面，所以测试人员必须非常　

仔细，测试周期也需要延长。　

开发人员需要掌握模板语言　

需要掌握一种额外模板语言，无论是Ｘｓｌｔ还是自己开　

发的模板语言，都需要花一定的时间掌握。如果是自己开　

发模板，让模板语法接近已经能熟练使用开发语言，或者　

完全相同是个不错的选择。　

需要给第一次生成腾出足够时间：　

如果不是新系统，那么数据迁移和生成的过程就比较　

痛苦，由于页面众多，第一次生成的过程可能需要以天来　

计算，在制订上线方案时就需要考虑到这个方面。　

Ｎｇｉｎｘ作为前端的跳转，根据其他网站的经验，应该　

可以达到２～３万并发连接，但是使用之后，常常有卡壳　

的情况发生，具体症状为在浏览器中访问页面时，连接超　

时，或者一直不响应。此时Ｎｇｉｎｘ连接数并不高，好在还　

有第

|

套

方

案

可

以

备

用

_|

-

3

菱

。

|

、

在

大型

w

些

方

面还

存在

e

一

b

开

发

上

，

我感

到

微软产

品

结

构

，

包

括

微

软

开

源社

区

的

成

果

，

在

某

些

不足

。

高性能

服

务

器

选

择

太少

Li

n

u

x

下

可

以采用

Li

g

h

t

HT

TPd

N

g

i

nx

等

诸多

服

务

器

，

，

这些

服

务

器

在

很多

方

面

的表

现

会

让

Wi

n

d

ow

s

下

唯

一

的

选

择

一

II

S

相

形

见

绌

。

分布

式

文件

系

统

微软

及

其社

区

没

有

比

较著

名

的

产

品

出现

，

Li

nu

x

下

有

M

o

g

il

e

F

S

。

微

软架构

下

文件

系

统

选

择

太

少

在

L

i

nu

x

下

我

们

可

以

选

择

诸

如

是

唯

E

x

t

3

、

R

e

i

ser

F

S

，

而

Wi

n

d

ows

环

境

下

。

，

NTFS

的

选

择

不

过

值

得

称

道

的

是

，

．

NTF

S

的

效率

和

稳

定

性

都相

当

不

错

开

源技术

对

w

i

n

d

或

者提

供

的

Wi

n

d

o

w

择

。

ows

版

本的

支

持

态

度

不

积

极

，

诸

多在

L

i

nux

下

名声卓著的

开

源产

品

s

又

懒

于

为

Wi

n

d

o

ws

提供相

应

的

版

本

，

版

本效

果

差强

人

意

，

使

得

采

用

微软

服

务

器

的

网

站

少

了

很多

选

大

整合的

时

代

ava

，

现

在

的

W

e

b

开

发

已

经

进

入

了

各种技

术

大

混

合

、

，

任

何

个

厂

商

，

都

不可

能

涵

盖

所

有方

面

在

后

端

架构

和

逻

辑

方

面

。

．

N

e

t

~

l

J

严

谨

良

好

的

编

程

风

格

，

清晰

的

设

计

思

路

，

较

高

的

运

行

效

率

，

以

及

稳

定的

配

套

服

务

支持

，

是

其最

大

的优

势

，

对

主

要

擅长

微

软技术的

W

e

b

工

程

师

和

架构师

而

言

应

该增进

对

L

i

nux

及

开

源

社

区

的

了

解

，

才

能根

据

需

求

设

计

出

合

理

的

架

构

。

■

朱皴从

事软

件

开

发

网

站

开

发

多年

关

注

网

站性

能和

架构

是

微软

N

e

t

C#

方

向的

MVP

同

时

也

密

切

注

意

L

i

nu

x

和

开

源

社

区

的

动向

，

，

，

，，

。

?

责任编

辑

：

赵健平

(

z

h

ao

j

p

@

c

s

d

n

n

e

t

)