《大型網站技術架構：核心原理與案例分析》筆記

目錄

· 大型網站軟體系統的特點

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

    · 初始階段的網站架構

        · 需求/解決問題

        · 架構

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

        · 需求/解決問題

        · 架構

    · 使用緩存改善網站性能

        · 需求/解決問題

        · 架構

    · 使用應用伺服器集群改善網站的併發處理能力

        · 需求/解決問題

        · 架構

    · 資料庫讀寫分離

        · 需求/解決問題

        · 架構

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

        · 需求/解決問題

        · 架構

    · 使用分散式文件系統和分散式資料庫系統

        · 需求/解決問題

        · 架構

    · 使用NoSQL和搜索引擎

        · 需求/解決問題

        · 架構

    · 業務拆分

        · 需求/解決問題

        · 架構

    · 分散式服務

        · 需求/解決問題

        · 架構

· 大型網站架構演化心得

· 大型網站架構模式

    · 綜述

    · 分層

        · 概念

        · 目的

        · 舉例

    · 分割

        · 概念

        · 目的

        · 舉例

    · 分散式

        · 概念

        · 目的

        · 缺點

        · 舉例

    · 集群

        · 概念

        · 目的

    · 緩存

        · 概念

        · 目的

        · 舉例

    · 非同步

        · 概念

        · 目的

    · 冗餘

        · 概念

        · 目的

        · 舉例

    · 自動化

        · 目的

        · 舉例

    · 安全

        · 舉例

· 大型網站核心架構要素

    · 性能

        · 網站性能測試

            · 不同視角下的網站性能

            · 性能測試指標

            · 性能測試方法

            · 性能測試報告

        · Web前端性能優化

            · 瀏覽器訪問優化

            · CDN加速

            · 反向代理

        · 應用伺服器性能優化

            · 分散式緩存

            · 非同步操作

            · 使用集群

            · 代碼優化

        · 存儲性能優化

    · 可用性

        · 網站可用性的度量與考核

            · 度量

            · 考核

        · 網站架構高可用（總述）

        · 應用層高可用

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

            · 應用伺服器集群的Session管理

        · 服務層高可用

        · 數據層高可用

            · CAP原理

            · 數據備份

            · 失效轉移

        · 高可用網站軟體質量保證

            · 網站發佈

            · 自動化測試

            · 預發佈驗證

            · 代碼控制

            · 自動化發佈

            · 灰度發佈

        · 網站運行監控

            · 監控數據採集

            · 監控管理

    · 伸縮性

        · 網站架構的伸縮性設計

            · 不同功能進行物理分離實現伸縮

            · 單一功能通過集群規模實現伸縮

        · 應用伺服器集群的伸縮性設計

            · HTTP重定向負載均衡

            · DNS功能變數名稱解析負載均衡

            · 反向代理負載均衡

            · IP負載均衡

            · 數據鏈路層負載均衡

            · 負載均衡演算法

        · 分散式緩存集群的伸縮性設計

        · 數據存儲服務集群的伸縮性設計

            · 關係資料庫集群的伸縮性設計

            · NoSQL資料庫集群的伸縮性設計

    · 擴展性

        · 擴展性與伸縮性

        · 構建可擴展的網站架構

        · 利用分散式消息隊列降低系統耦合性

        · 利用分散式服務打造可復用的業務平臺

    · 安全性

        · 網站應用攻擊與防禦

            · XSS攻擊

            · 註入攻擊

            · CSRF攻擊

        · Web應用防火牆

        · 網站安全漏洞掃描

        · 信息加密技術及密鑰安全管理

            · 單向散列加密

            · 對稱加密

            · 非對稱加密

        · 密鑰安全管理

· 網購秒殺系統架構設計案例分析

    · 秒殺活動的技術挑戰

    · 秒殺系統架構設計

大型網站軟體系統的特點

與傳統企業應用相比，大型互聯網應用系統有以下特點：

1. 高併發，大流量；

2. 高可用：系統7×24小時不間斷服務；

3. 海量數據：需要存儲、管理海量數據，需要使用大量伺服器；

4. 用戶分佈廣泛，網路情況複雜：許多大型互聯網都是為全球用戶提供服務的，用戶分佈範圍廣，各地網路情況千差萬別；

5. 安全環境惡劣：由於互聯網的開放性，使得互聯網更容易受到攻擊，大型網站幾乎每天都會被黑客攻擊；

