转自：
夏天的森林blog:(系统设计与架构(47))
一
在存储瓶颈的开篇我提到像hao123这样的导航网站只要它部署的web服务器数量足够，它可以承载超大
规模的并发访问量，如果是一个动态的网站，特别是使用到了数据库的网站是很难做到通过增加web服务器
数量的方式来有效的增加网站并发访问能力的。但是现实情况是像淘宝、京东这样的大型动态网站在承担
高并发的情况下任然能保证快速的响应，这其中有什么样的技术手段可以达到动态网站支撑高并发的场景
了，这也许是每个做web开发的朋友都很感兴趣的问题，今天我将写一个新的系列来探讨下这个问题，希望
我的经验和研究能给大多数人以启迪。这里要说明下，本系列的写法和存储的瓶颈的写法有所不同，本系
列开始部分主要是讲解原理，后面部分会针对原理讲解具体的实现手段，如果有朋友感觉这种写法不适
应，还请谅解。
我个人总结下来，这些大型动态网站之所以可以做到能快速响应高并发，它们都是尽量让自己的网站
静态化，当然这种静态化绝不是把网站就做成静态网站，而是在充分理解了静态网站在提升网站响应速度
的基础上对动态网站进行改良，所以我这里首先要讨论下静态网站那些特点可以用于我们提升网站的响应
速度。
静态网站非常简单，它就是通过一个url访问web服务器上的一个网页，web服务器接收到请求后在网络
上使用http协议将网页返回给浏览器，浏览器通过解析http协议最终将页面展示在浏览器里，有时这个网
页会比较复杂点，里面包含了一些额外的资源例如：图片、外部的css文件、外部的js文件以及一些flash
之类的多媒体资源，这些资源会单独使用http协议把信息返回给浏览器，浏览器从页面里的src，href、
Object这样的标签将这些资源和页面组合在一起，最终在浏览器里展示页面。但是不管什么类型的资源，
这些资源如果我们不是手动的改变它们，那么我们每次请求获得结果都是一样的。这就说明静态网页的一
个特点：静态网页的资源基本是不会发生变化的。因此我们第一次访问一个静态网页和我们以后访问这个
静态网页都是一个重复的请求，这种网站加载的速度基本都是由网络传输的速度，以及每个资源请求的大
小所决定，既然访问的资源基本不会发生变化，那么我们重复请求这些资源，自己在那里空等不是很浪费
时间吗？如是乎，浏览器出现了缓存技术，我们开发时候可以对那些不变的资源在http协议上编写相应指
令，这些指令会让浏览器第一次访问到静态资源后缓存起这些静态资源，用户第二次访问这个网页时候就
不再需要重复请求了，因为请求资源本地缓存，那么获取它的效率就变得异常高效。
由于静态网站的请求资源是不会经常发生变化的，那么这种资源其实很容易被迁移，我们都知道网络
传输的效率是和距离长短有关系的，既然静态资源很容易被迁移那么我们就可以把静态资源服务器按地域
分布在多个服务节点上，当用户请求网站时候根据一个路由算法将请求落地在离用户最近的节点上，这样
就可以减少网络传输的距离从而提升访问的效率，这就是我们长提的大名鼎鼎的CDN技术，内容分发网络技
术。
网络传输效率还和我们传输资源的大小有关，因此我们在资源传输前将其压缩，减小资源的大小从而
达到提升传输效率的目的；另外，每个http请求其实都是一个tcp的请求，这些请求在建立连接和释放连接
都会消耗很多系统资源，这些性能的消耗时常会比传输内容本身还要大，因此我们会尽力减少http请求的
个数来达到提升传输效率的目的或者使用http长连接来消除建立连接和释放连接的开销（长连接的使用要
看具体场景，这个我会在后面文章讲到）。
其实雅虎提出的网站优化的14条建议大部分都是基于以上原理得出的，关于雅虎的14条件建议，本系
列后面内容将做详细的讨论，这里就不展开了。
我常常认为最佳的性能优化手段就是使用缓存了，但是缓存的数据一般都是那些不会经常变化的数
据，上文里说到的浏览器缓存，CDN其实都是可以当做缓存手段来理解，它们也是提升网站性能最为有效的
方式之一，但是这些缓存技术到了动态网站却变得异常不好实施，这到底是怎么回事了？
首先动态网站和静态网站有何不同呢？我觉得动态网站和静态网站的区别就是动态网站网页虽然也有
一个url，但是我们如果传输参数不同那么这个url请求的页面并不是完全一样，也就是说动态网站网页的
内容根据条件不同是会发生改变的，但是这些变化的内容却是同一个url，url在静态网站里就是一个资源
的地址，那么在动态网站里一个地址指向的资源其实是不同的。因为这种不同所以我们没法把动态的网页
进行有效的缓存，而且不恰当的使用缓存还会引发错误，所以在动态网页里我们会在meta设定页面不会被
浏览器缓存。
如果每次访问动态的网页该网页的内容都是完全不同的，也许我们就没有必要写网站静态化的主题
了，现实中的动态网页往往只是其中一部分会发生变化，例如电商网站的菜单、页面头部、页面尾部这些
其实都不会经常发生变化，如果我们只是因为网页一小部分经常变化让用户每次请求都要重复访问这些重
复的资源，这其实是非常消耗计算资源了，我们来做个计算吧，假如一个动态页面这些不变的内容有10k，
该网页一天有1000万次的访问量，那么每天将消耗掉1亿kb的网络资源，这个其实很不划算的，而且这些重
复消耗的宽带资源并没有为网站的用户体验带来好处，相反还拖慢了网页加载的效率。那么我们就得考虑
拆分网页了，把网页做一个动静分离，让静态的部分当做不变的静态资源进行处理，动态的内容还是动态
处理，然后在合适的地方将动静内容合并在一起。
这里有个关键点就是动静合并的位置，这个位置的选择会直接导致我们整个web前端的架构设计。我们
这里以java的web开发为例，来谈谈这个问题。
java的web开发里我们一般使用jsp来编写页面，当然也可以使用先进点的模板引擎开发页面例如
velocity，freemark等，不管我们页面使用的是jsp还是模板引擎，这些类似html的文件其实并不是真正的
html，例如jsp本质其实是个servlet也就是一个java程序，所以它们的本质是服务端语言和html的一个整
合技术，在实际运行中web容器会根据服务端的返回数据将jsp或模板引擎解析成浏览器能解析的html，然
后传输这个html到浏览器进行解析。由此可见服务端语言提供的开发页面的技术其实是动静无法分离的源
头，但是这些技术可以很好的完成动静资源中的动的内容，因此我们想做动静分离那么首先就要把静的资
源从jsp或者模板语言里抽取出来，抽取出来的静态资源当然就要交给静态的web服务器来处理，我们常用
的静态资源服务器一般是apache或ngnix，所以这些静态资源应该放置在这样的服务器上，那么我们是否可
以在这些静态web服务器上做动静结合呢？答案是还真行，例如apache服务器有个模块就可以将它自身存储
的静态资源和服务端传输的资源整合在一起，这种技术叫做ESI，这个时候我们可以把不变的静态内容制作
成模板放置在静态服务器上，动态内容达到静态资源服务器时候，使用ESI或者CSI的标签，把动静内容结
合在一起，这就完成了一个动静结合操作。这里就有一个问题了，我前面提到过CDN，CDN其实也是一组静
态的web服务器，那么我们是否可以把这些事情放到CDN做了？理论上是可以做到，但是现实却是不太好
做，因为除了一些超有钱的互联网公司，大部分公司使用的CDN都是第三方提供的，第三方的CDN往往是一
个通用方案，再加上人家毕竟不是自己人，而且CDN的主要目的也不是为了做动静分离，因此大部分情况下
在CDN上完成这类操作并不是那么顺利，因此我们常常会在服务端的web容器前加上一个静态web服务器，这
个静态服务器起到一个反向代理的作用，它可以做很多事情，其中一件事情就是可以完成这个动静结合的
问题。
那么我们把这个动静结合点再往前推，推到浏览器，浏览器能做到这件事情吗？如果浏览器可以，那
么静态资源也就可以缓存在客户端了，这比缓存在CDN效率还要高，其实浏览器还真的可以做到这点，特别
是ajax技术出现后，浏览器来整合这个动静资源也就变得更加容易了。不过一般而言，我们使用ajax做动
静分离都是都是从服务端请求一个html片段，到了浏览器后，使用dom技术将这个片段整合到页面里，虽然
这个已经比全页面返回高效很多，但是他还是有问题的，服务端处理完请求最终返回结果其实都是很纯粹
的数据，可是这些数据我们不得不转化为页面片段返回给浏览器，这本质是为纯粹的数据上加入了很多与
服务端无用的结构，之所以说无用是因为浏览器自身也可以完成这些结构，为什么我们一定要让服务端做
这个事情了？如是乎javascript的模板技术出现了，这些模板技术和jsp，velocity类似，只不过它们是通
过javascript设计的模板语言，有了javascript模板语言，服务端可以完全不用考虑对页面的处理，它只
需要将有效的数据返回到页面就行了，使用了javascript模板技术，可以让我们动静资源分离做的更加彻
底，基本上所有的浏览器相关的东西都被静态化了，服务端只需要把最原始的数据传输到浏览器即可。讲
到这里我们就说到了web前端最前沿的技术了：javascriptMVC架构了。
好了今天就写到这里，本篇文章是网站静态化处理理论的总述，后面的文章我将会一点一滴的讲述实
现网站静态化的各种技术实现细节。
二
上篇文章我简要的介绍了下网站静态化的演进过程，有朋友可能认为这些知识有点过于稀松平常了，而
且网站静态化的技术基点也不是那么高深和难以理解，因此它和时下日新月异的web前端技术相比，就显得
不伦不类了。其实当我打算写本系列的之前我个人觉得web前端有一个点是很多人都知道重要，但是有常常
低估它作用的，那就是web前端和web服务端如何融合的这个点上，这个点再加上我们要做出一个规模庞
大，高并发，快速响应的网站时候它对于web前端的架构技术的演进起到了一个不可忽视的作用。
网站的web前端要实现高效，第一个要解决的短板就是网络的延迟性对网站的加载效率的影响，当然很
多人会说网速快不快这是网络运营商的问题，不是网站的问题，但是大家肯定也见过就算我们用上了千兆
宽带也会有些网站加载速度慢的让人无法忍受，网站本身的确是没法控制网络速度的能力，但是如果我们
不降低网络对页面加载效率的影响，其他任何优化网站的手段也就无从谈起，原因就是网络效率对于网页
加载效率的影响是起到大头作用的，只有这个大头被解决了，那么解决其他的小头才能发挥作用。
回到上文讲到的网站静态化的关键点动静分离，解决这个关键点的本质就是为了降低网速对网站加载
效率的影响，但是我们在处理动静分离问题时候采取的策略不同会对我们整个网站架构产生重大影响，特
别是将网页做好动静拆分后，静态的资源尽力向浏览器端推移，这就导致了前端架构出现了以前服务端才
有的MVC模式，这就导致web前端架构产生了质的变化，如是一些原来适用于flash这样的重客户端的技术也
被传统的web前端所采用，MVC模式在web前端进一步演进由此而出现了MVP（Model-View-Presenter）模
式，MVVM（Model-View-ViewModel）模式。也许上篇文章里有人对讲述动静分离的原理有点异议，但是当
今日新月异的web前端技术就是这些常见技术不断演化而来，这就是我上篇想表达的内容，我觉得这个系列
的特点应该是细节，这是和上个系列存储的瓶颈注重思想是有所不同的。
动态网站最难以动静分离的就是页面了，其他的静态资源例如：图片、外部脚本文件等等这些和静态
网站的手法基本一致，其实业界很早就关注了动态网站的动静分离问题，并且为不同的动静分离方案都进
行了总结，今天我就介绍下这些技术。本人web服务端的工作语言是java，因此下面服务端的例子是使用
java的web技术阐述的，其他语言例如php都有与之对应的技术，所以请那些不是使用java作为服务端工作
语言的朋友可以类比学习。
在java的web开发里，页面技术jsp本身就包含了将页面动静分离的手段，例如下面的代码：
<%@ include file=”header.jsp” %>">×