关于大型网站技术演进的思考（十二）--网站静态化处理—缓存（4）

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

　　下面我们要讨论下动静分离的策略了，一个页面什么内容是动态的，什么内容是静态的，这个我们到底该如何来区分了？这个问题学问非常大，我们的标准不同，最后拆分出来的动静资源就会存在很大的不同。在本系列开篇里，我提到了什么样的页面是静态页面，什么样的页面是动态页面，我是以一个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操作是值得商榷的，所以前文的说法还是有点问题的。

　　好了，今天就写到这里，祝大家生活愉快。

上篇我补充了下SSI的知识，SSI是一个十分常见的技术，记得多年前我看到很多门户网站页面的后缀是.shtml，那么这就说明很多门户网站都曾经使用过SSI技术，其实现在搜狐网站也还在用shtml，如下图所示：

 


　　由此可见SSI在互联网的应用还是非常广泛的。其实互联网很多网页如果我们按照动静分离策略拆分，绝大部分都是可以当做静态资源处理，例如新闻网站，文学网站，这些网页生成后，大部分的资源都是不变的，说白了这些网页本质就是一个静态页面，我们开发他们时候也不需要服务端的参入，每一个网站都有自己固定的板式，假如每个新网页都要完完整整的开发，重复性的工作实在太多了，出错的概率也非常高，在本系列第二篇里我曾经详细介绍了velocity的布局模板技术，其实SSI也可以制作出一套固定的模板，开发时候我们只需要在定义好的模板里添加或者修改我们需要更改的内容就可以完成一个页面的制作，可见SSI技术为了我们开发网页提供了很大的便利。

　　与SSI相对应的还有ESI，这个技术不是太常用，在网上能收集到的资料也不是太多，网上有限的资料也基本都是和淘宝相关的，不过仔细研究下淘宝对ESI的运用，对于理解网站静态化处理是非常有借鉴意义的，下面我将重点讲讲ESI的知识。首先看个场景啊。

　　我们登录支付宝网站，到了个人首页我们发现在支付宝下面有一个条目，如下图所示：

        


　　这是支付宝默认给我们显示的【生活好助手】，右边有个箭头，我们点开它，如下图所示：

 

　　我们看到这里有添加的按钮，通过添加按钮，我们可以添加其他常用的组件图标。（注意：我这里只是以支付宝这个功能为例，支付宝是否按照我说的设计，这个我就不清楚了）

　　如果我们按照自己个性化添加了自己的组件，不同的人添加的常用组件也会是不尽相同的，如果我们自己开发的网站也有这样的功能，那么我们该如何设计了？我们一般都会很直观的把这个新增的组件信息存储在数据库里，用户每次登录时候该信息也会随之从数据库里读取，但是这个场景对于像支付宝这种用户量极大，日均访问量极高的大型网站，这种个性化又非核心的功能都从数据库里读取，那么它对数据库造成的压力一定是十分巨大的，在存储的瓶颈里我们讲了那么多优化数据库的手段，其核心手段有一个就是减少对数据库价值不高的操作，而这种个性化配置跟支付宝的支付操作相比起来，价值度实在太低，因此我们最好的选择是避免数据库承担过多此类的操作。

　　不过像上面这个场景里的功能，它所使用的数据又不是那种可有可无的，假如数据存储的不可靠造成数据丢失还是会造成不必要的麻烦，所以我们还是会把这些信息做持久化存储。此外像上面的【生活好助手】条目还是页面的一个重要组成部分，因此像SSI那种使用html注释指令，当指令无法正常解析，就直接返回到浏览器，因为是注释，所以页面也不会显示它，SSI的这种做法用在上面场景肯定是不太合适的。这样的场景在电商网站里是十分常见的，例如一个商品页面，页面里会有商品的图片，还有商品的详细介绍，这些内容其实都是会用持久化系统进行存储，同时它们本身也是网页的重要做成部分，如果碰到问题就忽略最终会造成页面显示错误。