6. 需求快速變更，發佈頻繁：和傳統軟體的版本發佈頻率不同，互聯網產品為快速適應市場，滿足用戶需求，其產品發佈頻率是極高的；

7. 漸進式發展：與傳統軟體產品或企業應用系統一開始就規劃好全部的功能和非功能需求不同，幾乎所有的大型互聯網網站都是從一個小網站開始，漸進地發展起來的。

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

初始階段的網站架構

需求/解決問題

小網站最開始沒有太多人訪問。

架構

應用程式、資料庫、文件等所有的資源都在一臺伺服器上。

應用服務和數據服務分離

需求/解決問題

隨著網站業務的發展，越來越多的用戶訪問導致性能越來越差，越來越多的數據導致存儲空間不足。

架構

應用和數據分離後整個網站使用三台伺服器，其對硬體資源的要求各不相同：應用伺服器處理大量業務邏輯，需要更快更強大的CPU；資料庫伺服器快速磁碟檢索和數據

緩存，需要更快的磁碟和更大的記憶體；文件伺服器存儲大量用戶上傳的文件，需要更大的磁碟。

使用緩存改善網站性能

需求/解決問題

用戶逐漸增多，資料庫壓力太大導致訪問延遲。

架構

根據二八定律：80%的業務訪問集中在20%的數據上，把小部分數據緩存在記憶體中，可減少資料庫訪問壓力。

使用應用伺服器集群改善網站的併發處理能力

需求/解決問題

單一應用伺服器能夠處理的請求連接有限。

架構

Scale up有限，Scale out無限，所以應用伺服器要Scale out。

資料庫讀寫分離

需求/解決問題

一部分讀操作（緩存訪問不命中、緩存過期）和全部的寫操作需要訪問資料庫。

架構

應用伺服器寫數據時，訪問主資料庫，主資料庫通過主從複製機制將數據更新同步到從資料庫；當應用伺服器讀數據時，可通過從資料庫獲得數據。通常在應用伺服器端使用專門的數據訪問模塊，使資料庫讀寫分離對應用透明。

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

需求/解決問題

中國網路環境複雜，不同地區的用戶訪問網站時，速度差別極大，網站訪問延遲導致用戶流失率提高。

架構

CDN和反向代理目的都是儘早返回數據、加快訪問速度、減輕後端伺服器負載壓力。

1. CDN：部署在網路提供商機房。用戶請求網站服務時，可從距離自己最近的網路提供商機房獲取數據。

2. 反向代理：部署在網站中心機房。用戶請求到達中心機房後，首先訪問反向代理伺服器，如果反向代理伺服器緩存著用戶請求的資源，就將其直接返回給用戶。

使用分散式文件系統和分散式資料庫系統

需求/解決問題

讀寫分離伸縮性有限。

架構

只有在單表數據規模非常龐大的時候（不到萬不得已）才資料庫拆分，按業務分庫，不同的業務數據部署在不同的物理伺服器上。

使用NoSQL和搜索引擎

需求/解決問題

隨著網站業務越來越複雜，對數據存儲和檢索的需求也越來越複雜。

架構

1. NoSQL和搜索引擎都是源自互聯網的技術手段，可伸縮的分散式特性更好；

2. 應用伺服器通過一個統一數據訪問模塊訪問各種數據。

業務拆分

需求/解決問題

業務場景日益複雜。

架構

1. 將整個網站業務分成不同產品線（如大型購物交易網站拆分為首頁、商鋪、訂單、買家、賣家），分歸不同業務團隊負責。

2. 根據產品線劃分，將網站拆分成不同應用，每個應用獨立部署維護。應用間關聯方式：

    a) 超鏈接（首頁上導航鏈接每個應用地址）；

    b) 通過消息隊列進行數據分發；

    c) 通過同一數據存儲系統構成一個關聯的完整系統（最多）。

分散式服務

需求/解決問題

所有應用要和所有資料庫系統鏈接，在數萬台伺服器規模的網站中，連接數目時伺服器規模的平方，導致資料庫連接資源不足，拒絕服務。

架構

將共用的業務提取出服務，獨立部署。

大型網站架構演化心得

1. 大型網站架構技術的核心價值不是從無到有搭建一個大型網站，而是能夠伴隨小型網站業務的逐步發展，慢慢地演化成一個大型網站。

2. 驅動大型網站技術發展的主要力量時網站的業務發展。

