关于大型网站技术演进的思考(十)网站静态化处理—动静整合方案（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页面里，这样技术人员在开发页面时候就不再需要重复编写这些重复的代码，只需要引用即可，这个做法最大的好处就是可以避免不同页面在相同代码这块的不一致性，假如没有这个统一引用的话，手动编写或者复制和粘贴，出错的概率是非常的高的。

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

　页面里我们可以引入这个布局格式，这个布局文件其实就是页面里不变的东西抽取了出来，它完成了页面动静分离，页面只要应用这个布局文件即可，到了这里这个布局文件和前面的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有一种标签，例如：

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

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

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

<esi:include src="test.vm.esi?id=100" max-age="45"/>

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

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

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

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

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

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

文章出自:http://www.cnblogs.com/sharpxiajun/p/4285085.html

      本文转自027ryan  51CTO博客，原文链接：http://blog.51cto.com/ucode/1743266，如需转载请自行联系原作者