网站静态化处理--总述（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架构了。

网站静态化处理—动静整合方案（2）

上篇文章我简要的介绍了下网站静态化的演进过程，有朋友可能认为这些知识有点过于稀松平常了，而且网站静态化的技术基点也不是那么高深和难以理解， 因此它和时下日新月异的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本身就包含了将页面动静分离的手段，例如下面的代码：

　　一般一个网站的头部和尾部都是一样，因此我们把头部的代码单独放置在一个header.jsp页面里，页面尾部的代码放置下footer.jsp页面 里，这样技术人员在开发页面时候就不再需要重复编写这些重复的代码，只需要引用即可，这个做法最大的好处就是可以避免不同页面在相同代码这块的不一致性， 假如没有这个统一引用的话，手动编写或者复制和粘贴，出错的概率是非常的高的。

　　但是这个做法有一个问题，问题就是这种动静分离其实都是作用于单个页面的，也就是说每个页面都要手动的重复这个动静分离的操作，大多数情况这种做法都不会有什么问题，但是对于一个大型网站而言这种做法就有可能会制造不必要的麻烦，这里我截取了一张京东的首页，如下图所示：

　　讲述前我要事先声明下，京东网站可 能不存在我要讲述的问题，我这里只是使用京东网站的首页做例子来说明，看图里的首页和食品两个条目，有些公司做这样的网站时候这些导航进入的页面会是一个 独立的工程，每个工程都是由独立的项目组开发维护的，虽然项目组不同但是他们页面的整体结构会是一致的，如果按照上面的动静分离手段，那么每个项目组都要 独立维护一份相同的头部尾部资源，这个时候麻烦来了，如果该公司要新增个新的条目，那么每个项目组都要更新自己不变的资源，如果该企业一共分了5个项目 组，现在又做了一个新的条目，那么其他与之无关的项目组都得折腾一次更改统一引用文件的工作，要是做的不仔细就有可能出现页面展示不一致的问题，为了解决 这个问题，java的web开发里就会考虑使用模板语言替代jsp页面技术，例如模板语言velocity，这些模板语言都包含一个布局的功能，例如velocity就有这样的功能，我们看看velocity的布局模板实例，如下所示：

　　页面里我们可以引入这个布局格式，这个布局文件其实就是页面里不变的东西抽取了出来，它完成了页面动静分离，页面只要应用这个布局文件即可，到了这里这个布局文件和前面的include方式区别不大，那么我们再看看下面的代码：

　　这是布局文件的引用方式，我们可以把布局文件放置在网络上，项目里应用这个文件所在地址即可，这样我们就把项目里不变的静态资源抽取在同一个地方，如果在碰到布局要做修改，那么我们只需要改一个地方即可。

　　不管服务端采取何种动静分离，动静资源的整合都是有服务端完成，按照上文提到网站静态化的思想，这些做法不会给网站性能提升带来任何好处，它们只是给 开发，运维提供了便利而已，按前文的思路，我们要把动静分离往前移，服务端往前移碰到的第一个点就是静态的web服务器例如apache或ngnix。

　　在讲解静态的web服务器动静分离前我要先讲一下为什么我们要在服务端前面加个静态web服务器的道理。我个人觉得在每个服务端之前都布置一个静态web服务器，该服务器起到一个反向代理的作用，而且我觉得不管我们是否使用CDN，最好都这么做，这么做有如下好处：

　　好处一：方便日志的记录。

　　好处二：在服务端之前设立了一个安全屏障，即静态web服务器可以在必要时候过滤有害的请求。

　　好处三：可以控制流入到服务端的请求个数，当并发很高时候，可以利用静态web服务器能承担更高并发的能力来缓冲服务端的压力，这 里我补充一些实践技巧，以java里常用的web容器tomcat为例，一般官方给出它的最大并发数应该不会超过200，如果我们在tomcat前放置了 一个apache服务器，那么我们可以把tomcat的最大并发数设置为无效大，把并发数的控制放置在apache这边控制，这么做会给我们系统运维带来 很大的好处，tomcat虽然有一个建议最大并发数，但是实际运行里java的web容器到底能承受多大并发其实要看具体场景了，因此我们如果可以动态控 制apache的并发数，这个操作很方便的，那么我们就可以动态的调整tomcat这样容器的承载能力。

　　好处四：可以便于我们做动静分离。

　　这里我们以apache为例子讲解将动静分离前移到apache的一些做法，apache有一个功能叫做SSI，英文全称是Server Side Include，页面上我们一般这样使用SSI，SSI有一种标签，例如：

　　页面一般使用注释的方式引入，这个和jsp的 引入有点区别的，SSI的做法其实和服务端的引入类似，只不过使用SSI将本来服务端做的动静整合交由了apache完成了，我们可以把静态文件直接放置 在Apache这里，如果这个静态web服务器上升到CDN，那么这些静态资源就可以在靠近用户的地方使用，SSI说白了就是像apache这样的静态资 源服务器接收到服务端返回后，将一部分内容插入到页面了，然后将完整页面返回至浏览器。这个做法如果优化的得当，可以很好的提升网站的加载效率。

