大型網(wǎng)站技術架構_5. 網(wǎng)站的高可用架構

5. 網(wǎng)站的高可用架構

網(wǎng)站的可用性(Availablilty)描述網(wǎng)站可有效訪問的特性。
網(wǎng)站的有用性(Usability),通常也被譯作可用性,但是后者強調(diào)的是網(wǎng)站的有用性,即對最終用戶的使用價值。

5.1 網(wǎng)站可用性度量

網(wǎng)站不可用時間(故障時間)= 故障修復時間點 - 故障發(fā)現(xiàn)(報告)時間點。
網(wǎng)站年度可用性指標 = (1 - 網(wǎng)站不可用時間/年度總時間)* 100%。

5.2 網(wǎng)站可用性考核

故障分是指對網(wǎng)站故障進行分類加權計算故障責任的方法。

故障分的計算公式:
故障分 = 故障時間(分鐘)* 故障權重

網(wǎng)站故障分類 描述 權重
事故級故障 嚴重故障,網(wǎng)站整體不可用 100
A類故障 網(wǎng)站訪問不順暢或核心功能不可用 20
B類故障 非核心功能不可用,或核心功能少數(shù)用戶不可用 5
C類故障 以上故障以外的其他故障 1

5.3 高可用的網(wǎng)站架構

  • 硬件故障是常態(tài)。
  • 網(wǎng)站可用性架構設計不但要考慮實際的硬件故障引起的宕機,還要考慮網(wǎng)站升級發(fā)布引起的宕機。
  • 網(wǎng)站高可用架構設計的主要目的:保證服務器硬件故障時服務依然可用、數(shù)據(jù)依然保存并能夠被訪問。
  • 實現(xiàn)高可用架構的主要手段:數(shù)據(jù)和服務的冗余備份及失效轉移。
網(wǎng)站架構基本分層模型

在復雜的大型網(wǎng)站架構中,劃分的粒度會更小、更詳細,結構更復雜,服務器規(guī)模更龐大,但通常還是能夠把這些服務器劃分到以上三層中。

應用層服務器:負載均衡、心跳檢測。
服務層服務器:集群部署、分布式服務調(diào)用框架、軟件負載均衡、心跳檢測。
數(shù)據(jù)層服務器:數(shù)據(jù)同步復制、數(shù)據(jù)冗余備份。

5.4 高可用的應用

應用層(業(yè)務邏輯層)主要處理網(wǎng)站應用的業(yè)務邏輯。
應用層的特點:應用的無狀態(tài)性。

無狀態(tài)應用:
應用服務器不保存業(yè)務的上下文信息,而僅根據(jù)每次請求提交的數(shù)據(jù)進行相應的業(yè)務邏輯處理,多個服務器實例之間完全對等,請求提交到任意服務器,處理結果完全一樣。

通過負載均衡進行無狀態(tài)服務的失效轉移

負載均衡顧名思義,主要使用在業(yè)務量和數(shù)據(jù)量較高的情況下,當單臺服務器不足以承擔所有的負載壓力時,通過負載均衡手段,將流量和數(shù)據(jù)分攤到一個集群組成的多臺服務器上,以提高整體的負載處理能力。
目前,不管是開源免費的負載均衡軟件還是昂貴的負載均衡硬件,都提供失效轉移功能。在網(wǎng)站應用中,當集群中的服務是無狀態(tài)對等時,負載均衡可以起到事實上高可用的作用。

負載均衡

負載均衡開源解決方案

1. LVS

LVS,工作在 4 層,Linux 實現(xiàn)的高性能高并發(fā)、可伸縮性、可靠的的負載均衡器,支持多種轉發(fā)方式 (NAT、DR、IP Tunneling),其中 DR 模式支持通過廣域網(wǎng)進行負載均衡。支持雙機熱備 (Keepalived 或者 Heartbeat)。對網(wǎng)絡環(huán)境的依賴性比較高。

2. Nginx

Nginx 工作在 7 層,事件驅(qū)動的、異步非阻塞的架構、支持多進程的高并發(fā)的負載均衡器 / 反向代理軟件??梢葬槍τ蛎⒛夸浗Y構、正則規(guī)則針對 http 做一些分流。通過端口檢測到服務器內(nèi)部的故障,比如根據(jù)服務器處理網(wǎng)頁返回的狀態(tài)碼、超時等等,并且會把返回錯誤的請求重新提交到另一個節(jié)點,不過其中缺點就是不支持 url 來檢測。對于 session sticky,可以基于 ip hash 的算法來實現(xiàn),通過基于 cookie 的擴展 nginx-sticky-module 支持 session sticky。

3. HAProxy

HAProxy 支持 4 層和 7 層做負載均衡,支持 session 的會話保持,cookie 的引導;支持后端 url 方式的檢測;負載均衡的算法比較豐富,有 RR、權重等。

應用服務器集群的 Session 管理

會話(Session):Web 應用中多次請求修改使用的上下文對象。

單機環(huán)境下的 Session 管理:由部署在 Web 容器(如 JBoss)管理。

集群環(huán)境下的 Session 管理:

  1. Session 復制。
  2. Session 綁定:利用負載均衡的源地址 Hash 算法實現(xiàn)。
  3. 利用 Cookie 記錄 Session。
  4. Session 服務器:利用獨立部署的 Session 服務器(集群)統(tǒng)一管理 Session。

