關於大型網站技術演進的思考（十）--網站靜態化處理—動靜整合方案（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本身就包含了將頁面動靜分離的手段，例如下面的程式碼：
<%@ include file=”header.jsp” %><body> ………. <%@ include file=”footer.jsp” %>
一般一個網站的頭部和尾部都是一樣，因此我們把頭部的程式碼單獨放置在一個header.jsp頁面裡，頁面尾部的程式碼放置下footer.jsp頁面裡，這樣技術人員在開發頁面時候就不再需要重複編寫這些重複的程式碼，只需要引用即可，這個做法最大的好處就是可以避免不同頁面在相同程式碼這塊的不一致性，假如沒有這個統一引用的話，手動編寫或者複製和貼上，出錯的概率是非常的高的。
但是這個做法有一個問題，問題就是這種動靜分離其實都是作用於單個頁面的，也就是說每個頁面都要手動的重複這個動靜分離的操作，大多數情況這種做法都不會有什麼問題，但是對於一個大型網站而言這種做法就有可能會製造不必要的麻煩，這裡我截取了一張京東的首頁，如下圖所示：
講述前我要事先宣告下，京東網站可能不存在我要講述的問題，我這裡只是使用京東網站的首頁做例子來說明，看圖裡的首頁和食品兩個條目，有些公司做這樣的網站時候這些導航進入的頁面會是一個獨立的工程，每個工程都是由獨立的專案組開發維護的，雖然專案組不同但是他們頁面的整體結構會是一致的，如果按照上面的動靜分離手段，那麼每個專案組都要獨立維護一份相同的頭部尾部資源，這個時候麻煩來了，如果該公司要新增個新的條目，那麼每個專案組都要更新自己不變的資源，如果該企業一共分了5個專案組，現在又做了一個新的條目，那麼其他與之無關的專案組都得折騰一次更改統一引用檔案的工作，要是做的不仔細就有可能出現頁面展示不一致的問題，為了解決這個問題，java的web開發裡就會考慮使用模板語言替代jsp頁面技術，例如模板語言velocity，這些模板語言都包含一個佈局的功能，例如velocity就有這樣的功能，我們看看velocity的佈局模板例項，如下所示：
<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> <title>#springMessage("page_upop_title")</title> <meta http-equiv="X-UA-Compatible" content="requiresActiveX=true"/> <meta name="keywords" content='#springMessage("page_upop_keywords")'/> <meta content='#springMessage("page_upop_description")' name="description"/> </head> <body oncontextmenu="return false" onselectstart="return false"> #if($pageHead) #parse($pageHead) #end $screen_content #parse($page_footer) </body> </html>
頁面裡我們可以引入這個佈局格式，這個佈局檔案其實就是頁面裡不變的東西抽取了出來，它完成了頁面動靜分離，頁面只要應用這個佈局檔案即可，到了這裡這個佈局檔案和前面的include方式區別不大，那麼我們再看看下面的程式碼：
<property name="layoutUrl" value="layout/default.vm"/><!--指定layout檔案-->
這是佈局檔案的引用方式，我們可以把佈局檔案放置在網路上，專案裡應用這個檔案所在地址即可，這樣我們就把專案裡不變的靜態資源抽取在同一個地方，如果在碰到佈局要做修改，那麼我們只需要改一個地方即可。
不管服務端採取何種動靜分離，動靜資源的整合都是有服務端完成，按照上文提到網站靜態化的思想，這些做法不會給網站效能提升帶來任何好處，它們只是給開發，運維提供了便利而已，按前文的思路，我們要把動靜分離往前移，服務端往前移碰到的第一個點就是靜態的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的使用是本系列的重點，我會在後面文章裡重點講解。
好了，今天就寫到這裡，祝大家生活愉快，晚安。
相關推薦
關於大型網站技術演進的思考（十）--網站靜態化處理—動靜整合方案（2）
上篇文章我簡要的介紹了下網站靜態化的演進過程，有朋友可能認為這些知識有點過於稀鬆平常了，而且網站靜態化的技術基點也不是那麼高深和難以理解，因此它和時下日新月異的web前端技術相比，就顯得不倫不類了。其實當我打算寫本系列的之前我個人覺得web前端有一個點是很多人都知道重要，但是有常常低估它作用的，那就是we
網站靜態化處理—動靜整合方案
上篇文章我簡要的介紹了下網站靜態化的演進過程，有朋友可能認為這些知識有點過於稀鬆平常了，而且網站靜態化的技術基點也不是那麼高深和難以理解，因此它和時下日新月異的web前端技術相比，就顯得不倫不類了。其實當我打算寫本系列的之前我個人覺得web前端有一個點是很多人都知道重要，但是有常常低估它
關於大型網站技術演進的思考（十一）--網站靜態化處理—動靜分離策略（3）
前文裡我講到了網站靜態化的關鍵點是動靜分離，動靜分離是讓動態網站裡的動態網頁根據一定規則把不變的資源和經常變的資源區分開來，動靜資源做好了拆分以後，我們就可以根據靜態資源的特點將其做快取操作，這就是網站靜態化處理的核心思路。由此可見，網站靜態化處理的核心就是動靜分離和快取兩大方面，上篇我簡單講述了動靜整合
關於大型網站技術演進的思考（十四）--網站靜態化處理—前後端分離—上（6）
前文講到了CSI技術，這就說明網站靜態化技術的講述已經推進到了瀏覽器端了即真正到了web前端的範疇了，而時下web前端技術的前沿之一就是前後端分離技術了，那麼在這裡網站靜態化技術和前後端分離技術產生了交集，所以今天我將討論下前後端分離技術，前後端分離技術討論完後，下一篇文章我將會以網站靜態化技術的角度回過
關於大型網站技術演進的思考（十五）--網站靜態化處理—前後端分離—中（7）
上篇裡我講到了一種前後端分離方案，這套方案放到服務端開發人員面前比放在web前端開發人員面前或許得到的掌聲會更多，我想很多資深前端工程師看到這樣的技術方案可能會有種說不出來的矛盾心情，當我的工作逐漸走向越來越專業化的前端開發後，我就時常被這套前後端分離方案所困惑，最近我終於明白了這個困惑的本源在哪裡了，那
關於大型網站技術演進的思考（十七）--網站靜態化處理—滿足靜態化的前後端分離（9）
前後端分離的主題雖然講完了，但是前後端分離的內容並沒有結束，本篇將繼續前後端分離的問題，只不過這次前後端分離的講述將會圍繞著本系列的主題網站靜態化進行。在講本篇主題之前，我需要糾正一下前後端分離主題講述中會讓朋友們產生誤導的地方，這種誤導就是對時下流行的一些前後端分離方案（沒有使用nodejs的前後端分離
關於大型網站技術演進的思考（十六）--網站靜態化處理—前後端分離—下（8）
我第一次聽說nodejs技術大概是在2009年年末，不過我真正認真在網路上進一步瞭解nodejs還是在2010年年中，當時對nodejs的認識和我現在對nodejs的認識有著天壤的區別，開始想了解nodejs我只是為了感慨谷歌公司開發的V8引擎居然如此強大，它不僅僅可以作為chrome瀏覽器的javasc
關於大型網站技術演進的思考（十九）--網站靜態化處理—web前端優化—上（11）
對於一個網路請求的處理，是由兩個不同型別的操作共同完成，這兩個操作是CPU的計算操作和IO操作，如果我們以處理效率角度來評判這兩個操作，CPU操作效率是光速的，而IO操作就不盡然了，計算機裡的IO操作就是對儲存資料介質的操作，計算機裡有如下幾個介質可以儲存資料，它們分別是：CPU的一級快取、二級快取、記憶
關於大型網站技術演進的思考（十八）--網站靜態化處理—反向代理（10）
反向代理也是一種可以幫助實現網站靜態化的重要技術，今天我就來講講反向代理這個主題。那麼首先我們要了解下什麼是反向代理。和反向代理相對應的是正向代理，正向代理也就是我們常說的代理服務，正向代理是非常常見的，例如在某些公司裡我們想使用網際網路，那麼我們就得在瀏覽器裡設定一個代理伺服器，通過代理伺服器我們才能正
關於大型網站技術演進的思考（十二）--網站靜態化處理—快取（4）
上篇我補充了下SSI的知識，SSI是一個十分常見的技術，記得多年前我看到很多入口網站頁面的字尾是.shtml，那麼這就說明很多入口網站都曾經使用過SSI技術，其實現在搜狐網站也還在用shtml，如下圖所示： 由此可見SSI在網際網路的應用還是非常廣泛的。其實網際網路很多網頁如果我們按照動靜分離
關於大型網站技術演進的思考（五）--存儲的瓶頸（5）
做了 技術分享 表數 例子 執行 同時 設備 系統重啟 拆分 原引：http://www.cnblogs.com/sharpxiajun/p/4265853.html 上文裏我遺留了兩個問題，一個問題是數據庫做了水平拆分以後，如果我們對主鍵的設計采取一種均勻分布的策略，那麽
關於大型網站技術演進的思考（二）--儲存的瓶頸（2）
上篇裡我講到某些網站在高併發下會報出503錯誤，503錯誤的含義是指網站服務端暫時無法提供服務的含義，503還表達了網站服務端現在有問題但是以後可能會提供正常的服務，對http協議熟悉的人都知道，5開頭的響應碼錶達了服務端出現了問題，在我們開發測試時候最為常見的是500錯誤，500代表的含義是服務端程式出
關於大型網站技術演進的思考（九）--網站靜態化處理--總述（1）
在儲存瓶頸的開篇我提到像hao123這樣的導航網站只要它部署的web伺服器數量足夠，它可以承載超大規模的併發訪問量，如果是一個動態的網站，特別是使用到了資料庫的網站是很難做到通過增加web伺服器數量的方式來有效的增加網站併發訪問能力的。但是現實情況是像淘寶、京東這樣的大型動態網站在承擔高併發的情況下任然能
關於大型網站技術演進的思考（六）--儲存的瓶頸（6）
在講資料庫水平拆分時候，我列出了水平拆分資料庫需要解決的兩個難題，它們分別是主鍵的設計問題和單表查詢的問題，主鍵問題前文已經做了比較詳細的講述了，但是第二個問題我沒有講述，今天我將會講講如何解決資料表被水平拆分後的單表查詢問題。 要解決資料表被水平拆分後的單表查詢問題，我們首先要回到問題的源頭，我們
關於大型網站技術演進的思考（一）--儲存的瓶頸（1）
前不久公司請來了位網際網路界的技術大牛跟我們做了一次大型網站架構的培訓，兩天12個小時資訊量非常大，知識的廣度和難度也非常大，培訓完後我很難完整理出全部聽到的知識，今天我換了個思路是回味這次培訓，這個思路就是通過本人目前的經驗和技術水平來思考下大型網站技術演進的過程。 首先我們要思考一個問題，什麼樣
關於大型網站技術演進的思考（四）--儲存的瓶頸（4）
如果資料庫需要進行水平拆分，這其實是一件很開心的事情，因為它代表公司的業務正在迅猛的增長，對於開發人員而言那就是有不盡的專案可以做，雖然會感覺很忙，但是人過的充實，心裡也踏實。 資料庫水平拆分簡單說來就是先將原資料庫裡的一張表在做垂直拆分出來放置在單獨的資料庫和單獨的表裡後更進一步的把本來是一個整體
關於大型網站技術演進的思考（七）--儲存的瓶頸（7）
本文開篇提個問題給大家，關係資料庫的瓶頸有哪些？我想有些朋友看到這個問題肯定會說出自己平時開發中碰到了一個跟資料庫有關的什麼什麼問題，然後如何解決的等等，這樣的答案沒問題，但是卻沒有代表性，如果出現了一個新的儲存瓶頸問題，你在那個場景的處理經驗可以套用在這個新問題上嗎？這個真的很難說。 其實不管什麼
關於大型網站技術演進的思考（五）--儲存的瓶頸（5）
上文裡我遺留了兩個問題，一個問題是資料庫做了水平拆分以後，如果我們對主鍵的設計採取一種均勻分佈的策略，那麼它對於被水平拆分出的表後續的查詢操作將有何種影響，第二個問題就是水平拆分的擴容問題。這兩個問題在深入下去，本系列就越來越技術化了，可能最終很多朋友讀完後還是沒有找到解決實際問題的啟迪，而且我覺得這些問
關於大型網站技術演進的思考（三）--儲存的瓶頸（3）
儲存的瓶頸寫到現在就要進入到深水區了，如果我們所做的網站已經到了做資料庫垂直拆分和水平拆分的階段，那麼此時我們所面臨的技術難度的挑戰也會大大增強。 這裡我們先回顧下資料庫的垂直拆分和水平拆分的定義： 垂直拆分：把一個數據庫中不同業務單元的資料分到不同的資料庫裡。 水平拆分：是根據一定的規
關於大型網站技術演進的思考（十三）--網站靜態化處理—CSI（5）
講完了SSI，ESI，下面就要講講CSI了 ，CSI是瀏覽器端的動靜整合方案，當我文章發表後有朋友就問我，CSI技術是不是就是通過ajax來載入資料啊，我當時的回答只是說你的理解有點片面，那麼到底什麼是CSI技術了？這個其實要和動靜資源整合的角度來定義。 CSI技術其實是在頁面進行動靜分離後，將頁面