網站架構結構的變遷史

    前些天看到一篇不錯的文章[1]，講的是網站架構的發展歷史，這種綜述的文章每每很可貴，這裏進行一個簡化訴述和我我的的解讀，詳細的信息能夠參看Ref的鏈接。首先，我先給一個通俗的理解，網站架構發展的驅動力是用戶數和數據量的膨脹，壓力瓶頸在websever鏈接和database之間來回切換，解決問題的三板斧：加緩存（精益求精地作緩存。。。）、加機器（多搞搞分佈式，一臺不行多臺）和功能分離（讀寫分離、業務分離、動靜分離等等）。下面是所讀那篇文章的主要思路。

    網站架構的演變主要經歷了以下幾個階段：

    一、物理分離webserver和數據庫

 

    比較直觀，再也不贅述。

    二、增長頁面緩存

    目的是減少數據庫鏈接的資源競爭以及對數據庫讀訪問的壓力，此時會採用squid等機制將更新週期相對較長的靜態頁面作緩存，從而減小對webserver和databse的壓力。

    三、增長頁面片斷緩存

    採用前端頁面緩存相似的技術，不過這裏更進一步將動態頁面中相對靜態的部分也作了緩存，使用ESI之類的頁面片斷緩存策略。進一步緩解database的讀壓力。

    四、數據緩存

    一樣的思路，不過這裏是將數據庫中常常訪問的、重複獲取的數據放到緩存裏，也就是數據緩存，進一步緩解數據庫壓力。因而可知，在網站發展的開始階段，你們提升網站性能的主要途徑就是加緩存，另外，在這些階段，database的IO始終是限制併發和性能瓶頸。

    五、增長webserver

    隨着系統訪問量的進一步增長，websever上的壓力徒增，在高峯時沒法保證穩定鏈接，這是爲了解決可用性問題，避免單點，引入了多機。sever集羣的介入帶來一些新問題，也誕生了一些新技術：負載均衡問題（Apache自帶的負載均衡或者lvs），可靠性問題（主備技術，heart-beat等），狀態信息同步問題（用戶session同步和共享技術、狀態信息廣播），緩存信息的同步（分佈式緩存，緩存同步等），多機系統文件功能的保持（共享文件、共享存儲等等） 

    六、分庫

    此時應對的數據量的膨脹，數據庫須要進行分庫和調優，database也分攤到多機上面。

 

    七、分表、DAL和分佈式緩存

    數據量繼續大幅增加，因而出現了通用的框架來實現分庫分表的數據訪問（例如ebay架構中對一個的DAL），而且因爲數據量過大，不太可能再緩存在本地，因而採用了分佈式緩存。動態hash算法、一致性hash以及DAL技術獲得了普遍的應用。

    八、增長更多的server

    當上面的技術緩解了database的壓力時，webserver又成爲瓶頸，尤爲是面臨愈來愈多的鏈接請求，太高的請求數會被apache服務器阻塞排隊，從而響應速度變慢。此時就須要進一步的增長websever的數量，這帶來了新的挑戰，例如以前的負載均衡方法hold不住了（硬件負載，如F五、Netsclar、Athelon之類的開始成爲選擇，但價格昂貴，或者採用邏輯分類的方法，將請求分散到不一樣的軟負載集羣）、文件共享瓶頸（分佈式文件系統迎來了大規模應用）

 

    九、數據讀寫分離和廉價存儲方案

    websever鏈接的問題獲得緩和了，數據庫又出問題了，此時分析數據庫的壓力狀況，發現其讀寫比很高，所以想到了讀寫分離方案，另外編寫一些更爲廉價的存儲方案，例如BigTable。

     十、大型分佈式應用時代和廉價服務器羣的時代

    這時作的主要事情是將系統進行業務職責才分，造成大型的分佈式應用，這個步驟至關艱難和耗時，主要挑戰有（下面三點摘的原話）：

    1）、拆成分佈式後須要提供一個高性能、穩定的通訊框架，而且須要支持多種不一樣的通訊和遠程調用方式；

      2）、將一個龐大的應用拆分須要耗費很長的時間，須要進行業務的整理和系統依賴關係的控制等；

      3）、如何運維（依賴管理、運行情況管理、錯誤追蹤、調優、監控和報警等）好這個龐大的分佈式應用。

 

Ref：

[1] http://www.blogjava.net/BlueDavy/archive/2008/09/03/226749.html