3. 技術是用來解決業務問題的，而業務問題，也可以通過業務手段去解決。

    a) 12306的問題不在於技術架構，而在於業務架構：幾億中國一票難求的情況下，零點開始出售若幹天後的車票；

    b) 解決：售票方式上引入排隊機制、整點售票調整為分時段售票。

大型網站架構模式

綜述

1. 模式：每一個模式描述了一個在我們周圍不斷重覆發生的問題及該問題解決方案的核心。這樣，你就能一次又一次地使用該方案而不必做重覆工作。

2. 網站架構模式：大型互聯網公司在實踐中提出了許多解決方案，以實現網站高性能、高可用、易伸縮、可擴展、安全等各種技術框架目標。這些解決方案又被更多網站重覆使用，從而逐漸形成大型網站架構模式。

分層

概念

1. 將系統在橫向維度上切分成幾個部分，每個部分負責一部分相對比較單一的職責，然後通過上層對下層的依賴和調用組成一個完整的系統。

2. 實踐中，大的分層結構內部還可以繼續分層。

目的

1. 便於分工合作開發和維護；

2. 各層獨立，只要維持調用介面不變，各層可根據具體問題獨立演化發展而無需其他層必須相應調整；

3. 物理部署上，三層結構可部署在同一物理機器上，隨著網站業務發展，必然要分離部署，其三層結構分別部署在不同伺服器，使網站擁有更多計算資源應對更多用戶訪

問。

舉例

分割

概念

1. 從縱向方面對軟體進行切分，將不同功能和服務分割開來，包裝成高內聚低耦合的模塊單元。

2. 大型網站分割粒度可能會很小。

目的

1. 有助於軟體開發和維護；

2. 便於不同模塊的分散式部署，提供網站的併發處理能力和功能擴展能力。

舉例

1. 在應用層，按業務分割為購物、論壇、搜索、廣告不同的應用，獨立團隊負責，部署在不同伺服器；

2. 同一應用內部，如果規模龐大業務複雜，會繼續分割，比如購物業務分割為機票酒店業務、3C業務、小商品業務等更細小的粒度。

分散式

概念

分層和分割的一個主要目的是為了切分後的模塊便於分散式部署，即不同模塊部署在不同伺服器上，通過遠程調用協同工作。

目的

可使用更多的電腦完成同樣的功能，電腦越多，CPU、記憶體、存儲資源也越多，處理併發訪問和數據兩就越大。

缺點

1. 分散式服務調用必須通過網路，可能會影響性能；

2. 伺服器越多，伺服器宕機概率就越大；

3. 分散式環境數據一致性非常困難，分散式事務也難以保證；

4. 分散式導致網站依賴錯綜複雜，開發管理維護困難。

舉例

1. 分散式應用和服務：將分層和分割後的應用和服務模塊分散式部署。

2. 分散式靜態資源：網站的靜態資源如JS、CSS、Logo圖片等資源獨立分散式部署，並採用獨立功能變數名稱，即動靜分離。

3. 分散式數據和存儲：大型網站需處理以P為單位的海量數據，單台電腦無法提供如此大的存儲空間，此時需分散式存儲。

4. 分散式計算：嚴格來說，應用、服務、實時數據處理都是計算，網站除了要處理這些線上業務，還有很大一部分後臺業務，包括搜索引擎的索引構建、數據倉庫的數據分析統計等。

集群

概念

通過負載均衡技術為一個應用構建一個多台伺服器組成的集群，共同對外提供服務。

目的

提高系統可用性。

緩存

概念

將數據存放在距離計算最近的位置。

目的

加快處理速度。

舉例

1. CDN。

2. 反向代理。

3. 本地緩存。

4. 分散式緩存。

5. 以上4個都在前面章節已說明，不再贅述。

非同步

概念

1. 單一伺服器內部可通過多線程共用內部隊列方式實現非同步，業務操作前面的線程將輸出寫入隊列，後面的線程從隊列讀取數據處理。

2. 分散式系統中，多個伺服器集群通過分散式消息隊列實現非同步。

目的

1. 提高系統可用性：消費者伺服器發生故障，數據會在消息隊列伺服器存儲堆積，生產伺服器可以繼續處理業務請求，系統整體表現無故障。消費者伺服器恢復正常後，繼續處理消息隊列中的數據。

2. 加快網站響應速度：業務處理前端的生產著伺服器將數據寫入消息隊列，無需等待消費者伺服器處理就可以返回，響應延遲減少。

