《大型網站架構演化發展歷程》筆記

一、初始階段的網站架構

大型網站從小型網站發展而來，網站架構也同樣，從小型網站架構逐漸演化而來。

小型網站最開始沒有太多人訪問，只須要一臺服務器就綽綽有餘，應用程序、數據庫、文件等全部的資源都在一臺服務器上。

 

二、應用服務與數據服務分離

 

隨着網站業務的發展，一臺服務器逐漸不能知足需求：愈來愈多的用戶訪問致使性能變差，愈來愈多的數據致使存儲空間不足。這時就須要將應用和數據分離。

應用和數據分離後使用三臺服務器：應用服務器，數據庫服務器和文件服務器

這三臺服務器對硬件的資源要求各不相同：

• 應用服務器須要處理大量業務，所以須要更快更強大的CPU

• 數據庫服務器須要快速磁盤檢索和數據緩存，所以須要更快的硬盤和更大的內存

• 文件服務器須要處理大量用戶上傳的文件，所以須要更大的硬盤

 

應用和數據分離後，不一樣特性的服務器承擔不一樣角色，網站併發處理能力和數據存儲空間獲得很大改善，支持網站進一步發展。

但隨着用戶逐漸增多，網站又一次面臨挑戰：數據庫壓力太大致使訪問延遲，進而影響整個系統性能，用戶體驗受影響。

這時須要對網站進一步優化。

 

網站訪問特色和現實世界的財富分配同樣，遵循二八定律：80%的業務訪問集中在20%的數據上。

即大部分的業務訪問集中在一小部分的的數據上。

 

三、使用緩存改善網站性能

網站使用的緩存可分爲兩種：

一、緩存在應用服務器上的本地緩存（訪問速度快一些，可是受應用服務器內存限制，可緩存的數量有限，並且會出現與應用程序爭用內存的狀況）

二、緩存在專門的分佈式緩存服務器上的遠程緩存（可使用集羣的方式，部署大內存的服務器做爲專門的緩存服務器，能夠在理論上作到不受內存容量限制的緩存服務）

 

使用緩存後，數據庫壓力獲得有效緩解，可是單一應用服務器能處理的請求鏈接有限， 在網站訪問高峯期，應用服務器成爲整個網站的瓶頸。

 

 

四、使用應用服務器集羣改善網站的併發處理能力

 

 使用集羣是網站解決高併發、海量數據問題的經常使用手段。單一臺服務器的處理能力、存儲空間不足時，不要企圖去換更強大的服務器，對大型網站而言，無論多麼強大的服務器，都知足不了網站持續增加的業務需求。

 在這種狀況下，更恰當的方法是增長一臺服務器分擔原有服務器的訪問及存儲壓力。

 對網站架構而言，只要能經過增長一臺服務器的方式改善負載壓力，就能夠用一樣的方式持續增長服務器不斷改善系統性能，從而實現系統的可伸縮性。

 應用服務器實現集羣是網站可伸縮集羣架構設計中較爲簡單成熟的一種。

 

　　經過負載均衡調度服務器，可未來自用戶瀏覽器的請求分發到應用服務器集羣中的任何一臺服務器上。

　　若是有更多的用戶，就在集羣中加入更多的應用服務器，使應用服務器的負載均衡能力再也不成爲整個網站的瓶頸

 

五、數據庫讀寫分離

　　網站使用緩存後，使絕大部分數據讀操做訪問均可以不經過數據庫就能完成，可是仍有一部分讀操做（緩存訪問未命中，緩存過時）和所有的寫操做須要訪問數據庫，當網站用戶達到必定規模後，數據庫由於負載壓力太高而成爲網站瓶頸。

 

　　目前大部分的主流數據庫都提供主從備份功能，經過配置兩臺數據庫主從關係，可將一臺數據庫服務器的數據同步到另外一臺服務器上。網站利用數據庫的這一功能，實現數據庫主從分離，從而改善數據庫負載壓力。

 

應用服務器在寫數據時，訪問主數據庫，主數據庫經過主從複製機制將數據更新到從數據庫，這樣當應用服務器讀取數據時，就能夠經過從數據庫獲取。

爲了便於應用服務器訪問讀寫分離後的數據庫，一般在應用服務器端使用專門的數據訪問模塊，使數據庫讀寫分離對應用透明。

 

隨着網站業務不斷髮展，用戶規模愈來愈大，因爲中國複雜的網絡環境，不一樣地區的用戶訪問網站時，速度差異也極大。

有研究代表，網絡訪問延遲和用戶的流失率正相關，網絡訪問越慢，用戶越容易失去耐心而離開。

爲了提供更好的用戶體驗，留住用戶，網站須要加速網站訪問速度。主要手段有CDN和反向代理。

 

六、使用反向代理和CDN加速網站響應

 

CDN和反向代理的基本原理都是緩存，區別在於CDN部署在網絡提供商的機房，使用戶在請求網站服務時，能夠從距離本身最近的網絡提供商機房獲取數據。

