關於大型網站技術演進的思考（十九）：網站靜態化處理—Web前端優化—上（11）

發表於2015-03-09
網站Web前端優化

網站靜態化處理這個系列馬上就要結束了，今天我要講講本系列最後一個重要的主題web前端優化。在開始談論本主題之前，我想問大家一個問題，網站靜態化處理技術到底是應該歸屬於web服務端的技術範疇還是應該歸屬於web前端的技術範疇，要回答清楚這個問題我們要明確下網站應用的本質到底是什麼？網站的本質其實就是BS，這裡的BS我沒有帶上架構二字，而就是指Browser和Server即瀏覽器和伺服器，而網站靜態化技術的作用目標就是讓客戶端即瀏覽器的使用者體驗更好，但是如果我們想讓網站在瀏覽器上執行的更快，在更快的基礎上能設計更多更好的使用者體驗功能，那麼我們需要做的工作其實就不僅僅是著眼於瀏覽器本身，而是要把和瀏覽器相關的一切作用因子結合在一起考慮，這就是網站靜態化技術的本源所在，所以有些朋友認為網站靜態化技術其實是一個服務端技術多於web前端的技術，因此認為網站靜態化技術是不屬於web前端的範疇，我認為這種理解是不正確的，我想產生這種誤導的原因是很多人都是狹義的理解web前端技術，認為web前端就是以javascript、css以及html所代表的技術，超出這個範疇的技術就不應該屬於web前端範疇，我個人覺得這種理解也無可厚非，但是這種理解可能會讓那些有追求的前端工程師產生一個不好的後果，這個後果就是不靈活的劃分自己需要掌握的技術範疇，最終影響自身技術能力的突破，不管是web前端還是web服務端都應該把做好優秀的網站為己任。BS本身就是一個整體，只有二者結合起來才能產生網站，缺少其中任何一方，那又何來的網站呢？BS中的S就猶如蝴蝶效益裡蝴蝶的翅膀，雖然蝴蝶看起來只是在亞馬遜雨林輕輕的揮動了一下，可是這個揮動卻能讓相距千萬裡的太平洋上颳起可怕的颶風，因此本人對web前端有個新的認識，我們不應該把前端只是侷限於javascript、css和html這些技術之上，而是應該把自己當做瀏覽器應用開發專家，一切用作於瀏覽器的技術和手段都是web前端工程師需要掌握的知識，就像時下的nodejs出現，逼得前端工程師不得不去做服務端開發，不要覺得這是被迫的，而要把它當做web前端的逆襲，認為這是理所當然的事情。

好了，我們現在回到web前端優化這個主題吧。Web前端優化技術的普及還是要歸功於網際網路兩大巨頭雅虎和谷歌的貢獻，他們通過多年的積累和總結，將這些web前端優化的經驗無償的公佈給全世界，從而推動了web前端的發展，這些技術都不是什麼祕密，我在網上找到一篇講解這些技巧的文章，文章就是《Web前端優化最佳實踐及工具集錦》。

web前端優化技術和網站靜態化技術使用目的是一致的，就是讓網站變得更快，使用者體驗更好，我個人認為網站靜態化技術其實就是web前端優化的一部分，只不過網站靜態化技術是通過服務端的大規模技術改造來實現web前端技術優化，而服務端的這種改造的目的就是讓整個網站的後臺技術架構更加切合web前端的要求，從而能更好的實現web前端優化。我這裡之所以能如此評價網站靜態化技術，其實說明網站靜態化技術和web前端優化技術一定存在某種強烈的切合點，我個人認為這個切合點就是它們背後使用的理論基點是一致的。那麼它們之間這個切合的理論基點到底是什麼呢？

優秀的網站應該是使用者體驗好的網站，當人們使用這個網站感覺爽，好評不斷，那麼這個網站就是一個使用者體驗優秀的網站，但是使用者體驗好的網站就是網站佈局精美，圖片很炫，人性化設計到位這麼簡單嗎？這些要素都是網站使用者的感受，但是對於網站設計和開發人員而言，再好的網站一定要解決一個根本問題，那就是網站載入的速度要快，如果網站載入速度不快，你就算把網站設計的再漂亮，估計也會搞的無人問津，說到這裡，是不是有較真的朋友不信我的結論呢？我把前面引用文章裡的一張圖再給大家瞧瞧，如下圖所示：

其實當我們開發網站如果只考慮如何把網站做的漂亮而忽視網站的效能，我們就會發現漂亮的網站和網站的效能其實是矛與盾的關係，例如精美的圖片往往需要高質量的圖片格式，而高質量的圖片格式就意味圖片會變得很大，那麼在圖片通過網路載入時候就需要花費更多的時間，所以我們在設計和開發優秀網站時候，漂亮和效率是需要我們認真權衡的，認真思考的，最終要找到一個最好的方式實現二者的平衡，同時更加充分的發揮雙方的潛在價值。而直觀的使用者體驗好這其實更多的是一個設計問題，而解決使用者體驗好的根基：速度問題，這就是一個技術問題了。