3. 消除併發訪問高峰：用戶訪問網站是隨機的，雖然存在高峰和低谷，但突發事件（促銷活動、微博熱點事件）會造成網站併發訪問突然增大。使用消息隊列將突然增加的訪問請求數據放入消息隊列，等待消費者伺服器依次處理，減小網站負載壓力。

4. 解耦，提升擴展性。

5. 缺點：消費者伺服器處理（如業務校驗、寫資料庫）失敗，以訂單提交為例，可在成功提交後Email或簡訊通知用戶訂單成功，避免交易糾紛。

冗餘

概念

任何服務都必須部署至少兩台伺服器構成的一個集群。

目的

實現服務高可用。

舉例

1. 冷備份：定期備份，存檔保存。

2. 熱備份：主從分離，實時同步。

自動化

目的

減少人為干預，減少故障。

舉例

1. 自動化發佈。

    a) 自動化代碼管理：代碼版本控制、代碼分支創建合併等過程自動化，開發工程師只要提交自己參與開發的產品代號，系統自動為其創建開發分支，後期自動合併代碼。

    b) 自動化測試：代碼開發完成，提交測試後，系統自動將代碼部署到測試環境，啟動自動化測試用例測試，向相關人員發送測試報告，向系統反饋測試結果。

    c) 自動化安全檢測：安全檢測工具對代碼靜態安全掃描及部署到安全測試環境進行安全攻擊測試，評估安全性。

    d) 自動化部署：將工程代碼自動部署到線上生產環境。

2. 自動化監控。

    a) 自動化報警：對線上生產環境自動化監控，對伺服器心跳檢測，及各項性能指標和應用程式的關鍵數據指標。如果發現異常、超出預設閥值，自動化向相關人員發送報警，警告故障可能發生。

    b) 自動化失效轉移：檢測到故障發生後，系統自動化將失效伺服器從集群隔離，不再處理請求。

    c) 自動化失效恢復：待故障消除後，系統自動化重新啟動服務，同步數據保證數據一致性。

    d) 自動化降級：網站遇到訪問高峰，超出網站最大處理能力時，為保證整個網站安全可用，會自動化拒絕部分請求及關閉部分不重要服務將系統負載降至安全水平。

    e) 自動化分配資源：將空閑資源分配給重要服務，擴大部署規模。

安全

舉例

1. 通過密碼和手機驗證碼身份認證。

2. 登錄、交易等操作需網路通信加密，網站伺服器上存儲的敏感數據也加密處理。

3. 使用驗證碼識別，防止機器人程式濫用網路資源攻擊網站。

4. 對常見的用於攻擊網站的XSS攻擊、SQL註入進行編碼轉換等處理。

5. 對垃圾信息、敏感信息過濾。

6. 對交易轉賬等重要操作根據交易模式和交易信息進行風險控制。

大型網站核心架構要素

性能

網站性能測試

不同視角下的網站性能

1. 用戶視角：用戶在瀏覽器上直觀感受到的網站相應速度，包括用戶電腦和網站伺服器通信的速度、網站伺服器處理的速度、用戶電腦瀏覽器構造請求解析響應數據的速度。

2. 開發人員視角：應用程式本身及其相關子系統的性能，包括響應延遲、系統吞吐量、併發處理能力、系統穩定性等技術指標。

3. 運維人員視角：基礎設施性能和資源利用率，如網路運營商的帶寬、伺服器硬體的配置、數據中心網路架構、伺服器和網路帶寬的資源利用率等。

性能測試指標

1. 響應時間

    a) 解釋：從發出請求開始到收到最後響應數據所需要的時間。

    b) 意義：系統最重要的性能指標。

    c) 測試方法：測試程式通過模擬應用程式，記錄收到響應和發出請求之間的時間差；通常重覆請求，取平均值。

    d) 常用系統操作響應時間表。

2. 併發數

    a) 解釋：同時處理請求的數目，反映了系統的負載特性。網站併發數指“併發用戶數”。

    b) 併發用戶數：同時提交請求的用戶數目。

    c) 線上用戶數：當前登錄網站的用戶數目。

    d) 系統用戶數：可能訪問系統的總用戶數，對多數網站而言就是註冊用戶數。

    e) 三者數量比較關係：系統用戶數>>線上用戶數>>併發用戶數。

    f) 意義：網站產品設計初期，產品經理和運營人員要規劃不同發展階段網站系統用戶數，以此為基礎，推算線上用戶數和併發用戶數，這些指標是非功能設計的重要依據。

    g) 測試方法：測試程式多線程模擬併發用戶測試併發處理能力；測試程式並不多線程不停發送請求，而是兩次請求間加隨機等待時間，模擬用戶思考時間。

