【轉】關於大型網站技術演進的思考（十二）--網站靜態化處理—緩存（4）

　　上篇我補充了下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容器，若是咱們讓靜態資源緩存在內存裏，效率確定也是比在硬盤上高。

　　好了，今天就寫到這裏，最後祝你們生活愉快，新年快樂。

 

原來連接：http://www.cnblogs.com/sharpxiajun/p/4289298.html