　　结合上面的场景我们来讨论下ESI技术了，ESI技术和SSI技术类似，其实也和jsp里的include指令类似，它也是在页面里使用一个指令标签web容器解析这个标签后将获取的数据替换掉这个标签。我们来看看ESI的使用方法，我们可以在velocity里自定义一个esi标签，velocity里的使用如下所示：

esiTool.setTemplate('test.vm').addQueryData('id', 100)

 
 

　　velocity引擎解析vm模板，最终会把vm解析成html页面，这个时候该页面里使用esi标签的地方就被转化为：

<esi:include src="test.vm.esi?id=100" />

 
 

　　当页面到了服务端web容器之前的静态web容器（该web容器要安装好解析esi的模块），静态web容器就会解析这个esi标签，静态web容器会以test.vm.esi?id=100 作为key，到缓存系统里查找信息，如果查到了信息，缓存服务器就直接返回，用返回内容替换掉esi标签，如果缓存里没有找到则会直接请求持久化系统，持久化系统返回信息后，缓存系统将信息缓存起来，同时也将信息返回至静态web容器，那么下次用户再访问同样内容就会直接从缓存里读取了。

　　ESI技术和SSI很像，只不过ESI技术是和缓存技术配合起来的，同时ESI标签也不像SSI标签那样使用注释的形式，因此ESI标签是一定要被解析的，如果仅仅是缓存，ESI和SSI比较起来也没显得那么有优势和特别，但是对于电商这种场景而言ESI的现实意义非常大，电商网站也是一个由用户产生内容的网站，每一个商家的店铺虽然我们都知道它是属于淘宝或天猫的，但是单独一个商家的店铺都是个性化很强的，与其他店铺差异很大，为了买卖商品，商家会上传自己商品的图片，还会使用图片和文字描述自己的商品，单个商品页面我们做动静分离分析，很容易分辨出动态内容和静态内容，但是如果一个电商平台拥有超乎想象数量的商家，那么每个页面的图片，文字和商家页面的关系就会变得有点微妙了。由于电商网站的图片特别多，那么电商网站系统一般都会设计一套管理这些小图片的分布式存储系统，例如淘宝的TFS文件系统，它是专门针对图片使用的分布式文件系统，这些文件系统里存储的图片会和商家紧密关联，这就让图片本身拥有了一定的动态属性，但是对于每个商家页面而言，商家自己的图片资源都是可以静态化的，也就是说图片的读取是要通过商家信息进行计算的，计算出的结果对于商家而言又是静态的，可以被缓存的。但是这个静态资源的处理时候就变得复杂了，而这些是SSI无法完成的。

　　首先我们直接从文件系统读取图片，效率是非常低效，因此我们还是会把它们缓存在内存里，但是由于不同图片和不同商户是相关联，那么对于缓存查找时候是需要一定的条件，不同商户对自己页面的设计方案也会有所不同，一般商户这些资源，存储系统肯定会按照设计模板的维度存储，不同商家由于商品和文化的不一样，那么使用的模板也不一样，因此资源返回静态web容器前还需要一个整合过程，这样场景下的静态资源获取其实是需要一定逻辑计算的，那么这个计算一般都会在开发时候由代码完成，所以从上面ESI使用的例子看到，开发人员会使用velocity的esi标签，这个标签开发人员可以设置参数，velocity引擎最终会将这个标签解析成静态web容器可以解析的esi标签，标签里有这样的代码test.vm.esi?id=100，文件后面会带上参数，那么这个参数其实是动态的，那么这个参数也就是缓存系统获取正确信息的规则了。这样我们就完成了静态资源获取的逻辑计算，计算完毕后这些资源会在一段时间里长期有效，因此它就演变为静态资源，可以被缓存了。ESI比SSI强大多了，同时ESI也可以完成SSI的功能，所以使用了ESI也就没必要用SSI了。