3. 吞吐量

    a) 解釋：單位時間內系統處理的請求數量。

    b) 常用量化指標：“請求數/秒”或“頁面數/秒”、“訪問人數/天”或“處理的業務數/小時”、TPS（每秒事務數）、HPS（每秒HTTP請求數）、QPS（每秒查詢數）。

    c) 三者關係：併發數由小逐增過程中，伺服器資源消耗逐增，吞吐量逐增，響應時間小幅上升；達到吞吐量極限後，併發數增加反而下降，響應時間快速上升；達到系統崩潰點後，系統資源耗盡，吞吐量為零，失去響應。

4. 性能計數器

    a) 解釋：描述伺服器或操作系統性能一些數據指標，包括System Load、對象與線程數、記憶體使用、CPU使用、磁碟與網路IO等。

    b) 意義：系統監控的重要參數，監控系統發現性能計數器超過閥值時，向運維人員報警，及時發現處理異常。

    c) System Load（系統負載）：當前正在被CPU執行和等待被CPU執行的進程數目總和，反映系統閑忙程度的重要指標。多核CPU情況下，Load值等於CPU數目時，說明所有CPU都在使用，沒有CPU不足和空閑；Load值大於CPU數目時，說明進程排隊等待CPU調度，資源不足；Load值小於CPU數目時，說明CPU空閑。Linux的“top”命令可查詢最近1分鐘、10分鐘、15分鐘的運行隊列平均進程數。

性能測試方法

1. 性能測試是總稱，細分為：

    a) 性能測試：以系統設計初期規劃的性能指標為預期目標，不斷施加壓力（增加併發請求），驗證系統在資源可接受範圍，可否達到預期。

    b) 負載測試：不斷施加壓力（增加併發請求），直到某項或多項性能指標達到安全臨界值（比如資源已飽和）。此時繼續加壓，系統處理能力會下降。

    c) 壓力測試：超過安全負載情況下，不斷施加壓力（增加併發請求），直到系統崩潰或無法處理任何請求，依此獲得系統最大壓力承受能力。

    d) 穩定性測試：被測試系統在特定硬體、軟體、網路環境下，載入一定業務壓力（模擬生產環境不同時間點、不均勻請求，呈波浪特性）運行一段較長時間，以此檢測系統是否穩定。

2. 性能測試曲線：橫坐標為消耗的系統資源，縱坐標為吞吐量。a~b為網站日常運行區間，c為系統最大負載點，d為系統崩潰點。

性能測試報告

Web前端性能優化

瀏覽器訪問優化

1. 減少HTTP請求：合併CSS、合併JavaScript、合併圖片。

2. 使用瀏覽器緩存：CSS、JavaScript、Logo、圖標等靜態資源文件更新頻率較低，通過HTTP頭Cache-Control和Expires設置緩存數天，甚至幾個月。更新此類文件時，不更新內容，而是修改文件名，生成新文件並更新HTML引用。當有一批此類文件要更新時，不宜一次全部更新，而是逐個更新，並有時間間隔，以免瀏覽器大量緩存失效，集中更新緩存，伺服器負載劇增。

3. 啟用壓縮：文本文件（如HTML、CSS、JavaScript）GZip壓縮率可達80%以上，有效減少通信傳輸數據量。但伺服器、瀏覽器壓力上升，所以要權衡。

4. CSS放在頁面最上面，JavaScript放在頁面最下麵：瀏覽器下載全部CSS後才渲染頁面，而在載入JavaScript後立即執行，可能會阻塞頁面，渲染緩慢。

5. 減少Cookie傳輸：每次請求和響應都會包含Cookie，影響數據傳輸；靜態資源訪問（如CSS、JavaScript）發送Cookie無意義。可靜態資源使用獨立功能變數名稱，避免請求靜態資源時發送Cookie。

CDN加速

前面章節已說明，不再贅述。

反向代理

前面章節已說明，不再贅述。

應用伺服器性能優化

分散式緩存

1. 網站性能優化第一定律：優先考慮使用緩存優化性能。

