网站静态化处理--总述（1）

　　在存储瓶颈的开篇我提到像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架构了。

　　原文：http://www.cnblogs.com/sharpxiajun/p/4282789.html