網站靜態化處理—動靜整合方案(2)

  上篇文章我簡要的介紹了下網站靜態化的演進過程,有朋友可能認爲這些知識有點過於稀鬆日常了,並且網站靜態化的技術基點也不是那麼高深和難以理解,所以它和時下突飛猛進的web前端技術相比,就顯得不三不四了。其實當我打算寫本系列的以前我我的以爲web前端有一個點是不少人都知道重要,可是有經常低估它做用的,那就是web前端和web服務端如何融合的這個點上,這個點再加上咱們要作出一個規模龐大,高併發,快速響應的網站時候它對於web前端的架構技術的演進起到了一個不可忽視的做用。javascript

  網站的web前端要實現高效,第一個要解決的短板就是網絡的延遲性對網站的加載效率的影響,固然不少人會說網速快不快這是網絡運營商的問題,不是網站的問題,可是你們確定也見過就算咱們用上了千兆寬帶也會有些網站加載速度慢的讓人沒法忍受,網站自己的確是無法控制網絡速度的能力,可是若是咱們不下降網絡對頁面加載效率的影響,其餘任何優化網站的手段也就無從談起,緣由就是網絡效率對於網頁加載效率的影響是起到大頭做用的,只有這個大頭被解決了,那麼解決其餘的小頭才能發揮做用。php

  回到上文講到的網站靜態化的關鍵點動靜分離,解決這個關鍵點的本質就是爲了下降網速對網站加載效率的影響,可是咱們在處理動靜分離問題時候採起的策略不一樣會對咱們整個網站架構產生重大影響,特別是將網頁作好動靜拆分後,靜態的資源盡力向瀏覽器端推移,這就致使了前端架構出現了之前服務端纔有的MVC模式,這就致使web前端架構產生了質的變化,如是一些原來適用於flash這樣的重客戶端的技術也被傳統的web前端所採用,MVC模式在web前端進一步演進由此而出現了MVP(Model-View-Presenter)模式,MVVM(Model-View-ViewModel)模式。也許上篇文章裏有人對講述動靜分離的原理有點異議,可是當今突飛猛進的web前端技術就是這些常見技術不斷演化而來,這就是我上篇想表達的內容,我以爲這個系列的特色應該是細節,這是和上個系列存儲的瓶頸注重思想是有所不一樣的。css

  動態網站最難以動靜分離的就是頁面了,其餘的靜態資源例如:圖片、外部腳本文件等等這些和靜態網站的手法基本一致,其實業界很早就關注了動態網站的動靜分離問題,而且爲不一樣的動靜分離方案都進行了總結,今天我就介紹下這些技術。本人web服務端的工做語言是java,所以下面服務端的例子是使用java的web技術闡述的,其餘語言例如php都有與之對應的技術,因此請那些不是使用java做爲服務端工做語言的朋友能夠類比學習。html

  在java的web開發裏,頁面技術jsp自己就包含了將頁面動靜分離的手段,例以下面的代碼:前端

複製代碼
<%@ include file=」header.jsp」 %>

<body>

         ……….

<%@ include file=」footer.jsp」 %>
複製代碼

  通常一個網站的頭部和尾部都是同樣,所以咱們把頭部的代碼單獨放置在一個header.jsp頁面裏,頁面尾部的代碼放置下footer.jsp頁面裏,這樣技術人員在開發頁面時候就再也不須要重複編寫這些重複的代碼,只須要引用便可,這個作法最大的好處就是能夠避免不一樣頁面在相同代碼這塊的不一致性,假如沒有這個統一引用的話,手動編寫或者複製和粘貼,出錯的機率是很是的高的。java

  可是這個作法有一個問題,問題就是這種動靜分離其實都是做用於單個頁面的,也就是說每一個頁面都要手動的重複這個動靜分離的操做,大多數狀況這種作法都不會有什麼問題,可是對於一個大型網站而言這種作法就有可能會製造沒必要要的麻煩,這裏我截取了一張京東的首頁,以下圖所示:web

 

  講述前我要事先聲明下,京東網站可能不存在我要講述的問題,我這裏只是使用京東網站的首頁作例子來講明,看圖裏的首頁和食品兩個條目,有些公司作這樣的網站時候這些導航進入的頁面會是一個獨立的工程,每一個工程都是由獨立的項目組開發維護的,雖然項目組不一樣可是他們頁面的總體結構會是一致的,若是按照上面的動靜分離手段,那麼每一個項目組都要獨立維護一份相同的頭部尾部資源,這個時候麻煩來了,若是該公司要新增個新的條目,那麼每一個項目組都要更新本身不變的資源,若是該企業一共分了5個項目組,如今又作了一個新的條目,那麼其餘與之無關的項目組都得折騰一次更改統一引用文件的工做,要是作的不仔細就有可能出現頁面展現不一致的問題,爲了解決這個問題,java的web開發裏就會考慮使用模板語言替代jsp頁面技術,例如模板語言velocity,這些模板語言都包含一個佈局的功能,例如velocity就有這樣的功能,咱們看看velocity的佈局模板實例,以下所示:ajax

複製代碼
<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方式區別不大,那麼咱們再看看下面的代碼:spring

<property name="layoutUrl" value="layout/default.vm"/><!--指定layout文件-->

 

  這是佈局文件的引用方式,咱們能夠把佈局文件放置在網絡上,項目裏應用這個文件所在地址便可,這樣咱們就把項目裏不變的靜態資源抽取在同一個地方,若是在碰到佈局要作修改,那麼咱們只須要改一個地方便可。apache

  無論服務端採起何種動靜分離,動靜資源的整合都是有服務端完成,按照上文提到網站靜態化的思想,這些作法不會給網站性能提高帶來任何好處,它們只是給開發,運維提供了便利而已,按前文的思路,咱們要把動靜分離往前移,服務端往前移碰到的第一個點就是靜態的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/4314387.html

相關文章
相關標籤/搜索