要解決網站的速度和效率問題，那麼我們就得思考網站的載體計算機到底哪些因素會影響網站的速度和效率。其實計算機的本質很簡單，那就是計算和儲存，計算主要是CPU來完成，而計算機用於儲存的介質就多了，它們主要是記憶體、硬碟，如果是網站應用還有個很關鍵的儲存介質需要考慮那就是網路了。那麼計算機用於計算和儲存的這些介質的效率是怎樣的一個情況呢？這個問題我在以前一篇文章裡有過闡述，這篇文章就是《關於如何提高Web服務端併發效率的非同步程式設計技術》

這篇文章的其他內容太多了，我把關鍵部分在本文摘抄一遍，內容如下：

由此可見網站的速度和效率問題似乎都是由儲存即IO造成的。不過我們不能因為感覺發現問題根源在於儲存，而就忽視對CPU的思考，所以我先講講CPU和網站效能的關係吧。CPU是計算機用於做計算的裝置，現在的電腦能看電影，能聽歌，可以和朋友聊天，還能用於工作，這些令人稱奇的功能其實到了CPU這裡也就是通過加減乘除這類基本的數學運算完成的，說到這個真是難以讓人想象，讀書時候學數學總是覺得那麼枯燥乏味，沒想到如此強大的人類神器居然就是通過數學運算得來的，難怪有國外科學家說宇宙都是通過數學運算得來的，這還是有道理的。不過網站背後的數學運算卻有著自己的特點，雖然CPU計算能力很強，但是在實際場景下很多業務的計算其實很消耗時間的，如果網站某些請求響應背後的運算是需要消耗太多的時間，那麼這個時候CPU也就會成為網站效能的瓶頸所在，網站應用有個重要的特點，這個特點有個專有名詞描述那就是網站的實時性，根據網站實時性的特點，那麼就要求我們網站每個請求所包含的計算都要簡單和快捷，簡單快捷的計算也就讓每個請求背後所包含的業務性運算要更加簡單，這也就是為什麼很多人會說網際網路的網站和企業的web應用相比，網際網路的業務邏輯比較簡單的道理，但是隨著網站的規模擴大，業務模式越來越豐富，這個時候網站在某些業務環節不可避免的變得複雜，假如這些複雜的業務又需要實時的反應給使用者，那麼CPU不能快速完成業務計算就是網站的效率問題的根源了，例如我在儲存系列裡說到的海量資料的計算操作，就是這樣的場景之一，那麼這個時候我們該如何來做了？

碰到這個問題，我們首先要明確一個問題，計算出現了瓶頸，那麼最直接的手段就是增加計算機的計算能力，比如使用運算更快的CPU，但是更快的CPU面對快速增長的業務而言，增加的效率是非常有限的，所以在CPU這塊出現了多核技術，我們可以把一個計算任務拆分成諾幹個子運算，這些子運算在不同CPU上計算，最終把結果彙總起來，但是這個手段和用更快的CPU手段一樣，面對快速增長的業務很快就會達到效能瓶頸，最終我們發現我們的業務計算任務其實已經超出了單機計算機的能力，如是乎分散式技術出現了，我們這回不再是在CPU上做文章了，而是使用多臺計算機聯合計算，但是分散式計算系統是需要網路進行互聯的，而網路是計算和儲存裡最大的短板，再加以現在網際網路的所使用的計算資源規模達到了超乎想象的程度，我們發現想通過擴充套件計算機的計算能力來解決網站快速響應的問題基本是一件無法完成的任務，那麼這個時候我們又該怎麼辦呢？

