【讀書筆記】大型網站技術架構

關於大型網站

大型網站是相當於企業級應用來說的，特點有

• 高併發，大流量
• 高可用
• 海量數據
• 用戶分佈廣泛，網絡情況複雜
• 安全環境惡劣
• 需求快速變更，發佈頻繁
• 漸進式發展
  
  

核心要素

架構是“最高層次的規劃，難以改變的規定”。主要關注五個要素：

• 性能
• 可用性(Availability)
• 伸縮性(Scalability)
• 擴展性(Extensibility)
• 安全性
  
  

大型網站追求的性能指標

可用性 availability

在服務器宕機時，服務和應用是否依舊可用。網站使用的商用服務器硬件的設計目標本身並不保證高可用性。必須在系統設計層面予以考慮。

伸縮性 scalability

定義：往集羣中加入服務器的手段，緩解併發訪問壓力的難易程度

擴展性 extensibility

滿足功能需求的難易程度。一般使用事件驅動的架構或分佈式服務實現。

安全性 security

大型網站的演化發展歷程

任何大型網站都是從小網站進化出來的：

階段 1

應用程序、文件、數據庫都在同一臺服務器上

階段 2

應用和文件、數據分離。使用三臺專職服務器：

• 文件服務器：執行大量業務邏輯，需要CPU優化的硬件

• 數據庫服務器：磁盤讀寫和緩存讀寫，需要快速的硬盤和內存

• 文件服務器：大硬盤
  

階段 3

數據庫成爲瓶頸。加入對最hot的20%的數據緩存：

• 應用服務器上的本地緩存（大小受限）

• 專門的分佈式緩存服務器集羣上的遠程緩存
  

階段 4

應用服務器成爲瓶頸。將應用服務器擴展爲集羣。
此時的問題：

• Session管理：4種方式
  • 複製：服務器之間同步所有session。資源利用率太低。
  • 綁定：利用load balancer的源地址Hash，確保同一IP的請求被分發到同一服務器。可用性目標很難達到，一旦某臺服務器宕機，它維護的所有session就會丟失
  • Cookie記錄：不少網站採用。但受限cookie的大小，並且如果用戶關閉瀏覽器的cookie功能，session就將無法工作。
  • 專用session服務器：將應用服務器分爲有狀態和無狀態部分。有狀態的部分用專門的session服務器來維護。一般來說redis是一個很好的選擇。
    

階段 5

對數據看的寫操作和未命中緩存的讀操作，在用戶達到一定規模後使得數據庫再次成爲瓶頸。這時啓用主從備份功能：

1.寫數據直接寫到主數據庫
2.主數據庫通過主從備份機制把寫數據更新到從數據庫
3.讀操作讀取從數據庫

階段 6

隨着網站用戶羣擴散，特定地區的用戶訪問網站會遇到性能問題。此時開始對前端性能進行優化，啓用CDN和反向代理

階段 7

單機數據庫和文件系統不能滿足性能和高可用性需求，啓用分佈式數據庫和分佈式文件服務器：

• 分佈式存儲系統的三類故障：

  • 瞬時鼓掌：網絡中斷、服務器GC等，可重試後自行恢復
  • 臨時故障：交換機宕機、網卡鬆動、內存損壞、CPU過熱等，需要人工干預，持續幾十分鐘到幾個小時
  • 永久故障：硬盤損壞

• 使用備份和冗餘

• 服務器宕機下的失效轉移：確認失效 -> 訪問轉移 -> 數據恢復

• CAP原理：可用性、某種程度上的數據一致性、伸縮性之間的權衡

  • 強一致：各個副本數據總是一致的，對更新和讀操作的響應也是一致的
  • 用戶一致：各個副本的數據可能是不一致的，但是用戶一旦訪問數據，就會通過糾錯和校驗機制確保用戶得到的數據是一致正確的
  • 最終一致：各個副本的數據可能是不一致的，用戶得到的數據也可能是不一致的（同一個用戶連續訪問，或者多個用戶同時訪問，結果不同）。但是系統經過一段時間的自我恢復和修正，數據最終達到一致。

階段 8

網站業務越來越複雜，對搜索和存儲的需求也越來越複雜。此時引入NoSQL和非數據庫查詢技術，如搜索引擎。

階段 9

業務場景複雜度與日俱增，此時開始採取分而治之的手段把網站業務拆分成不同的產品線。技術上網站被拆分成多個獨立維護的應用。應用之間通過如消息隊列等手段通信。

階段 10

隨着業務拆分越來越小，應用系統的整體複雜程度急劇上升，部署和維護越來越困難。此時採取分佈式服務架構，把公共的可複用業務提取出來獨立部署