負(fù)載均衡 （Load Balancing） 負(fù)載均衡建立在現(xiàn)有網(wǎng)絡(luò)結(jié)構(gòu)之上，它提供了一種廉價有效透明的方法擴(kuò)展網(wǎng)絡(luò)設(shè)備和服務(wù)器的帶寬,、增加吞吐量,、加強(qiáng)網(wǎng)絡(luò)數(shù)據(jù)處理能力、提高網(wǎng)絡(luò)的靈活性和可用性,。

大型網(wǎng)站負(fù)載均衡的利器

• 全局負(fù)載均衡系統(tǒng)（GSLB）

• 內(nèi)容緩存系統(tǒng)（CDN）

• 服務(wù)器負(fù)載均衡系統(tǒng)（SLB）

DNS域名解析的基本過程

最初的負(fù)載均衡解決方案（DNS輪詢）

優(yōu)點

• 基本上無成本,，因為往往域名注冊商的這種解析都是免費的；

• 部署方便,，除了網(wǎng)絡(luò)拓?fù)涞暮唵螖U(kuò)增,，新增的Web服務(wù)器只要增加一個公網(wǎng)IP即可

缺點

• 健康檢查，如果某臺服務(wù)器宕機(jī),，DNS服務(wù)器是無法知曉的,，仍舊會將訪問分配到此服務(wù)器。修改DNS記錄全部生效起碼要3-4小時,，甚至更久,；

• 分配不均，如果幾臺Web服務(wù)器之間的配置不同,，能夠承受的壓力也就不同,，但是DNS解析分配的訪問卻是均勻分配的。用戶群的分配不均衡導(dǎo)致DNS解析的不均衡,。

• 會話保持,，如果是需要身份驗證的網(wǎng)站，在不修改軟件構(gòu)架的情況下,，這點是比較致命的,，因為DNS解析無法將驗證用戶的訪問持久分配到同一服務(wù)器。雖然有一定的本地DNS緩存,，但是很難保證在用戶訪問期間,，本地DNS不過期，而重新查詢服務(wù)器并指向新的服務(wù)器,，那么原服務(wù)器保存的用戶信息是無法被帶到新服務(wù)器的,，而且可能要求被重新認(rèn)證身份，來回切換時間長了各臺服務(wù)器都保存有用戶不同的信息,，對服務(wù)器資源也是一種浪費,。

全局負(fù)載均衡系統(tǒng)（GSLB）

優(yōu)勢

• 數(shù)據(jù)中心冗余備份

• 多站點流量優(yōu)化

• 確保用戶體驗

全局負(fù)載均衡系統(tǒng)（GSLB）的原理

DNS檢查工具網(wǎng)上有很多，感興趣的可以搜索一下,。

內(nèi)容緩存系統(tǒng)（CDN）

• 內(nèi)容緩存系統(tǒng)（CDN）之靜態(tài)加速

• 內(nèi)容緩存系統(tǒng)（CDN）之動態(tài)加速

動態(tài)加速的特點

• 智能路由

• 傳輸控制協(xié)議（TCP）優(yōu)化

• HTTP預(yù)載

服務(wù)器負(fù)載均衡系統(tǒng)

應(yīng)用背景

• 訪問流量快速增長

• 業(yè)務(wù)量不斷提高

用戶需求

服務(wù)器負(fù)載均衡系統(tǒng)的常見調(diào)度算法

• 輪詢（Round Robin）

• 加權(quán)輪詢（Weighted Round Robin）

• 最少連接（Least Connections）

• 加權(quán)最少連接（Weighted Least Connections）

健康性檢查

健康性檢查算法的目的：通過某種探針機(jī)制,，檢查服務(wù)器群中真實服務(wù)器的健康情況，避免把客戶端的請求分發(fā)給出現(xiàn)故障的服務(wù)器,，以提高業(yè)務(wù)的HA能力,。

目前常用的健康性檢查算法：

• Ping（ICMP）

• TCP

• HTTP

• FTP

系統(tǒng)加速

優(yōu)化功能-SSL加速

優(yōu)化功能-HTTP壓縮

 HTTP壓縮是在Web服務(wù)器和瀏覽器間傳輸壓縮文本內(nèi)容的方法。F5 HTTP壓縮技術(shù)通過具有智能壓縮能力的 BIG-IP 系統(tǒng)可縮短應(yīng)用交付時間并優(yōu)化帶寬,。HTTP壓縮采用通用的壓縮算法壓縮HTML,、JavaScript或CSS文件。壓縮的最大好處就是降低了網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量,，從而提高客戶端瀏覽器的訪問速度,。