而反向代理則部署在網站的中心機房，當用戶請求到達中心機房後，首先訪問的服務器是反向代理服務器，若是反向代理服務器中緩存着用戶請求的資源，就將其直接返回給用戶。

使用CDN和反向代理的目的都是儘早返回數據給用戶，一方面加快用戶訪問速度，另外一方面也減輕後端服務器的負載壓力。

 

七、使用分佈式文件系統和分佈式數據庫

 

任何強大的單一服務器都知足不了大型網站持續增加的業務需求。數據庫通過讀寫分離後，從一臺拆分紅兩臺，可是隨着網站業務的發展依然不能知足需求，這時須要使用分佈式數據庫。文件系統也是同樣，須要使用分佈式文件系統。

 

分佈式數據庫是目前網站數據庫拆分的最後手段，只有在單表數據規模很是龐大的時候才使用。

不到不得已時，網站更經常使用的是數據庫拆分手段是業務分庫，將不一樣業務的數據部署在不一樣的物理服務器上。

 

八、使用NoSQL和搜索引擎

隨着網站業務愈來愈複雜，對數據存儲和檢索的需求也愈來愈複雜，網站須要採用一些非關係數據庫技術如NoSQL和非數據庫查詢技術如搜索引擎。

NoSQL和搜索引擎都是源自互聯網的技術手段，對可伸縮的分佈式特性具備更好的支持。應用服務器則經過統一數據訪問模塊訪問各類數據，減輕應用程序管理諸多數據源的麻煩。

 

九、業務拆分

大型網站爲了應對日益複雜的業務場景，經過使用分而治之的手段 將整個網站業務分紅不一樣的產品線，分歸不一樣的業務團隊負責。

 

具體到技術上，也會根據產品線劃分，將 一個網站拆分紅許多不一樣的應用，每一個應用獨立部署維護。 應用之間能夠經過超連接創建關係，也可經過消息隊列進行數據分發，固然最多的仍是經過訪問同一數據存儲系統來構成一個關聯的完整系統。

 

十、分佈式服務

隨着業務拆分愈來愈小，存儲系統愈來愈龐大，應用系統的總體複雜度呈指數級增加，部署維護愈來愈困難。

因爲全部應用要和全部數據庫系統鏈接，在數百萬服務器規模的網站中，這些鏈接的數目是服務器規模的平方，致使數據庫鏈接資源不足，拒絕服務。

 

既然每個業務系統都須要執行相同的業務操做，如用戶管理、商品管理等，那麼能夠將這些公共的業務提取出來，獨立部署。

由這些可複用的業務鏈接數據庫，提供共用業務服務，而應用服務只須要管理用戶界面，經過分佈式服務調用共用服務完成具體業務操做。

 

大型網站的架構演化到這裏，基本上大多數的技術問題都得以解決，諸如 跨數據中心的實時數據同步和具體網站業務相關的問題也均可以經過 組合改進現有的技術架構來解決。

目前許多大型網站都開始建設雲計算平臺，將計算做爲一種基礎資源出售，中小網站不須要關心技術架構問題，只需按需付費便可使網站隨着業務增加逐漸得到更好的存儲空間和計算資源。

 

 

11. 網站架構設計誤區

（1）一味追隨大公司(較成熟互聯網公司)的解決方案

因爲大公司巨大成功的光環效應，再加上從大公司挖來的技術高手(活寶)的影響，網站在討論決策時，最具說服力的一句話就是「淘寶就是這麼搞的」或者「騰訊就是這麼搞的」。

大公司的經驗和成功模式當然重要，值得學習借鑑，但若是所以而變得盲從，就失去了堅持自個人勇氣，在架構演化的路上早晚會迷路。

（2）爲了技術而技術

技術是爲業務而存在的，除此以外毫無心義。在技術選型和架構設計中，脫離業務發展的實際，一味追求時髦的新技術，極可能會將技術發展引入崎嶇小道，架構之路越走越難。

（3）企圖用技術解決全部問題（有時能夠從業務角度想辦法解決）

最典型的例子就是2012年初12306故障事件後，軟件開發技術界的反應。

各路專業和非專業人士紛紛幫12306技術架構出謀劃策，甚至有人提議幫12306寫一個開源的網站，解決大規模併發訪問的問題。

12306真正的問題其實不是他的技術架構，而是他的業務架構。12306根本就不該該在幾億人一票難求時依窗口售票模式在網上售票（零點開始出售若干天后的車票）。12306須要重構的不只是它的技術架構，更重要的是它的業務架構：調整業務需求，換一種方式賣票，而不要去搞促銷秒殺這種噱頭式的遊戲。

後來證實12306確實是朝這個方向發展的：在售票方式上引入了排隊機制、整點售票調整爲分時段售票。其實若是能控制住併發訪問的量，不少棘手的問題難關均可以順利攻破。

（4）避免過分設計

在中小型公司，尤爲是創業公司都須要低成本試錯；若設計一款產品、架構過於考慮三、5年後的擴展是沒有必要的；當今技術發展這麼快，幾乎不到2年就有一個迭代，到時你的設計極可能過期，或因業務變動致使架構變動或產品流產。通常考慮到半年至一年就能夠了。