負(fù)載均衡（Load Balancing） 負(fù)載均衡建立在現(xiàn)有網(wǎng)絡(luò)結(jié)構(gòu)之上，它提供了一種廉價(jià)有效透明的方法擴(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域名解析的基本過(guò)程

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

優(yōu)點(diǎn)

• 基本上無(wú)成本，因?yàn)橥蛎?cè)商的這種解析都是免費(fèi)的；
• 部署方便，除了網(wǎng)絡(luò)拓?fù)涞暮?jiǎn)單擴(kuò)增，新增的Web服務(wù)器只要增加一個(gè)公網(wǎng)IP即可

缺點(diǎn)

• 健康檢查，如果某臺(tái)服務(wù)器宕機(jī)，DNS服務(wù)器是無(wú)法知曉的，仍舊會(huì)將訪問(wèn)分配到此服務(wù)器。修改DNS記錄全部生效起碼要3-4小時(shí)，甚至更久；
• 分配不均，如果幾臺(tái)Web服務(wù)器之間的配置不同，能夠承受的壓力也就不同，但是DNS解析分配的訪問(wèn)卻是均勻分配的。用戶群的分配不均衡導(dǎo)致DNS解析的不均衡。
• 會(huì)話保持，如果是需要身份驗(yàn)證的網(wǎng)站，在不修改軟件構(gòu)架的情況下，這點(diǎn)是比較致命的，因?yàn)镈NS解析無(wú)法將驗(yàn)證用戶的訪問(wèn)持久分配到同一服務(wù)器。雖然有一定的本地DNS緩存，但是很難保證在用戶訪問(wèn)期間，本地DNS不過(guò)期，而重新查詢(xún)服務(wù)器并指向新的服務(wù)器，那么原服務(wù)器保存的用戶信息是無(wú)法被帶到新服務(wù)器的，而且可能要求被重新認(rèn)證身份，來(lái)回切換時(shí)間長(zhǎng)了各臺(tái)服務(wù)器都保存有用戶不同的信息，對(duì)服務(wù)器資源也是一種浪費(fèi)。

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

優(yōu)勢(shì)

• 數(shù)據(jù)中心冗余備份
• 多站點(diǎn)流量?jī)?yōu)化
• 確保用戶體驗(yàn)

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

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

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

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

動(dòng)態(tài)加速的特點(diǎn)

• 智能路由
• 傳輸控制協(xié)議（TCP）優(yōu)化
• HTTP預(yù)載

#p#

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

應(yīng)用背景

• 訪問(wèn)流量快速增長(zhǎng)
• 業(yè)務(wù)量不斷提高

用戶需求

• 希望獲得7×24的不間斷可用性及較快的系統(tǒng)反應(yīng)時(shí)間

負(fù)載均衡必須滿足性能、擴(kuò)展、可靠性

服務(wù)器負(fù)載均衡系統(tǒng)三種接入方式

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

• 輪詢(xún)（Round Robin）
• 加權(quán)輪詢(xún)（Weighted Round Robin）
• 最少連接（Least Connections）
• 加權(quán)最少連接（Weighted Least Connections）

健康性檢查

健康性檢查算法的目的：通過(guò)某種探針機(jī)制，檢查服務(wù)器群中真實(shí)服務(wù)器的健康情況，避免把客戶端的請(qǐng)求分發(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ù)通過(guò)具有智能壓縮能力的 BIG-IP 系統(tǒng)可縮短應(yīng)用交付時(shí)間并優(yōu)化帶寬。HTTP壓縮采用通用的壓縮算法壓縮HTML、JavaScript或CSS文件。壓縮的最大好處就是降低了網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量，從而提高客戶端瀏覽器的訪問(wèn)速度。

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

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

#p#

會(huì)話保持

會(huì)話保持-客戶端源IP會(huì)話保持

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

會(huì)話保持-Cookie會(huì)話保持

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

局限性：

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

會(huì)話保持-URL哈希（Hash）會(huì)話保持

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

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

故障案例分析

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

故障現(xiàn)象：

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

原因分析：

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

解決方案：

　　全站啟用SSL加速。

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

故障現(xiàn)象：

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

原因分析：

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

解決方案：

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

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

故障現(xiàn)象：

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

原因分析：

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

解決方案：

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

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

1.價(jià)格因素

硬件設(shè)備：F5、 Citrix 、Redware 、A10

軟件：LVS、Nginx、Haproxy、zen loadbalance

2.性能

4/7層吞吐量(單位bps)

4/7層新建連接數(shù)（單位CPS）

并發(fā)連接數(shù)

功能模塊性能指標(biāo)（ssl加速、 HTTP壓縮、內(nèi)存Cache）

3.滿足真實(shí)和未來(lái)需求

1）如果確認(rèn)負(fù)載均衡設(shè)備對(duì)所有應(yīng)用的處理都是最簡(jiǎn)單的4層處理，那么理論上選擇的負(fù)載均衡設(shè)備的4層性能稍高于實(shí)際性能需求即可。

2）如果確認(rèn)負(fù)載均衡設(shè)備對(duì)所有應(yīng)用的處理都是簡(jiǎn)單的7層處理，那么理論上選擇的負(fù)載均衡設(shè)備的7層性能稍高于實(shí)際性能需求即可。

3）如果負(fù)載均衡設(shè)備處理的應(yīng)用既有4層的也有7層的，建議按照7層應(yīng)用的性能來(lái)考慮負(fù)載均衡設(shè)備。

4）如果確認(rèn)自己的應(yīng)用經(jīng)過(guò)負(fù)載均衡處理時(shí)，需要復(fù)雜的4層或者7層處理，例如需要根據(jù)客戶端的地址做策略性分發(fā)，需要根據(jù)tcp的內(nèi)容做處理，需要根據(jù)HTTP頭或者HTTP報(bào)文做處理，那么建議選擇的負(fù)載均衡設(shè)備4/7層性能為真實(shí)性能需求的兩倍。

5）如果負(fù)載均衡設(shè)備有混合的復(fù)雜流量處理并且還開(kāi)啟了一些功能模塊，那么建議選擇的負(fù)載均衡設(shè)備4/7層性能為真實(shí)性能需求的3倍。

6）考慮到設(shè)備需要輕載運(yùn)行才能更加穩(wěn)定，所以有可能的話在以上基礎(chǔ)上再增加30%的性能。

7）如果還要滿足未來(lái)幾年的發(fā)展需求，在以上基礎(chǔ)上還要留出未來(lái)發(fā)展所需要增加的性能。

8）不同負(fù)載均衡設(shè)備廠家由于不同的架構(gòu)，使得某些設(shè)備在復(fù)雜環(huán)境下可能也表現(xiàn)的比較優(yōu)秀，這個(gè)客戶可以對(duì)比判斷，但總體來(lái)說(shuō)，以上建議適合于所有廠家的設(shè)備。

原文鏈接：http://www.cnblogs.com/and/p/3366400.html