優(yōu)化功能-連接復(fù)用

優(yōu)化功能-TCP緩存

會話保持

會話保持-客戶端源IP會話保持

源IP地址會話保持就是將同一個源IP地址的連接或者請求認(rèn)為是同一個用戶，根據(jù)會話保持策略,，在會話保持有效期內(nèi),，將這些發(fā)自同一個源IP地址的連接/請求都轉(zhuǎn)發(fā)到同一臺服務(wù)器。

會話保持-Cookie會話保持

當(dāng)采用基于源地址的會話保持無法做到負(fù)載均分時,，例如客戶端發(fā)起連接請求的源IP地址相對固定,，發(fā)生此類問題通常可采用基于應(yīng)用層的會話保持方式,，Cookie通常是存在于HTTP頭中,，現(xiàn)如今基于HTTP的應(yīng)用被廣泛使用，因此基于Cookie的會話保持越來越多的出現(xiàn)在服務(wù)器負(fù)載均衡解決方案中,。 

局限性：

　　對于非HTTP協(xié)議,，或者客戶端禁用Cookie，無效,。

會話保持-URL哈希（Hash）會話保持

哈希會話保持的一個基本概念就是按照某個Hash因子,，根據(jù)此因子以及后臺存在多少臺服務(wù)器計算得到的結(jié)果來選擇將請求分配到那臺服務(wù)器。哈希會話保持的特點是在后臺服務(wù)器的健康狀態(tài)不發(fā)生改變的時候，每個特定的Hash因子被分配到的服務(wù)器是固定的,。其最大的優(yōu)勢是哈希會話保持可以沒有會話保持表，而僅僅是根據(jù)計算的結(jié)果來確定被分配到那臺服務(wù)器,，尤其在一些會話保持表查詢的開銷已經(jīng)遠(yuǎn)遠(yuǎn)大于Hash計算開銷的情況下,，采用Hash會話保持可以提高系統(tǒng)的處理能力和響應(yīng)速度。

　URL哈希會話保持通常針對后臺采用Cache服務(wù)器的應(yīng)用場景,，針對URL進(jìn)行Hash計算,，將同一個URL的請求分配到同一臺Cache服務(wù)器，這樣,，對后臺的Cache服務(wù)器群來說,，每臺Cache服務(wù)器上存放的內(nèi)容都是不一樣的，提高Cache服務(wù)器的利用率,。

故障案例分析

Q&A案例分析（1）-循環(huán)跳轉(zhuǎn)

故障現(xiàn)象：

　　Web服務(wù)端對用戶訪問的URL進(jìn)行判斷,，對于非https的請求，重定向到http站點,，結(jié)果導(dǎo)致用戶一直302跳轉(zhuǎn),。

原因分析：

　　采用了負(fù)載均衡SSL加速功能，在服務(wù)端看到所有的用戶請求都來自于http,。

解決方案：

　　全站啟用SSL加速,。

Q&A案例分析（2）-用戶Session丟失

故障現(xiàn)象：

　　用戶在http站點上提交數(shù)據(jù)到同域名的https站點，web程序拋出session丟失的異常,，用戶提交數(shù)據(jù)失敗,。

原因分析：

　　http和https在負(fù)載均衡設(shè)備上被認(rèn)為是2個獨立的服務(wù)，產(chǎn)生2個獨立的TCP鏈接,，會命中不同的真實服務(wù)器,，導(dǎo)致session丟失。

解決方案：

　　在負(fù)載均衡設(shè)備上啟用基于真實服務(wù)器的會話保持,。

Q&A案例分析（3）-客戶端源IP取不到

故障現(xiàn)象：

　　服務(wù)端獲取不到用戶外網(wǎng)的IP地址,，看到的都是大量來自于內(nèi)網(wǎng)特定網(wǎng)段的IP地址。

原因分析：

　　負(fù)載均衡設(shè)備啟用了用戶源地址轉(zhuǎn)換（SNAT）模式,，修改了TCP報文中的用戶源IP,。

解決方案：

　　 負(fù)載均衡設(shè)備會用用戶的外網(wǎng)IP改寫x-forwarded-for值，服務(wù)端通過獲取http協(xié)議中request header頭的x-forwarded-for值作為用戶源IP,。IIS日志通過安裝插件形式顯示用戶源IP,。

服務(wù)器負(fù)載均衡設(shè)備選型

未完待續(xù)

感興趣的可以我關(guān)注微博或博客，如果感覺不錯可以點“推薦”