　　像我们平时做web开发时候可能没有太留心一个问题，一般的web开发里使用的静态资源例如图片，css文件，js文件我们都会放置在一个resource包里，如果是企业开发，这个web应用上线时候也就直接打包在web工程里，一些互联网网站也只不过会将这些资源放置在单独的静态服务器上，我平时开发时常听到有人说，项目里图片太多了，应该合并下，css文件和js文件也太多了也要合并下，这个多到底多多少了，几十个文件，几百个文件，这个要和社交网站，电商网站这种用户可以产生图片的网站比起来那就是小巫见大巫了，因为用户能产生内容的网站静态资源会随着时间推移文件规模变得异乎寻常的大，所以此类网站的静态资源已经没法放置在项目下，它就要求我们需要有新的手段管理这些静态资源，并且有新的手段使用这些静态资源，那么像TFS文件存储系统出现了，缓存技术出现了，最后我们在应用里使用ESI技术把它们整合到我们网页里，通过这个分析我们就能明白ESI适用的业务场景了。

　　网站静态化处理我们首先要按规则拆分动静资源，拆分出来的静态资源该如何处理就是网站静态化处理的关键所在，把静态资源处理从服务端的web应用里剥离出来，不让服务端的web应用参入过多的静态资源解析，这样就可以为服务端的web应用减少不必要的处理操作，从而达到提升服务端web应用的运行效率，接着我们就把拆分出来的静态资源处理操作往前推移到静态web服务器，前两篇文章和今天的文章我着重讲解了静态web服务器处理静态资源的手段，那么这里有个问题了，这些处理可以再往前推到浏览器来完成吗？答案当然是否定的，首先浏览器的缓存是非常不可靠的，如果用户把浏览器设置为不缓存任何数据的模式，那么浏览器就没法缓存数据了，而用户的行为那是根本没法控制的，其次浏览器缓存的数据量是有限的，如果我们要在浏览器进行缓存也是缓存最有价值缓存的数据，更重要的一点，为了做好网站静态化处理我们对网页的动静资源做了拆分，但是拆分出的静态资源也并不是完全不需要进行任何逻辑处理就能使用的，例如前面讲到的ESI适用的场景我们就发现，有些静态资源的获取还是要很多条件的参入，而这些条件是由动态数据产生的，那么这样的静态数据浏览器是没法做缓存的，这点也说明了拆分出来的静态化资源绝大部分还是要停留在服务端的，居然只能停留在服务端，那么最为高效的处理这些静态资源的地方就是CDN和静态web容器了。所以在本系列的第一篇里我讲到网站生产部署时候最好是在服务端web应用之前放置一个静态web容器，如果有了这样的静态web容器做反向代理，那么我们就可以让它来完成静态资源的相关操作，而且静态web容器还能辅助完成一些逻辑上的处理，从而弥补了CDN的不足之处。当然这么做的好处不仅仅只有这些，第二篇文章里我曾经讨论了反向代理的好处，可能大家印象还不是很深刻，我将会在后面文章里对反向代理做更加深入的分析。

　　讲完了ESI的妙用后，我下面将讲讲本篇的主题缓存了。其实单独讲缓存真的没啥太多内容，不过在网站静态化处理里的缓存还是和存储里讲到的分布式缓存有所不同，分布式缓存的数据都是存储在内存里，而网站静态处理的缓存既有存储在内存里还有存储在硬盘上，当然存储在内存里读取速度会更快，但是网站的读取效率还和资源距离用户的远近有关系，例如浏览器的缓存其实是把静态内容缓存在硬盘上，但是因为不需要通过网络获取资源，因此它的读取效率就显得特别高了，除了这个因素外还有个因素，我们前面做动静拆分的目的就是想拆分出静态资源，让这些静态资源远离服务端的web应用，这样可以减少服务端不必要的压力，从而达到提升服务端web应用处理能力，而把静态资源放置在静态web容器处理，它的处理静态资源效率又会高于在服务端web应用的处理，从而也达到提升静态资源读取的效率。不过如果静态资源最终只能放置在服务端，那么这个时候我们把静态资源存入到缓存里即内存里效率肯定比在硬盘上高，所以CDN的服务节点一般都是采取将静态资源存储在内存里，就算是服务端web应用前的静态web容器，如果我们让静态资源缓存在内存里，效率肯定也是比在硬盘上高。

　　好了，今天就写到这里，最后祝大家生活愉快，新年快乐。