『大型網站技術架構』(三):高可用架構

NO IMAGE

『大型網站技術架構』(三):高可用架構

一、可用性度量與考核

度量

衡量方式:多少個9。

網站不可用時間(故障時間) = 故障修復時間點 – 故障發現(報告)時間點

網站年度可用性指標 = (1-網站不可用時間/年度總時間) * 100%

  • 2個9:基本可用,年度不可用時間小於88小時
  • 3個9:較高可用,年度不可用時間小於9小時
  • 4個9:具有自動恢復能力的高可用,年度不可用時間小於53分鐘
  • 5個9:極高可用,年度不可用時間小於5分鐘

考核

故障分:對網站故障進行分類加權計算故障責任。故障分 = 故障時間(分鐘) * 故障權重。

  • 事故級故障(100): 嚴重故障,網站整體不可用
  • A類故障(20): 網站訪問不順暢或核心功能不可用
  • B類故障(5): 非核心功能不可用,或核心功能少數使用者不可用
  • C類故障(1): 以上故障以外的其他故障

二、高可用網站架構

高可用架構設計不僅要考慮軟硬體故障,還要考慮網站升級釋出引起的不可用。

主要手段: 資料和服務的冗餘備份和失效轉移。

典型分層模型:

  • 應用層: 負責具體業務邏輯處理。思路:負載均衡裝置
  • 服務層: 負責提供可複用的服務。思路:分散式服務呼叫框架,客戶端軟體負載均衡
  • 資料層: 負責資料的儲存與訪問。思路:資料冗餘

三、高可用應用

主要特點:無狀態

無狀態應用是指應用伺服器不儲存業務的上下文資訊,僅根據每次請求提交的資料進行相應業務邏輯處理,多個服務例項完全對等。

1. 通過負載均衡進行無狀態服務的失效轉移

  • 應用訪問量小也使用負載均衡技術構建一個小型叢集保證高可用
  • 平滑升級

2. 應用伺服器叢集的Session管理

  • Session複製:Session在叢集中同步,大叢集不適用。
  • Session繫結:Session Sticky,會話黏滯。Hash(Source IP)、Hash(Cookie),無法實現高可用。
  • 利用Cookie記錄Session:伺服器端不記錄Session,每次從Cookie中解,伺服器可線性伸縮。缺點:大小受限、增大傳輸資料量、使用者關閉Cookie時不可用。
  • Session伺服器:獨立部署Session伺服器叢集,通過 分散式快取 資料庫 實現。可用性高、伸縮性好、效能不錯。

四、高可用服務

主要特點: 無狀態

  • 分級管理:核心業務隔離部署、用更好更穩定的硬體。
  • 超時設定
  • 非同步呼叫
  • 服務降級:拒絕服務(拒絕低優先順序任務、隨機拒絕)、關閉功能。
  • 冪等性設計:允許重複呼叫。

五、高可用資料

主要手段:資料備份和失效轉移機制

含義:

  • 資料永續性
  • 資料可訪問性
  • 資料一致性:

    • 1) 資料強一致:最強,各副本資料在物理儲存中一致;
    • 2) 資料使用者一致: 較強,在物理儲存中可能不一致,但是通過糾錯和校驗機制,可以返回一個一致且正確地的資料給使用者;
    • 3) 資料最終一致,較弱,使用者得到的資料可能不一致,但是最終會達到一致。

CAP理論: 資料一致性(Consistency)、資料可用性(Availibility)、分割槽容忍性(Partition Tolerance)。大型網站中,通常會選擇強化分散式儲存系統的可用性(A)和伸縮性(P),在某種程度上放棄一致性(C)。

快取服務討論,兩種觀點:

  • 快取需要高可用:快取承擔了業務中絕大多數資料讀取訪問,快取服務失效會影響整個網站可用性。
  • 快取不需要高可用:快取服務不是資料儲存服務,快取失效引起伺服器負載太大的問題應用通過其他手段解決。比如擴大快取叢集規模,單臺快取伺服器失效帶來影響較小。

資料備份

  • 冷備份:定期將資料備份到某種儲存介質(磁帶、光碟……)並物理存檔保管。簡單、廉價、技術難度低,無法保證資料最終一致,可能丟資料,無法保證資料可用性。
  • 熱備份:

    • 非同步熱備:Master-Slave架構。寫Master,返回操作成功響應,再由Master同步到Slave,這個過程可能失敗。例子:MySQL半同步複製、讀寫分離等。
    • 同步熱備:儲存伺服器互相間對等。資料多副本寫入同步完成。

失效轉移

  • 失效確認:1. 心跳檢查。2. 應用程式訪問失敗報告。
  • 訪問轉移:資料讀寫重新路由
  • 資料恢復:恢復副本數量

六、高可用網站軟體質量保證

  • 網站釋出:平滑升級,從LB下線->更新程式->掛回LB
  • 自動化測試
  • 預釋出驗證:預釋出伺服器與線上機器的唯一不同就是沒有配置在負載均衡上,外部使用者無法訪問。避免驗證過程汙染生產環境資料。
  • 程式碼控制:1. 主幹開發、分支釋出。2. 分支開發、主幹釋出。
  • 自動化釋出:週四釋出,火車釋出模型(基於規則驅動的流程,一級級評審)
  • 灰度釋出:分批次升級,等一批穩定執行後再上下一批。

七、網站執行監控

準則:“不允許沒有監控的系統上線”

監控資料採集

  • 使用者行為日誌收集:伺服器端日誌、客戶端日誌
  • 伺服器效能監控
  • 執行資料包告:業務場景相關

監控管理

  • 系統報警
  • 失效轉移
  • 自動優雅降級

EOF