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

　　網站靜態化處理這個系列立刻就要結束了，今天我要講講本系列最後一個重要的主題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服務端併發效率的異步編程技術》

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

對於一個網絡請求的處理，是由兩個不一樣類型的操做共同完成，這兩個操做是CPU的計算操做和IO操做，若是咱們以處理效率角度來評判這兩個操做，CPU操做效率是光速的，而IO操做就不盡然了，計算機裏的IO操做就是對存儲數據介質的操做，計算機裏有以下幾個介質能夠存儲數據，它們分別是：CPU的一級緩存、二級緩存、內存、硬盤和網絡，一級緩存存儲和讀取數據的能力接近光速，它比二級緩存快個5倍到6倍，可是無論是一級緩存仍是二級緩存，它們存儲數據量太少了，作不了什麼大事情，下面就是內存了，以一級緩存的效率作參照，一級緩存比內存速度快100多倍，到了硬盤存儲和讀取數據效率就更慢了，一級緩存比硬盤要快1000多萬倍，到了網絡就慢的更不像話了，一級緩存比網絡要快一億多倍，可見一個請求處理的效率瓶頸都是由IO引發的。

 

　　因而可知網站的速度和效率問題彷佛都是由存儲即IO形成的。不過咱們不能由於感受發現問題根源在於存儲，而就忽視對CPU的思考，因此我先講講CPU和網站性能的關係吧。CPU是計算機用於作計算的設備，如今的電腦能看電影，能聽歌，能夠和朋友聊天，還能用於工做，這些使人稱奇的功能其實到了CPU這裏也就是經過加減乘除這類基本的數學運算完成的，說到這個真是難以讓人想象，讀書時候學數學老是以爲那麼枯燥乏味，沒想到如此強大的人類神器竟然就是經過數學運算得來的，難怪有國外科學家說宇宙都是經過數學運算得來的，這仍是有道理的。不過網站背後的數學運算卻有着本身的特色，雖然CPU計算能力很強，可是在實際場景下不少業務的計算其實很消耗時間的，若是網站某些請求響應背後的運算是須要消耗太多的時間，那麼這個時候CPU也就會成爲網站性能的瓶頸所在，網站應用有個重要的特色，這個特色有個專有名詞描述那就是網站的實時性，根據網站實時性的特色，那麼就要求咱們網站每一個請求所包含的計算都要簡單和快捷，簡單快捷的計算也就讓每一個請求背後所包含的業務性運算要更加簡單，這也就是爲何不少人會說互聯網的網站和企業的web應用相比，互聯網的業務邏輯比較簡單的道理，可是隨着網站的規模擴大，業務模式愈來愈豐富，這個時候網站在某些業務環節不可避免的變得複雜，假如這些複雜的業務又須要實時的反應給用戶，那麼CPU不能快速完成業務計算就是網站的效率問題的根源了，例如我在存儲系列裏說到的海量數據的計算操做，就是這樣的場景之一，那麼這個時候咱們該如何來作了？

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

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

　　那麼咱們就得進一步思考計算自己到底哪裏出現了影響速度的問題，計算自己包含三個方面，首先是用於計算的計算資源，再就是作運算的工具即CPU，最後是計算的最終結果，若是業務計算慢的緣由是由於數據量太大了，CPU很難快速完成，那麼這個時候咱們有一些手段能夠解決這個問題，咱們能夠把海量數據作一個分類，例如存儲系列裏說的歷史交易數據和當日交易數據的分類，當日數據由於數據量有限在必定條件下能夠快速計算出來，面對歷史數據，若是咱們的計算結果最終是很簡單的並且在必定時間範圍裏是不會變化的，那麼咱們可不能夠這麼考慮，讓這些結果提早計算出來，而後將結果存儲在效率更高的存儲設備裏例如內存，當用戶請求操做這個業務計算時候咱們只須要直接讀取緩存裏的計算結果就好了，這樣就避免了計算，同時計算結果存儲在效率高效的緩存裏，用戶得到響應的速度也會快多了，這個其實就是網站靜態化技術裏ESI技術背後的深意了。

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

　　由此咱們就能夠發現谷歌和雅虎總結的web前端優化技巧以及我這裏談的網站靜態化技術大部分都是圍繞如何解決網絡傳輸效率來進行了，由於它是整個木桶最大的短板，咱們只有首先解決了這個短板，那麼再去解決其餘因素的效率問題，才能發揮其做用。這裏的這個解釋也能夠解答前不久一個網友問我，爲何我講網站優化不多講解如何編寫高效的代碼，而都是從一些和代碼無關的角度來闡述的了，其實你想經過代碼優化提高網站性能，你首先要解決好對網站效率影響更大更關鍵的要素例如網絡通信問題，不然你代碼優化的再好，對最終效果影響都是有限的。

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