大型網站軟件系統的特點
- 高併發，大流量
- 高可用
- 海量數據
- 用戶分佈廣泛，網絡情況複雜
- 安全環境惡劣
- 需求快速變更，發佈頻繁
- 漸進式發展
大型網站架構演化發展歷程
初始階段的網站架構
Linux+PHP+Apache+MySQL
應用服務和數據服務分離
演化原因
一臺服務器逐漸不能滿足需求，越來越多的用戶訪問導致性能越來越差，越來越多的數據導致存儲空間不足
演化後
應用和數據分離後整個網站使用三臺服務器
- 應用服務器：需要更快更強大的CPU處理大量的業務邏輯
- 文件服務器：需要更大的硬盤存儲大量用戶上傳的文件
- 數據庫服務器：需要更快的硬盤和更大的內存進行快速磁盤檢索和數據緩存
使用緩存改善網絡性能
演化原因
大部分的業務訪問集中在一小部分數據上，把這一小部分數據緩存在內存可以減少數據庫的訪問壓力，提高整個網站的數據訪問速度
演化後
網站使用的緩存可以分爲兩種
- 本地緩存：緩存在應用服務器上，優點是訪問速度更快一些，但是受應用服務器內存的限制，其緩存的數據量有限，而且會出現和應用程序爭用內存的情況
- 遠程緩存：緩存在專門的分佈式緩存服務器上，優點是可以使用集羣的方式，部署大內存的服務器作爲專門的緩存服務器，可以在理論上做到不受內存容量限制的緩存服務
使用應用服務器集羣改善網站的併發處理能力
演化原因
當一臺服務器的處理能力、存儲空間不足時，應該增加一臺服務器分擔原有服務器的訪問及存儲壓力
演化後
通過負載均衡調度服務器，可將來自用戶瀏覽器的訪問請求分發到應用服務器集羣中的任何一臺服務器上，如果有更多的用戶，就在集羣中加入更多的應用服務器，使應用服務器的負載壓力不再成爲整個網站的瓶頸
數據庫讀寫分離
演化原因
在網站的用戶達到一定規模後，數據庫因爲負載壓力過高而成爲網站的瓶頸
演化後
利用數據庫的主從熱備功能，通過配置兩臺數據庫主從關係，可以將一臺數據庫服務器的數據更新同步到另一臺服務器上，實現數據庫讀寫分離，從而改善數據庫負載壓力
應用服務器在寫數據的時候，訪問主數據庫，主數據庫通過主從複製機制將數據更新同步到從數據庫，這樣當應用服務器讀數據的時候，就可以通過從數據庫獲得數據
應用服務器端應使用專門的數據訪問模塊，使數據庫讀寫分離對應用透明
使用反向代理和CDN加速網站響應
演化原因
不同地區的用戶訪問網站時，速度差別極大，爲了提供更好的用戶體驗，需要加速網站訪問速度
演化後
使用CDN和反向代理儘早返回數據給用戶，一方面加快用戶訪問速度，另一方面也減輕後端服務器的負載壓力
- CDN：CDN部署在網絡提供商的機房，使用戶在請求網站服務時，可以從距離自己最近的網絡提供商機房獲取數據
- 反向代理：部署在網站的中心機房，當用戶請求到達中心機房後，首先訪問的服務器是反向代理服務器，如果反向代理服務器中緩存着用戶請求的資源，就將其直接返回給用戶
使用分佈式文件系統和分佈式數據庫系統
演化原因
單一服務器滿足不了大型網站持續增長的業務需求，需要使用分佈式數據庫和分佈式文件系統
演化後
將數據庫拆分，把不同業務的數據庫部署在不同的物理服務器上
使用NoSQL和搜索引擎
演化原因
隨着網站業務越來越複雜，對數據存儲和檢索的需求也越來越複雜
演化後
採用一些非關係數據庫技術如NoSQL和非數據庫查詢技術如搜索引擎
業務拆分
演化原因
大型網站爲了應對日益複雜的業務場景，通過使用分而治之的手段將整個網站業務分成不同的產品線，如大型購物交易網站就會將首頁、商鋪、訂單、買家、賣家等拆分成不同的產品線，分歸不同的業務團隊負責
演化後
根據產品線劃分，將一個網站拆分成許多不同的應用，每個應用獨立部署維護，應用之間可以通過一個超鏈接建立關係，也可以通過消息隊列進行數據分發
分佈式服務
演化原因
隨着業務拆分越來越小，存儲系統越來越龐大，應用系統的整體複雜度呈指數級增加，部署維護越來越困難
演化後
既然每一個應用系統都需要執行許多相同的業務操作，比如用戶管理、商品管理等，那麼可以將這些共用的業務提取出來，獨立部署。由這些可複用的業務連接數據庫，提供共用業務服務，而應用系統只需要管理用戶界面，通過分佈式服務調用共用業務服務完成具體業務操作