這個時候我們就要轉化思路了，因為當網站的計算瓶頸問題已經到了這個地步了，我們再去更加深入挖掘計算機的計算能力這對最終的結果影響已經意義不大了，因此我們只能從計算的相關方哪裡尋找問題的解決方案。那什麼是相關方呢？仔細分析計算相關方的確太多了，但是有一個最根本的相關方就是使用者的實際業務需求了，使用者可能認為自己的業務需求都是很明確的，例如電商裡的使用者想查詢自己的交易資料，但是這個業務問題轉移到網站的開發人員和業務人員，面對這麼多使用者的交易查詢那就是一個超級複雜的計算問題，如是網站的業務和開發人員就會根據自己系統本身的特點和問題，進一步思考使用者業務計算問題的本質，談論業務計算本質這個問題如果展開細化是非常複雜的，因為現實的業務場景實在是太多太複雜了，但是放到網站實時計算這個角度，其實有一個很簡單的解決思路，我們回顧下我們前面討論的計算瓶頸問題，其實這個問題的本質不是計算能否成功完成的問題，而是計算是否能及時完成的問題，如果使用者的請求計算的確是沒法很快完成，那麼我們就不要讓使用者覺得這個計算是能很快的完成，這個做法也有一個專有名詞那就是非同步計算，但是如果我們把難以快速完成的計算都這麼來處理，雖然讓使用者感覺網站已經很坦誠的告訴自己能力有限啊，但是苛刻的使用者可不一定會買這個賬，因此當有同型別網站使用新的技術手段解決了快速實時計算問題後，假如我們的網站還是駐步不前，那麼後果就會很嚴重了，那麼這個時候我們又該如何突破了？

那麼我們就得進一步思考計算本身到底哪裡出現了影響速度的問題，計算本身包含三個方面，首先是用於計算的計算資源，再就是做運算的工具即CPU，最後是計算的最終結果，如果業務計算慢的原因是因為資料量太大了，CPU很難快速完成，那麼這個時候我們有一些手段可以解決這個問題，我們可以把海量資料做一個分類，例如儲存系列裡說的歷史交易資料和當日交易資料的分類，當日資料因為資料量有限在一定條件下可以快速計算出來，面對歷史資料，如果我們的計算結果最終是很簡單的而且在一定時間範圍裡是不會變化的，那麼我們可不可以這麼考慮，讓這些結果提前計算出來，然後將結果儲存在效率更高的儲存裝置裡例如記憶體，當使用者請求操作這個業務計算時候我們只需要直接讀取快取裡的計算結果就行了，這樣就避免了計算，同時計算結果儲存在效率高效的快取裡，使用者獲得響應的速度也會快多了，這個其實就是網站靜態化技術裡ESI技術背後的深意了。

當然當我們要解決網站效能問題，不太可能單獨從計算或者儲存一個維度來思考，一般都是把雙方放在一起思考，按照我前面提到計算和儲存介質的效率問題，我們發現儲存其實是最容易影響網站效率的痛點，實際情況也是如此，當網站發生計算瓶頸問題之前，更多的效率問題還是由儲存所導致的，而且複雜計算過程也是需要儲存參入才能正常完成，例如計算過程裡的中間結果當超出CPU快取大小後我們就不得不將中間結果放到記憶體裡，當記憶體也不夠的時候我們就得放到硬碟裡，所以解決計算效率問題也受到儲存效能很大的影響。假如我們還是按照木桶理論來理解這個問題，我們發現不管是單純的儲存問題還是計算和儲存混合的問題，最終的短板都是其中效率最差的哪一方，而計算和儲存裡效率最差的一方就是網路了，不過有些馬虎的朋友可能說現在寬頻好快了，我在網上下載一部幾個G的電影也就幾十秒，甚至有時比我硬碟拷貝還快，像你說網路是最大的短板其實不準確的，這位朋友的想法的確有他的道理，但是不是每個人使用的網路都是你那麼快呢，而且現在移動網際網路已經普了及，移動網際網路速度比普通寬頻就差多了，而且你在移動裝置上使用網路流量越大，成本也就越高，如果你認為我說的這些問題都不算啥，網路還和地域的距離有關，你寬頻很快，你想訪問大洋彼岸美國的網站（這個網站在中國沒有任何快取處理），訪問速度肯定還是快不起來，而且網際網路的連通路徑本身也很複雜，例如你感覺自己訪問的是一個上海本土的網站，但是這個網站說不定好多重要伺服器是放置在北京，這麼複雜的網路環境，這麼多不可控的因素還會影響網路的傳輸效率，網路談何能說自己效能比硬碟強呢？

由此我們就可以發現谷歌和雅虎總結的web前端優化技巧以及我這裡談的網站靜態化技術大部分都是圍繞如何解決網路傳輸效率來進行了，因為它是整個木桶最大的短板，我們只有首先解決了這個短板，那麼再去解決其他因素的效率問題，才能發揮其作用。這裡的這個解釋也可以解答前不久一個網友問我，為什麼我講網站優化很少講解如何編寫高效的程式碼，而都是從一些和程式碼無關的角度來闡述的了，其實你想通過程式碼優化提升網站效能，你首先要解決好對網站效率影響更大更關鍵的要素例如網路通訊問題，否則你程式碼優化的再好，對最終效果影響都是有限的。

看來本文今天寫不完了，關於儲存和web前端優化的內容我將在下一篇文章進一步討論。最後祝大家晚安，生活和工作愉快。

相關文章