一 大型網站架構演化

1.1 大型網站軟件系統的特色

　　大型網站應用系統有如下特色

　　　　高併發，大流量：須要面對高併發用戶，大流量訪問。谷歌日均 PV數 35億，日均 IP訪問數 3億；騰訊 QQ的最大在線用戶數1.4億（2011年數據）。

　　　　高可用：系統 7*24小時不間斷服務。

　　　　海量數據：須要存儲、管理海量數據，須要使用大量服務器。Facebook 每週上傳的照片數量接近10億，百度收錄的網頁數量有數百億，谷歌有近百萬臺服務器爲全球用戶提供服務。

　　　　用戶分佈普遍，網絡狀況複雜：大型互聯網都是爲全球用戶提供服務的，用戶分佈範圍廣，各地網絡狀況差異大。在國內，各個運營商網絡互通難。中美光纜屢次故障，對國外用戶依賴較大的網站須要創建海外數據中心。

　　　　安全環境惡劣：互聯網站容易受到攻擊，大型網站基本天天都會有黑客攻擊。

　　　　需求快速變動，發佈頻繁

　　　　漸進式發展：全部的大型互聯網站都是從一個小網站開始，漸進的發展起來的。

 

1.2 大型網站架構演化發展歷程

1.2.1 初始階段的網站架構

　　　　大型網站都是從小型網站發展來的，網站架構也同樣，從小型網站架構逐步演化而來。小型網站一開始沒有太多人訪問，只須要一臺服務器綽綽有餘，網站架構以下圖

　　　　

應用程序、數據庫、文件等全部資源都在一臺服務器上。一般服務器操做系統使用 Linux，應用程序使用 PHP開發，而後部署在 Apache上，數據庫使用 MySQL，聚集各類免費開源軟件及一臺廉價服務器就能夠開始網站的發展。

　　　

1.2.2 應用服務和數據服務分離

　　　　　應用和數據分離後整個網站使用三臺服務器：應用服務器、文件服務器和數據庫服務器

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

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

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

　　　　　　　文件服務器須要存儲大量用戶上傳的文件，所以須要更大的硬盤。

　　隨着用戶逐漸增多，網站有一次面臨挑戰：數據庫壓力太大致使訪問延遲，進而影響整個網站的性能，用戶體驗收到影響，須要進一步優化網站架構。

 

1.2.3 使用緩存改善網站性能

　　互聯網的業務訪問集中在一小部分的數據上，，把這一小部分數據緩存在內存中，就能夠減小數據庫的訪問壓力，提升整個網站的數據訪問速度，改善數據庫寫入性能。

　　網站使用的緩存能夠分爲兩種：緩存在應用服務器上的本地緩存和緩存在專門的分佈式緩存服務器上的遠程緩存。

　　本地緩存的訪問速度更快一些，可是受應用服務器內存限制，其緩存數據量有限，並且會出現和應用程序爭用內存的狀況。

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

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

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

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

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

　　

　　

 　　經過負載均衡調度服務器，可未來自用戶瀏覽器的訪問請求分發到應用服務器集羣中的任何一臺服務器上，若是有更多的用戶，就在集羣中加入更多的應用服務器，使應用服務器的負載壓力再也不成爲整個網站的瓶頸。

　　1.2.5 數據庫讀寫分離

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

　　　　目前大部分的主流數據庫都提供主從熱備功能，經過配置兩臺數據庫主從關係，能夠將一臺數據庫服務器的數據更新同步到另外一臺服務器上。

　　　　網站利用數據庫的這一功能實現數據庫讀寫分離，從而改善數據庫負載壓力。

 

　　　　應用服務器在寫數據的時候，訪問主數據庫，主數據庫經過主從複製機制將數據更新同步到從數據庫，這樣當應用服務器讀數據的時候，就能夠經過從數據庫得到數據。爲了便於應用程序訪問讀寫分離後數據庫，一般在應用服務器端使用專門的數據訪問模塊，使數據庫讀寫分離對應用透明。

　　

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

　　　　網站訪問延遲和用戶流失率正相關，網站訪問越慢，用戶越容易失去耐心離開，爲了提供更好的用戶體驗，留住用戶，網站須要加速網站訪問速度。

 　　　　主要手段有使用 CDN和反向代理。

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

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

　　　　   

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

 

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

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

　　　　分佈式數據庫是網站數據庫拆分的最後手段，只有在單表數據規模很是龐大的時候才使用。不到不得已時，網站更經常使用的數據庫拆分手段是業務分庫，將不一樣業務的數據庫部署在不一樣的物理服務器上。

　　

1.2.8 使用 NoSQL 和搜索引擎

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

　　

　　NoSQL 和搜索引擎都是源自互聯網的技術手段，對可伸縮的分佈式特性具備更好的支持。

　　應用服務器則經過一個統一數據訪問模塊訪問各類數據，減輕應用程序管理諸多數據源的麻煩。

 

1.2.9 業務拆分

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

　　如大型購物交易網站就會將首頁、商鋪、訂單、買家、賣家等拆分紅不一樣的產品線，分歸不一樣的業務團隊負責。

 　　具體到技術上，也會根據產品線劃分，將一個網站拆分紅許多不一樣的應用，每一個應用獨立部署維護。應用之間能夠經過一個超連接創建關係（在首頁上的導航連接每一個都指向不一樣的應用地址），

　　也能夠經過消息隊列進行數據分發，固然最多的仍是經過訪問同一個數據存儲系統來構成一個關聯的完整系統。

　　

1.2.10 分佈式服務

　　隨着業務拆分愈來愈小，存儲系統愈來愈龐大，應用系統的總體複雜度呈指數級增長，部署維護愈來愈困難。因爲全部應用要和全部數據庫系統鏈接，在數萬臺服務器規模的網站中，這些鏈接的數目是服務器規模的平方，致使存數據庫鏈接資源不足，拒絕服務。

　　既然每個應用系統都須要執行許多相同的業務操做，好比用戶管理、商品管理等，那麼能夠將這些共用的業務提取出來，獨立部署。由這些可複用的業務鏈接數據庫，提供共用業務服務，而應用系統只須要管理用戶界面，經過分佈式服務調用共用業務服務完成具體業務操做。

　　

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