Session 服務器將應用服務器的狀態(tài)分離:

  • 無狀態(tài)的應用服務器。
  • 有狀態(tài)的 Session 服務器:分布式緩存、數(shù)據(jù)庫。

5.5 高可用的服務

可復用的服務模塊為業(yè)務產(chǎn)品提供基礎公共服務。
高可用服務策略:

  1. 分級管理。(將服務器進行分級管理:核心服務器、非核心服務器)
  2. 超時設置。(在應用服務中設置服務調(diào)用的超時時間)
  3. 異步調(diào)用。(消息隊列)
  4. 服務降級。(拒絕服務、關閉功能)
  5. 冪等性設計:必須在服務層保證服務重復調(diào)用和調(diào)用一次產(chǎn)生的結果相同。

5.6 高可用的數(shù)據(jù)

保證數(shù)據(jù)存儲高可用的手段:

  1. 數(shù)據(jù)備份;
  2. 失效轉移;

數(shù)據(jù)備份是保證數(shù)據(jù)有多個副本,任意副本的失效都不會導致數(shù)據(jù)的永久丟失,從而實現(xiàn)數(shù)據(jù)完全的持久化。
失效轉移保證當一個數(shù)據(jù)副本不可訪問時,可以快速切換訪問數(shù)據(jù)的其他副本,保證系統(tǒng)可用。

CAP 原理

參考:數(shù)據(jù)庫原理 - 數(shù)據(jù) CAP 原理

為了保證數(shù)據(jù)的高可用,網(wǎng)站通常會犧牲另一個很重要的指標:數(shù)據(jù)一致性。

高可用數(shù)據(jù)的含義:數(shù)據(jù)持久性、數(shù)據(jù)可訪問性、數(shù)據(jù)一致性。

CAP 原理認為,一個提供數(shù)據(jù)服務的存儲系統(tǒng)無法同時滿足數(shù)據(jù)一致性( Consistency)、數(shù)據(jù)可用性(Availibility)、分區(qū)耐受性(Partition Tolerance,系統(tǒng)具有跨網(wǎng)絡分區(qū)的伸縮性)這三個條件。

image

在大型網(wǎng)站中,通常會選擇強化分布式存儲系統(tǒng)的可用性和伸縮性,而在某種程度上放棄一致性。

數(shù)據(jù)一致性:

  • 數(shù)據(jù)強一致。
  • 數(shù)據(jù)用戶一致。
  • 數(shù)據(jù)最終一致。

數(shù)據(jù)備份

image

異步方式:多份數(shù)據(jù)副本的寫入操作異步完成,應用程序收到數(shù)據(jù)服務系統(tǒng)的寫操作成功響應時,只寫成功一份,存儲系統(tǒng)將會異步地寫其他副本。
同步方式:多份數(shù)據(jù)副本的的寫入操作同步完成。即應用程序收到數(shù)據(jù)服務系統(tǒng)的寫成功響應時,多份數(shù)據(jù)都已經(jīng)寫操作成功。

失效轉移

若數(shù)據(jù)服務器集群中任何一臺服務器宕機,那么應用程序針對這臺服務器的所有讀寫操作都需要重新路由到其他服務器,保證數(shù)據(jù)訪問不會失敗,這個過程叫作失效轉移。

失效轉移操作由三部分組成:失效確認、訪問轉移數(shù)據(jù)恢復。

系統(tǒng)確認一臺服務器是否宕機的手段:

  1. 心跳檢測;
  2. 應用程序訪問失敗報告;

5.7 高可用網(wǎng)站的軟件質(zhì)量保證

網(wǎng)站發(fā)布

使用發(fā)布腳本完成發(fā)布

自動化測試

Web 自動化測試技術工具:Selenium

預發(fā)布驗證

網(wǎng)站發(fā)布時,先發(fā)布到預發(fā)布服務器上。

快速失敗:如果系統(tǒng)在啟動時發(fā)現(xiàn)問題就立刻拋出異常,停止啟動讓工程師介入排查錯誤,而不是啟動后執(zhí)行錯誤的操作。

代碼版本控制

版本控制工具:

  • Git;
  • SVN;

自動化發(fā)布

灰度發(fā)布

灰度發(fā)布:將集群服務器分成若干部分,每天只發(fā)布一部分服務器,觀察運行穩(wěn)定沒有故障,第二天繼續(xù)發(fā)布一部分服務器,持續(xù)幾天才把整個集群全部發(fā)布完畢,期間如果發(fā)現(xiàn)問題,只需要回滾已發(fā)布的一部分服務器即可。

5.8 網(wǎng)站運行監(jiān)控

不允許沒有監(jiān)控的系統(tǒng)上線。

監(jiān)控數(shù)據(jù)采集

  1. 用戶行為日志收集。
    • 服務器端日志收集;
    • 客戶端瀏覽器端日志收集;
  2. 服務器性能監(jiān)控。
    • 開源性能監(jiān)控工具:Ganglia。
  3. 運行數(shù)據(jù)報告。

監(jiān)控管理

  • 系統(tǒng)報警;
  • 失效轉移;
  • 自動優(yōu)雅降級;
最后編輯于
?著作權歸作者所有,轉載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

相關閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容