網站靜態化處理—動靜分離策略（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操做是值得商榷的，因此前文的說法仍是有點問題的。

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