[架構設計] 高性能負載均衡

高性能負載均衡：分類及架構

• single server 無論如何優化，無論採用多好的硬體，總會有一個性能天花板

• 高性能 cluster 的本質很簡單，通過增加更多的 server 來提升系統整體的計算能力

• 計算本身存在一個特點：同樣的輸入資料和邏輯，無論在那台 server 上執行，都應該得到相同的輸出

• 高性能 cluster 設計的複雜度主要體現在任務分配這部分

• 高性能 cluster 的複雜性主要體現在需要增加一個任務分配器，以及為任務選擇一個合適的任務分配算法

• 實際上任務分配並不只是考慮計算單元的負載均衡，不同的任務分配算法目標是不一樣的

  有的基於負載考慮，有的基於性能（吞吐量、響應時間）考慮，有的基於業務考慮

負載均衡分類

DNS 負載均衡

• DNS 是最簡單也是最常見的負載均衡方式，一般用來實現地理級別的均衡

• 優點：

  • 簡單、成本低
  • 就近訪問，提升訪問速度

• 缺點：

  • 更新不即時：DNS cache
  • 擴展性差：DNS 負載均衡的控制權在域名商那裡，無法根據業務特點針對其做更多的定製化功能和擴展特性
  • 分配策略比較簡單：DNS 負載均衡支持的算法少；不能區分 server 的差異(不能根據系統與服務的狀態來判斷負載)；也無法感知後端 server 的狀態

• 針對 DNS 負載均衡的一些缺點，對於時延和故障敏感的業務，有一些公司自己實現了 HTTP-DNS 的功能

硬體負載均衡

• 硬體負載均衡是通過單獨的硬體設備來實現負載均衡功能

• 這類設備性能強勁、功能強大，但價格都不便宜

• 優點：

  • 功能強大：全面支持各層級的負載均衡，支持全面的負載均衡算法，支持全局負載均衡
  • 性能強大：對比一下，軟體負載均衡支持到 10 萬級並發已經很厲害了，硬體負載均衡可以支持 100 萬以上的並發
  • 穩定性高：商用硬體負載均衡，經過了良好的嚴格測試，經過大規模使用，穩定性高。
  • 支持安全防護：硬體均衡設備除具備負載均衡功能外，還具備防火牆、防 DDoS 攻擊等安全功能。

• 缺點：

  • 價格昂貴
  • 擴展能力差：硬體設備，可以根據業務進行配置，但無法進行擴展和定製

軟體負載均衡

• 軟體負載均衡的最大優勢是便宜

• 常見的有 Nginx 和 LVS，其中 Nginx 是軟體的 7 層負載均衡，LVS 是 Linux 內核的 4 層負載均衡

• 4 層和 7 層的區別就在於協議和靈活性，Nginx 支持 HTTP、E-mail 協議；而 LVS 是 4 層負載均衡，和協議無關，幾乎所有應用都可以做，例如，聊天、資料庫等

• 軟體和硬體的最主要區別就在於性能，硬體負載均衡性能遠遠高於軟體負載均衡性能

• 一般的 Linux server 上裝一個 Nginx 大概能到 50,000/秒；LVS 的性能是十萬級，據說可達到 800,000/秒；而 F5 性能是百萬級，從 2,000,000/秒到 8,000,000/ 秒都有

• 軟體負載均衡的優點：

  • 簡單：無論是部署還是維護都比較簡單
  • 便宜：只要買個 Linux server ，裝上軟體即可
  • 靈活：4 層和 7 層負載均衡可以根據業務進行選擇；也可以根據業務進行比較方便的擴展，例如，可以通過 Nginx 的 plugin 來實現業務的定製化功能

• 缺點的部份都是和硬體負載均衡相比的，並不是說軟體負載均衡沒法用：

  • 性能一般：一個 Nginx 大約能支撐 50,000 並發。
  • 功能沒有硬體負載均衡那麼強大
  • 一般不具備防火牆和防 DDoS 攻擊等安全功能

負載均衡典型架構

• DNS 負載均衡、硬體負載均衡、軟體負載均衡，每種方式都有一些優缺點，但並不意味著在實際應用中只能基於它們的優缺點進行非此即彼的選擇，反而是基於它們的優缺點進行組合使用

• 組合的基本原則為：

  • DNS 負載均衡用於實現地理級別的負載均衡
  • 硬體負載均衡用於實現 cluster 級別的負載均衡
  • 軟體負載均衡用於實現機器級別的負載均衡

• 整個系統的負載均衡分為三層。
  • 地理級別負載均衡：www.xxx.com 部署在所屬地理區域不同的三個機房
  • cluster 級別負載均衡：機房 A 的負載均衡用的是 F5 設備，F5 收到用戶請求後，進行 cluster 級別的負載均衡
  • 機器級別的負載均衡：cluster 2 的負載均衡用的是 Nginx

討論整理精華

• PV（page view）

• 從 DAU(Daily Active User) 出發，結合業務的特點，計算出來總的 QPS(Query Per Second) 和 TPS(Transactions Per Second)，而後再根據通常規律計算出 QPS 和 TPS 的峰值，加上一定的未來發展空間和高可用冗餘，結合單機能夠支撐的 QPS 和 TPS 量，就可以計算出來整個 cluster 的規模，有了這些資料就可以制定出比較合理的負載均衡的策略

• nginx 做級聯不太合適，因為頂層的 nginx 性能是瓶頸，多級導流一般用在處理能力有差異的系統上，例如一級用 F5，二級用 LVS，三級用 nginx