　　Apache这样的静态资源服务器还支持一种动静整合的技术，这个技术就是ESi，它的英文全称叫做Edge Side Includes，它和SSI功能类似，它的用法如下所示:

　　它和SSI区别，使用esi标签获取的资源来自于缓存服务器，它和SSI相比有明显的性能优势，其实网页特别是一个复杂的网页我们做了动静分离后静态 的资源本身还可以拆分，有的部分缓存的时间会长点，有点会短点，其实网页里某些动态内容本身在一定时间里有些资源也是不会发生变化的，那么这些内容我们可 以将其存入到缓存服务器上，这些缓存服务器可以根据页esi传来的命令将各个不同的缓存内容整合在一起，由此我们可以发现使用esi我们会享受如下优点：

　　优点一：静态资源会存放在缓存里，那么获取静态资源的效率会更高。

　　优点二：根据静态资源的时效性，我们可以对不同的静态资源设置不同的缓存策略，这就增加了动静分离方案的灵活性。

　　优点三：缓存的文件的合并交由缓存服务器完成，这样就减少了web服务器本身抓取文件的开销，从而达到提升web服务器的并发处理能力，从而达到提升网站访问效率的目的。

　　(友情提示：ESI这块我还了解的不太深入，听说它其实可以直接使用在jboss上，相关知识我还要继续收集资料学习)

　　SSI和ESI是静态web服务器处理动静资源整合的手段，那么我们再把动静整合操作往前移，这个时候就到了浏览器端了。浏览器端的动静整合的技术称之为CSI，英文全称叫做Client Side Includes，这个技术就是时下javascriptMVC、 MVVM以及MVP技术采取的手段，实现CSI一般是采用异步请求的方式进行，在ajax技术还没出现的年代我们一般采取iframe的方式，不过使用 CSI技术页面加载就会被人为分成两次，一次是加载静态资源，等静态资源加载完毕，启动异步请求加载动态资源，这么一做的确会发生有朋友提到的一种加载延 迟的问题，这个延迟我们可以使用适当的策略来解决的，关于CSI的使用是本系列的重点，我会在后面文章里重点讲解。

网站静态化处理—动静分离策略（3）

前文里我讲到了网站静态化的关键点是动静分离，动静分离是让动态网站里的动态网页根据一定规则把不变的资源和经常变的资源区分开来，动静资源做好了拆分以后，我们就可以根据静态资源的特点将其做缓存操作，这就是网站静态化处理的核心思路。由此可见，网站静态化处理的核心就是动静分离和缓存两大方面，上篇我简单讲述了动静整合的基础知识，本篇将会讲述两大核心之一的动静分离策略，只有把动静分离策略做好了，缓存才能发挥出它应有的效果。

　　下面我们要讨论下动静分离的策略了，一个页面什么内容是动态的，什么内容是静态的，这个我们到底该如何来区分了？这个问题学问非常大，我们的标准不 同，最后拆分出来的动静资源就会存在很大的不同。在本系列开篇里，我提到了什么样的页面是静态页面，什么样的页面是动态页面，我是以一个url的角度定义 的，每个独立的页面都会有一个url，这个url就好比这个页面的门牌号，我们每次访问这个url时候如果得到的响应页面都是一样的那么我们就认为该页面 是静态页面，如果访问某个url，我们访问的时间不同，最后展示的页面也不一样那么这个页面就是动态页面，动态页面就是我们要进行动静分离的载体了，我们 可以看到我的定义其实是和时间相关的，也就是说访问时间不同，得到的结果会不一致，所以我们可以根据时间这个维度分析页面里那些内容是静态的，那些是动 态，但是这个划分在实际情况里就会变得非常复杂，下面我就讲讲这个复杂度。

　　场景一：假如我们是一个商户，我们查询自己网店的交易数据，一般这个交易数据我们会放置在页面的右下部分，这个部分我们很自然把它当做动态资源，就算我们的网店交易量很小，我们也不敢把这个部分当做静态资源处理。

　　场景二：我们网站为了给用户一个友好的体验，会在用户登录网站后在页面某个地方显示欢迎语，例如：上午好，夏天 的森林，欢迎使用我们的网站！，到了下午，这个欢迎语可能就变成了下午好，夏天的森林，欢迎使用我们的网站！，那么这块内容我们应该是当做静态内容还是动 态内容呢？这个就需要思考了。

　　场景三：网站页 面里会有很多图片，有些图片的确是很久很久都不会发生变化，例如网站的图标，但是有的图片却不同了，例如有一个星期我们要为某个商户做营销活动，那么营销 图片这块更新后就会有一个星期的有效期，复杂点的话，我们可能会在营销活动期间在页面的某一块专设给这个商户营销活动的内容区，这个内容区使用一个 html片段，但是当营销活动结束了，这个营销的图片可能就要发生变化，营销的内容区可能会被去掉，那么这些东西我们是当做静态内容还是动态内容处理了？

