負載均衡 （Load Balancing） 負載均衡建立在現有網路結構之上，它提供了一種廉價有效透明的方法擴充套件網路裝置和伺服器的頻寬、增加吞吐量、加強網路資料處理能力、提高網路的靈活性和可用性。
大型網站負載均衡的利器
- 全域性負載均衡系統（GSLB）
- 內容快取系統（CDN）
- 伺服器負載均衡系統（SLB）
DNS域名解析的基本過程
最初的負載均衡解決方案（DNS輪詢）
優點
- 基本上無成本，因為往往域名註冊商的這種解析都是免費的；
- 部署方便，除了網路拓撲的簡單擴增，新增的Web伺服器只要增加一個公網IP即可
缺點
- 健康檢查，如果某臺伺服器當機，DNS伺服器是無法知曉的，仍舊會將訪問分配到此伺服器。修改DNS記錄全部生效起碼要3-4小時，甚至更久；
- 分配不均，如果幾臺Web伺服器之間的配置不同，能夠承受的壓力也就不同，但是DNS解析分配的訪問卻是均勻分配的。使用者群的分配不均衡導致DNS解析的不均衡。
- 會話保持，如果是需要身份驗證的網站，在不修改軟體構架的情況下，這點是比較致命的，因為DNS解析無法將驗證使用者的訪問持久分配到同一伺服器。雖然有一定的本地DNS快取，但是很難保證在使用者訪問期間，本地DNS不過期，而重新查詢伺服器並指向新的伺服器，那麼原伺服器儲存的使用者資訊是無法被帶到新伺服器的，而且可能要求被重新認證身份，來回切換時間長了各臺伺服器都儲存有使用者不同的資訊，對伺服器資源也是一種浪費。
全域性負載均衡系統（GSLB）
優勢
- 資料中心冗餘備份
- 多站點流量優化
- 確保使用者體驗
全域性負載均衡系統（GSLB）的原理
DNS檢查工具網上有很多，感興趣的可以搜尋一下。
內容快取系統（CDN）
- 內容快取系統（CDN）之靜態加速
- 內容快取系統（CDN）之動態加速
動態加速的特點
- 智慧路由
- 傳輸控制協議（TCP）優化
- HTTP預載
伺服器負載均衡系統
應用背景
- 訪問流量快速增長
- 業務量不斷提高
使用者需求
- 希望獲得7×24的不間斷可用性及較快的系統反應時間
負載均衡必須滿足效能、擴充套件、可靠性
伺服器負載均衡系統三種接入方式
|
部署方式 |
特點 |
優點 |
缺點 |
|
串聯路由模式 |
比較常見的部署方式 |
|
|
|
單臂模式 |
最常見的部署方式 |
|
|
|
DSR |
伺服器回程報文不通過負載均衡裝置，直接返回給客戶端； 延遲短，適合流媒體等對延時要求較高應用 |
|
|
伺服器負載均衡系統的常見排程演算法
- 輪詢（Round Robin）
- 加權輪詢（Weighted Round Robin）
- 最少連線（Least Connections）
- 加權最少連線（Weighted Least Connections）
健康性檢查
健康性檢查演算法的目的：通過某種探針機制，檢查伺服器群中真實伺服器的健康情況，避免把客戶端的請求分發給出現故障的伺服器，以提高業務的HA能力。
目前常用的健康性檢查演算法：
- Ping（ICMP）
- TCP
- HTTP
- FTP
系統加速
優化功能-SSL加速
優化功能-HTTP壓縮
HTTP壓縮是在Web伺服器和瀏覽器間傳輸壓縮文字內容的方法。F5 HTTP壓縮技術通過具有智慧壓縮能力的 BIG-IP 系統可縮短應用交付時間並優化頻寬。HTTP壓縮採用通用的壓縮演算法壓縮HTML、JavaScript或CSS檔案。壓縮的最大好處就是降低了網路傳輸的資料量，從而提高客戶端瀏覽器的訪問速度。
優化功能-連線複用
優化功能-TCP快取
會話保持
會話保持-客戶端源IP會話保持
源IP地址會話保持就是將同一個源IP地址的連線或者請求認為是同一個使用者，根據會話保持策略，在會話保持有效期內，將這些發自同一個源IP地址的連線/請求都轉發到同一臺伺服器。
會話保持-Cookie會話保持
當採用基於源地址的會話保持無法做到負載均分時，例如客戶端發起連線請求的源IP地址相對固定，發生此類問題通常可採用基於應用層的會話保持方式，Cookie通常是存在於HTTP頭中，現如今基於HTTP的應用被廣泛使用，因此基於Cookie的會話保持越來越多的出現在伺服器負載均衡解決方案中。
侷限性：
對於非HTTP協議，或者客戶端禁用Cookie，無效。
會話保持-URL雜湊（Hash）會話保持
雜湊會話保持的一個基本概念就是按照某個Hash因子，根據此因子以及後臺存在多少臺伺服器計算得到的結果來選擇將請求分配到那臺伺服器。雜湊會話保持的特點是在後臺伺服器的健康狀態不發生改變的時候，每個特定的Hash因子被分配到的伺服器是固定的。其最大的優勢是雜湊會話保持可以沒有會話保持表，而僅僅是根據計算的結果來確定被分配到那臺伺服器，尤其在一些會話保持表查詢的開銷已經遠遠大於Hash計算開銷的情況下，採用Hash會話保持可以提高系統的處理能力和響應速度。
URL雜湊會話保持通常針對後臺採用Cache伺服器的應用場景，針對URL進行Hash計算，將同一個URL的請求分配到同一臺Cache伺服器，這樣，對後臺的Cache伺服器群來說，每臺Cache伺服器上存放的內容都是不一樣的，提高Cache伺服器的利用率。
故障案例分析
Q&A案例分析（1）-迴圈跳轉
故障現象：
Web服務端對使用者訪問的URL進行判斷，對於非https的請求，重定向到http站點，結果導致使用者一直302跳轉。
原因分析：
採用了負載均衡SSL加速功能，在服務端看到所有的使用者請求都來自於http。
解決方案：
全站啟用SSL加速。
Q&A案例分析（2）-使用者Session丟失
故障現象：
使用者在http站點上提交資料到同域名的https站點，web程式丟擲session丟失的異常，使用者提交資料失敗。
原因分析：
http和https在負載均衡裝置上被認為是2個獨立的服務，產生2個獨立的TCP連結，會命中不同的真實伺服器，導致session丟失。
解決方案：
在負載均衡裝置上啟用基於真實伺服器的會話保持。
Q&A案例分析（3）-客戶端源IP取不到
故障現象：
服務端獲取不到使用者外網的IP地址，看到的都是大量來自於內網特定網段的IP地址。
原因分析：
負載均衡裝置啟用了使用者源地址轉換（SNAT）模式，修改了TCP報文中的使用者源IP。
解決方案：
負載均衡裝置會用使用者的外網IP改寫x-forwarded-for值，服務端通過獲取http協議中request header頭的x-forwarded-for值作為使用者源IP。IIS日誌通過安裝外掛形式顯示使用者源IP。
伺服器負載均衡裝置選型
硬體裝置：F5、 Citrix 、Redware 、A10
軟體：LVS、Nginx、Haproxy、zen loadbalance
4/7層吞吐量(單位bps)
4/7層新建連線數（單位CPS）
併發連線數
功能模組效能指標（ssl加速、 HTTP壓縮、記憶體Cache）
1）如果確認負載均衡裝置對所有應用的處理都是最簡單的4層處理，那麼理論上選擇的負載均衡裝置的4層效能稍高於實際效能需求即可。
2）如果確認負載均衡裝置對所有應用的處理都是簡單的7層處理，那麼理論上選擇的負載均衡裝置的7層效能稍高於實際效能需求即可。
3）如果負載均衡裝置處理的應用既有4層的也有7層的，建議按照7層應用的效能來考慮負載均衡裝置。
4）如果確認自己的應用經過負載均衡處理時，需要複雜的4層或者7層處理，例如需要根據客戶端的地址做策略性分發，需要根據tcp的內容做處理，需要根據HTTP頭或者HTTP報文做處理，那麼建議選擇的負載均衡裝置4/7層效能為真實效能需求的兩倍。
5）如果負載均衡裝置有混合的複雜流量處理並且還開啟了一些功能模組，那麼建議選擇的負載均衡裝置4/7層效能為真實效能需求的3倍。
6）考慮到裝置需要輕載執行才能更加穩定，所以有可能的話在以上基礎上再增加30%的效能。
7）如果還要滿足未來幾年的發展需求，在以上基礎上還要留出未來發展所需要增加的效能。
8）不同負載均衡裝置廠家由於不同的架構，使得某些裝置在複雜環境下可能也表現的比較優秀，這個客戶可以對比判斷，但總體來說，以上建議適合於所有廠家的裝置。
未完待續
感興趣的可以我關注微博或部落格，如果感覺不錯可以點“推薦”