2. 緩存有點：緩存訪問速度快，減少數據訪問時間；如果緩存的數據是經過計算得到的，則此類數據無需重覆計算可直接使用。

3. 緩存本質：以一對Key、Value形式存儲在記憶體的Hash表，讀寫時間複雜度O(1)。

4. 使用緩存註意事項。

    a) 頻繁修改的數據：如果緩存頻繁修改的數據，會造成寫入緩存後來不及讀取已失效。一般數據讀寫比應在2:1以上，甚至更高。

    b) 沒有熱點的訪問：緩存使用記憶體，資源寶貴，應遵循二八定律，即緩存20%熱點數據。

    c) 數據不一致與臟讀：一般設置緩存失效時間，失效後從資料庫載入，因此要容忍一定時間的數據不一致。也可數據更新時立即更新緩存，但會帶來更多系統開銷和事務一致性問題。

    d) 緩存可用性：為避免緩存雪崩（緩存不可用造成資料庫無法承受壓力而宕機），可將緩存數據分佈到集群多台伺服器，宕機時只有部分緩存數據丟失。

    e) 緩存預熱（warn up）：熱點數據是通過LRU（最近最久未用演算法）淘汰生成的，需較長時間。

    f) 緩存穿透：緩存不存在的數據（其值為null），避免不恰當業務或惡意攻擊高併發請求某個不存在數據，造成資料庫壓力而崩潰。

非同步操作

前面章節已說明，不再贅述。

使用集群

前面章節已說明，不再贅述。

代碼優化

1. 多線程

    a) 目的：利用多線程IO阻塞與執行交替進行，最大限度利用CPU資源；多線程最大限度利用多核CPU。

    b) Web容器線程數設置：如果都是CPU計算型任務，則線程數最多不超過CPU內核數（更多線程CPU來不及調度）；如果都是等待磁碟IO、網路IO的任務，則多啟動線程有助於提高任務併發度，提高吞吐能力。

2. 資源復用：單例（Singleton）、對象池（Object Pool）。

3. 數據結構。

4. 垃圾回收：即優化JVM。

存儲性能優化

可能暫時不重要，以後需要時在看書。

可用性

網站可用性的度量與考核

度量

1. 業界通常用多少個9來衡量網站可用性。

2. 網站不可用也稱網站故障。

3. 網站不可用時間公式：

網站不可用時間（故障時間）= 故障修複時間點-故障發現（報告）時間點

4. 網站年度可用性指標公式：

網站年度可用性指標 =（1-網站不可用時間/年度總時間）×100%

5. 常見可用性：

考核

1. 故障分：對網站故障進行分類加權計算故障責任的方法。

2. 網站故障分類權重表（示例）

3. 故障分公式：

故障分=故障時間（分鐘）×故障權重

4. 考核過程：年初或考核季度開始時，根據網站產品可用性指標計算總的故障分，然後根據團隊和個人職責角色分攤故障分，這個可用性指標和故障分是管理預期；故障發生後，根據故障分類和責任劃分給故障產生的故障分分配給責任者承擔；年末或考核季度末時，個人及團隊實際承擔的故障分如果超過年度分攤的故障分，績效考核受到影響。

網站架構高可用（總述）

1. 以百度為例。

    a) 應用層：文庫、貼吧、百科等屬不同產品，各自獨立部署集群。

    b) 服務層：應用層產品依賴共同的復用業務，這些業務服務各自部署集群。

    c) 數據層：各自部署集群。

2. 實現高可用架構主要手段：數據和服務的冗餘備份及失效轉移。

3. 應用層高可用：通過負載均衡設備將一組伺服器組成一個集群對外處理高併發請求，負載均衡設備通過心跳檢測等手段監控到應用伺服器不可用時，將其從集群列表剔除，請求分發到集群其他可用伺服器上。

4. 服務層高可用：也是通過集群實現高可用。服務層被應用層通過分散式服務調用框架訪問，分散式服務調用框架在應用層客戶端中實現負載均衡，服務註冊中心獲取服務層伺服器心跳檢測，發現不可用伺服器，立即通知客戶端修改服務層訪問列表，剔除不可用伺服器（說的就是Dubbo）。

5. 數據層高可用：比較特殊，數據伺服器存儲了數據。數據寫入時同步複製數據到多台伺服器上，實現數據冗餘備份；數據伺服器宕機時，數據訪問切換到備份數據伺服器上