　　由上面的场景我们可以知道，这个动静分离是要讲究策略的，如果策略设计的不好，可能我们把网站静态化处理后，效果并没有达到我们的预期。其实，我认为 动静分离除了以时间维度考虑外，还应该有个维度，就是被拆分的资源是否需要服务端应用加以配合，例如像交易查询这样的动态内容，我们其实需要服务端程序按 照一定的业务逻辑处理请求后从存储层 获取数据，那么这种动态资源是没法做静态化处理的，还有一部分资源例如场景三里的图片以及营销的html片段，这些资源写好后在有效时间内是不会发生变化 的，那么这块内容虽然时效性可能会有差异，但是它却是可以在这段时间做静态化处理的，还有种情形就是场景二了，这个场景虽然使用数据需要服务端参入计算， 但是计算结果在一定时间范围内是不变的，也就是说结果是可以被缓存的，那么这块的资源也是可以当做静态化资源进行处理的，为什么说拆分策略要考虑服务端应 用的因素了？因为上面这些场景都是由服务端应用参入的形式所决定，在有效时间里服务端应用不需要参入，或者参入一次后，可以长期保存结果，那么我们可以把 这些资源当做静态资源处理。

　　除此之外，服务端应用和结果的密切度也是要当做考虑的因素的。在web开发里，除了需要浏览器处理的，其他技术都可以当做服务端来理解，如果我们网站使 用到了CDN，使用到了静态web服务器例如apache，以及服务端的web容器例如jboss，那么按请求的行进路径，我们结果处理越早那么网站响应 效率也就越高，所以当请求在CDN返回了，那么肯定比在apache返回效率高，在apache就返回了肯定比jboss返回的效率高，再则服务端的 web容器本身因为服务端程序运行要消耗部分系统资源，所以它在处理请求的效率会比CDN和apache差很多，所以当我们按照动静分离策略拆分出了静态 资源后，这个资源能不放在最底层的服务端的web容器处理就不要放在服务端的web容器里处理。

　　由上所述，我们再回过头来看看静态web服务器的SSI技术，这个技术使用起来和我们在服务端使用include类似，但是在SSI使用include一定会比在服务端效率高，因为服务端在整合动静资源时候还会掺杂很多服务端程序处理，因此动静资源的效率就会大打折扣。我们再看看SSI的include的用法，如下所示：

<!--#include file="info.htm"-->

　　这个写法是使用页面的注释标签， 当静态web容器处理请求时候，它会扫描里面的SSI标签，接着就会处理这个标签的内容，如果找到了资源那么web容器会将资源插入到页面里，如果web 没有处理这个SSI标签，那么等结果到了浏览器，这个也就是一个注释而已，不会影响页面的展示，而且SSI标签处理的资源也是非常丰富的，不管这个资源是 静态的，还是动态的，只要获取时候是个完整的资源都能被正常加入到页面里，所以像前面的场景二这种动态的内容也是可以正常处理的。因此场景二，场景三这样 的情况都可以使用SSI来解决。SSI的作用当然不仅仅只是可以做include操作，它的标签也可以做一些逻辑上的操作，讲述如何使用SSI不是本文的 重点，有兴趣的朋友可以去研究下。

　　不过SSI也有自己的局限性，它的第一个局限就是SSI解析是静态web容器来完成，因此它会消耗web容器的性能，如果SSI使用时候还有一定的逻辑，那么这种性能消耗就会更大，其实我觉得更加重要的是如果静态web容器过渡使用SSI，那么就会把自己变成了一个服务端的web容器，除了会影响到请求处理的效率，它还会降低自身的并发处理能力，所以我们希望资源整合策略交给外部服务处理效果会更好些，如是有些大型互联网公司使用ESI技术，ESI技术和缓存关系密切，这个内容我就放到下篇讨论了。

　　本篇最后我要再讲讲CDN的问题，上篇我讲到静态web容器整合动静资源的好处，由此我说如果CDN可以做动静整合，那么就能做到就近处理，这样效果 会更高，今天我对这个做法做了一些考证，觉得该说法有点不妥，至少我现在的公司没有使用到这样的技术，CDN技术应该由三个步骤组成，首先是解析DNS， 找到离用户最近的CDN服务器，接下来CDN要做一下负载均衡， 根据负载均衡策略将请求落地到最合适的一个服务器上，如果CDN服务器上就有用户所需要的静态资源，那么这个资源就会直接返回给浏览器，如果没有CDN服 务器会请求远端的服务器，拉取资源再把资源返回给浏览器，如此同时拉取的资源也被缓存在CDN服务器上，下次访问就不需要在请求远端的服务器了，CDN存储资 源的方式使用的是缓存，这个缓存的载体是和apache，nginx类似的服务器，我们一般称之为http加速器，之所以成为http加速器是为了和传统 静态web服务器区别开来，传统的静态资源服务器一般都是从持久化设备上读取文件，而http加速器则是从内存里读取，不过具体存储的计算模型会根据硬件 特点做优化使得资源读取的效率更高，常见的http加速器有varnish，squid。Ngnix加上缓存模块也是可以当做http加速器使用的，不管 使用什么技术CDN的服务器基本都是做一个就近的缓存操作，这也就是说CDN是否可以完成SSI操作是值得商榷的，所以前文的说法还是有点问题的。

来源：夏天的森林