• 論壇業務其實可以不用 DNS 做地理位置負載均衡，用CDN效果更好

高性能負載均衡：算法

負載均衡算法數量較多，根據算法期望達到的目的，大體上可以分為下面幾類：

• 任務平分類：負載均衡系統將收到的任務平均分配給 server 進行處理，這裡的”平均”可以是絕對數量的平均，也可以是比例或者權重上的平均

• 負載均衡類：負載均衡系統根據 server 的負載來進行分配，這裡的負載並不一定是通常意義上我們說的”CPU 負載”，而是系統當前的壓力，可以用 CPU 負載來衡量，也可以用連接數、I/O 使用率、網卡吞吐量等來衡量系統的壓力

• 性能最優類：負載均衡系統根據 server 的響應時間來進行任務分配，優先將新任務分配給響應最快的 server

• Hash 類：負載均衡系統根據任務中的某些關鍵訊息進行 Hash 運算，將相同 Hash 值的請求分配到同一台 server 上。常見的有 source IP hash、target IP hash、session ID hash、user ID hash 等

輪詢(任務平分類)

• 負載均衡系統收到請求後，按照順序輪流分配到 server 上

• 是最簡單的一個策略，無須關注 server

• 某個 server 當前因為觸發了程序 bug 進入了死循環導致 CPU 負載很高，負載均衡系統是不感知的，還是會繼續將請求源源不斷地發送給它

• cluster 中有新的機器是 32 核的，舊的機器是 16 核的，負載均衡系統也是不關注的，新舊機器分配的任務數是一樣的

• 只要 server 在運行，運行狀態是不關注的。但如果 server 直接當機了，或者 server 和負載均衡系統斷連了，這時負載均衡系統是能夠感知的，也需要做出相應的處理

• “簡單”是輪詢算法的優點，也是它的缺點

加權輪詢(任務平分類)

• 權重一般是根據硬體配置進行靜態配置的，採用動態的方式計算會更加契合業務，但複雜度也會更高

• 主要目的就是為了解決不同 server 處理能力有差異的問題

• 加權輪詢解決了輪詢算法中無法根據 server 的配置差異進行任務分配的問題，但同樣存在無法根據 server 的狀態差異進行任務分配的問題

負載最低優先(負載均衡類)

• 負載均衡系統將任務分配給當前負載最低的 server ，這裡的負載根據不同的任務類型和業務場景，可以用不同的指標來衡量：

  • LVS 這種 4 層網路負載均衡設備，可以以”連接數”來判斷 server 的狀態， server 連接數越大，表明 server 壓力越大。
  • Nginx 這種 7 層網路負載系統，可以以”HTTP 請求數”來判斷 server 狀態(Nginx 內建的負載均衡算法不支持這種方式，需要進行擴展)
  • 如果我們自己開發負載均衡系統，可以根據業務特點來選擇指標衡量系統壓力。如果是 CPU 密集型，可以以”CPU 負載”來衡量系統壓力；如果是 I/O 密集型，可以以”I/O 負載”來衡量系統壓力。

• 負載最低優先的算法解決了輪詢算法中無法感知 server 狀態的問題，由此帶來的代價是複雜度要增加很多

• 最少連接數優先的算法要求負載均衡系統統計每個 server 當前建立的連接，其應用場景僅限於負載均衡接收的任何連接請求都會轉發給 server 進行處理，否則如果負載均衡系統和 server 之間是固定的連接池方式，就不適合採取這種算法

• CPU 負載最低優先的算法要求負載均衡系統以某種方式收集每個 server 的 CPU 負載，不同業務最優的時間間隔(1~15 mins)是不一樣的，時間間隔太短容易造成頻繁波動，時間間隔太長又可能造成峰值來臨時響應緩慢

• 負載最低優先算法雖然效果看起來很美好，但實際上真正應用的場景反而沒有輪詢(包括加權輪詢)那麼多

性能最優類

• 負載最低優先類算法是站在 server 的角度來進行分配的，而性能最優優先類算法則是站在客戶端的角度來進行分配的

• 優先將任務分配給處理速度最快的 server ，通過這種方式達到最快響應客戶端的目的

• 通過響應時間這個外部標準來衡量 server 狀態

• 複雜度都很高，主要體現在：

  • 負載均衡系統需要收集和分析每個 server 每個任務的響應時間，在大量任務處理的場景下，這種收集和統計本身也會消耗較多的性能
  • 為了減少這種統計上的消耗，可以採取採樣的方式來統計，使用抽樣統計部分任務的響應時間來估算整體任務的響應時間
  • 採樣統計雖然能夠減少性能消耗，但使得複雜度進一步上升，因為要確定合適的採樣率
  • 無論是全部統計還是採樣統計，都需要選擇合適的週期，需要根據實際業務進行判斷和選擇

Hash 類

• 根據任務中的某些關鍵訊息進行 Hash 運算，將相同 Hash 值的請求分配到同一台 server 上

• source IP Hash：將來源於同一個 s ource IP 地址的任務分配給同一個 server 進行處理，適合於存在事務、會話的業務

• 將某個 ID 標識的業務分配到同一個 server 中進行處理，這裡的 ID 一般是臨時性資料的 ID

討論整理精華

• 高並發同步資料代價比較大

References

• 從0開始學架構_架構基礎_架構入門-極客時間

• [百亿级微信红包的高并发资金交易系统设计方案 - InfoQ](百亿级微信红包的高并发资金交易系统设计方案 - InfoQ)