Author : 岑文初
Email: wenchu.cenwc@alibaba-inc.com
Blog: http://blog.csdn.net/cenwenchu79
Date: 2009-5-26
目錄
很多時(shí)候不少做開發(fā)的同學(xué)都認(rèn)為技術(shù)更新的快，新技術(shù)、新概念層出不窮，大家樂此不疲的去跟隨著所謂的“技術(shù)趨勢(shì)”走在風(fēng)頭浪尖上，但其實(shí)往往忘記了一個(gè)最重要的問題“滿足客戶需求”。其實(shí)技術(shù)就是為滿足需求服務(wù)的，用最小的代價(jià)來滿足用戶的需求，以最簡單高效的方式來達(dá)到目標(biāo)，就是每個(gè)開發(fā)者應(yīng)該追求的。（不要因?yàn)樽约旱募軜?gòu)很簡單就臉紅拿不出手，只要你在滿足用戶當(dāng)前需求的基礎(chǔ)上對(duì)未來有所考慮，那么化繁為簡就是一種能力的表現(xiàn)）
SIP（服務(wù)集成平臺(tái)）5.7版本中對(duì)于未來多個(gè)服務(wù)提供商，多種類型的服務(wù)，在每日幾億的調(diào)用壓力下，需要找到一個(gè)解決方案：可以分流不同服務(wù)提供商的服務(wù)，分流不同類型的服務(wù)，服務(wù)隔離化來減少服務(wù)相互之間影響以及服務(wù)提供商之間的影響。
當(dāng)前SIP的前端是通過硬件F5作負(fù)載均衡，因此是無狀態(tài)無差別的服務(wù)負(fù)載，這也使得無法區(qū)分不同的服務(wù)提供商的服務(wù)請(qǐng)求和不同類型的服務(wù)請(qǐng)求，導(dǎo)致服務(wù)提供商之間的服務(wù)會(huì)產(chǎn)生相互影響（旺旺即時(shí)通信類API在峰值占用了大部分的服務(wù)處理資源，淘寶寶貝上傳類API占用了大量的帶寬）。近期還有更大的兩類API將會(huì)接入，因此尋找一個(gè)服務(wù)可分流的方案勢(shì)在必行。（當(dāng)然過去也考慮通過三級(jí)域名配置在負(fù)載均衡上來解決這些問題，但是這樣首先對(duì)于開發(fā)者來說不透明，其次也是一種比較僵化的設(shè)計(jì)方案，擴(kuò)展和維護(hù)也有一定的難度）
在過去也嘗試過Apache等Web容器自己的一些load balance特性，當(dāng)然效果不是很好，和硬件基本無法比擬，而一些專有的“軟”負(fù)載均衡方案和開源項(xiàng)目也沒有深入的去了解，因此借著這次機(jī)會(huì)，好好深入的挖一挖“軟”負(fù)載均衡。
作為互聯(lián)網(wǎng)應(yīng)用，隨時(shí)都需要做好用戶量突然增大，訪問量突然上升的準(zhǔn)備。今年熱門的詞匯“云”我就不多說了，這里就簡單說說服務(wù)器的橫向擴(kuò)展。其實(shí)和DB，文件系統(tǒng)等一樣，當(dāng)資源成為瓶頸的時(shí)候，就需要考慮如何通過擴(kuò)展或者提升資源能力來滿足用戶的需求，這就是我們常說的橫向擴(kuò)展和縱向擴(kuò)展。（對(duì)于橫向擴(kuò)展和縱向擴(kuò)展的優(yōu)劣大家應(yīng)該都很清楚了，這里也不做贅述）橫向擴(kuò)展中就會(huì)要求使用負(fù)載均衡的能力，如何根據(jù)資源能力不同以及資源在運(yùn)行期負(fù)荷動(dòng)態(tài)變化將負(fù)載合理分配是判斷負(fù)載均衡優(yōu)劣的標(biāo)準(zhǔn)。
軟件負(fù)載均衡一般通過兩種方式來實(shí)現(xiàn)：基于操作系統(tǒng)的軟負(fù)載實(shí)現(xiàn)和基于第三方應(yīng)用的軟負(fù)載實(shí)現(xiàn)。LVS就是基于Linux操作系統(tǒng)實(shí)現(xiàn)的一種軟負(fù)載，HA Proxy就是基于第三應(yīng)用實(shí)現(xiàn)的軟負(fù)載。（后面會(huì)詳細(xì)介紹這兩種方式的使用）
最早期也是最原始的軟負(fù)載均衡：“Round Robin DNS”，通過輪詢方式在DNS綁定多個(gè)IP的情況下，將用戶對(duì)于同一個(gè)域名的請(qǐng)求分配到后端不同的服務(wù)節(jié)點(diǎn)。這種方案的優(yōu)點(diǎn)：配置簡單，負(fù)載分配效率高。缺點(diǎn)：無法知曉后端服務(wù)節(jié)點(diǎn)服務(wù)情況（是否已經(jīng)停止服務(wù)），無法保證在一個(gè)Session中多次請(qǐng)求由一個(gè)服務(wù)節(jié)點(diǎn)服務(wù)，每一個(gè)節(jié)點(diǎn)都要求有一個(gè)外網(wǎng)IP。
另一種較為常見的就是基于分發(fā)器的Load balance。服務(wù)使用者通過向分發(fā)器發(fā)起請(qǐng)求獲得服務(wù)，分發(fā)器將請(qǐng)求分發(fā)給后端實(shí)際服務(wù)處理的節(jié)點(diǎn)，給客戶提供服務(wù)，最常說的反向代理模式就是典型的分發(fā)器Load Balance。這類負(fù)載均衡處理可以基于應(yīng)用級(jí)轉(zhuǎn)發(fā)，也可以基于IP級(jí)別轉(zhuǎn)發(fā)，當(dāng)然基于應(yīng)用轉(zhuǎn)發(fā)效率和損耗比較大，同時(shí)分發(fā)器本身也會(huì)成為瓶頸。
LVS是在Linux操作系統(tǒng)基礎(chǔ)上建立虛擬服務(wù)器，實(shí)現(xiàn)服務(wù)節(jié)點(diǎn)之間的負(fù)載均衡。LVS主要是處理OSI模型中的4層消息包，根據(jù)一定的規(guī)則將請(qǐng)求直接轉(zhuǎn)發(fā)到后端的服務(wù)處理節(jié)點(diǎn)，有較高轉(zhuǎn)發(fā)效率。
Virtual Server是Load Balancer和一組服務(wù)器的邏輯組合統(tǒng)稱，使用服務(wù)者只需要與Virtual Server進(jìn)行交互就可以獲得高效的服務(wù)。真實(shí)服務(wù)器和Load Balancer通過高速ＬＡＮ進(jìn)行交互。Load Balancer能夠?qū)⒄?qǐng)求分發(fā)到不同的服務(wù)端，在一個(gè)虛擬IP下并行處理多個(gè)請(qǐng)求。
Virtual Server有三種基于IP級(jí)別的負(fù)載均衡實(shí)現(xiàn)方式：IP address translation（NAT）、Direct routing、IP Tunneling。
NAT(Network address translation)：由于IPV4的某些缺陷和安全原因，某些網(wǎng)段例如（10.0.0.0/255.0.0.0, 172.16.0.0/255.240.0.0 and 192.168.0.0/255.255.0.0）不能被用于互聯(lián)網(wǎng)，因此常常被用作內(nèi)部局域網(wǎng)，通過網(wǎng)絡(luò)地址翻譯的方式可以讓這些網(wǎng)段的服務(wù)器訪問互聯(lián)網(wǎng)或者被互聯(lián)網(wǎng)訪問。網(wǎng)絡(luò)地址翻譯主要作用就是將一組ip地址映射到其他的一組ip地址，當(dāng)映射比例為1:1的時(shí)候通常稱作靜態(tài)映射，而當(dāng)映射地址為M:N(M>N)的時(shí)候（M為被映射地址數(shù)量，通常是內(nèi)部ip），則成為動(dòng)態(tài)映射。而對(duì)于Virtual Server的NAT模式來說，就是利用了NAT的特性，將內(nèi)部的一組服務(wù)器通過映射到一個(gè)虛擬的IP，然后以一個(gè)外網(wǎng)虛擬服務(wù)節(jié)點(diǎn)的身份對(duì)外提供服務(wù)。
上圖是一個(gè)實(shí)際的NAT范例，對(duì)外的服務(wù)IP為202.103.106.5，內(nèi)部建立了虛擬IP為172.16.0.1，然后將內(nèi)部其他兩臺(tái)實(shí)際服務(wù)的服務(wù)器172.16.0.2，172.16.0.3映射到172.16.0.1這個(gè)虛擬IP?？蛻舳讼?/span>202.103.106.5發(fā)起請(qǐng)求服務(wù)，Load Balancer查看請(qǐng)求數(shù)據(jù)包，如果是請(qǐng)求目標(biāo)地址是注冊(cè)的虛擬IP及監(jiān)聽端口的時(shí)候，那么通過NAT按照一定算法選擇某一臺(tái)實(shí)體服務(wù)器，再重寫報(bào)文目標(biāo)地址，轉(zhuǎn)發(fā)請(qǐng)求到實(shí)際的目標(biāo)服務(wù)器，當(dāng)目標(biāo)服務(wù)器處理完畢以后，將處理結(jié)果返回給Load Balancer，由Load Balancer修改源地址，返回給客戶端。
IP Tunneling：IP管道技術(shù)是在IP報(bào)文上再次封裝IP報(bào)文協(xié)議的一種技術(shù)。允許將一個(gè)目標(biāo)為A的IP數(shù)據(jù)報(bào)文封裝成為目標(biāo)為B的IP數(shù)據(jù)報(bào)文，在特定的IP 管道中傳輸。
上圖就是IP Tunneling模式的運(yùn)作原理。首先客戶端還是通過訪問對(duì)外的一個(gè)服務(wù)IP請(qǐng)求服務(wù)，當(dāng)Load Balancer接受到請(qǐng)求以后，檢查VIP注冊(cè)信息，然后根據(jù)算法選擇實(shí)際的一臺(tái)后臺(tái)服務(wù)器，通過IP管道封裝技術(shù)對(duì)IP報(bào)文再次封裝，然后將消息通過IP管道轉(zhuǎn)發(fā)到實(shí)際的服務(wù)器，實(shí)際的服務(wù)器通過解包處理請(qǐng)求，然后根據(jù)包體內(nèi)實(shí)際的服務(wù)請(qǐng)求地址，將處理結(jié)果直接返回給客戶端。 Direct routing：利用Load Balancer和實(shí)際服務(wù)器共享同一VIP，簡單的通過修改消息報(bào)體目標(biāo)MAC地址，轉(zhuǎn)發(fā)請(qǐng)求，然后再通過實(shí)際服務(wù)器配置VIP為本地回環(huán)，直接處理消息報(bào)文，而不再轉(zhuǎn)發(fā)，當(dāng)處理完以后，直接將處理結(jié)果返回給客戶端。
上圖就是Direct Routing的運(yùn)作流程，當(dāng)外部請(qǐng)求到Load Balancer時(shí)，通過查找VIP注冊(cè)信息，直接選擇一臺(tái)后端服務(wù)器作為新的目標(biāo)地址，修改消息報(bào)文中的目標(biāo)地址Mac地址，轉(zhuǎn)發(fā)到目標(biāo)服務(wù)器，目標(biāo)服務(wù)器由于配置VIP在本地網(wǎng)卡回路中，因此直接處理消息，將處理完的結(jié)果直接返回給客戶端。
下表是官方整理出的關(guān)于Virtual Server三種不同模式的區(qū)別：
|
| NAT | TUNNEL | DR |
| 服務(wù)器要求 | 無要求 | 需要支持IP管道 | 無 arp組件（當(dāng)前也有補(bǔ)丁） |
| 網(wǎng)絡(luò)要求 | Private | LAN/WAN | LAN |
| 可支持后端服務(wù)器節(jié)點(diǎn)數(shù) | 較少（10-20） | 較多 | 較多 |
| 服務(wù)網(wǎng)關(guān) | Load Balancer | 本身 | 本身 |
NAT：根據(jù)其實(shí)現(xiàn)原理，可以知道這種模式對(duì)于操作系統(tǒng)，網(wǎng)絡(luò)都沒有太多的要求和約束，但是由于消息需要打解包，同時(shí)消息的響應(yīng)都必須經(jīng)過Load Balancer，因此Load Balancer自身成為了瓶頸，這樣一個(gè)Load Balancer能夠支持的后端服務(wù)節(jié)點(diǎn)數(shù)量就有限了。當(dāng)然可以采用混合模式來解決這個(gè)問題，也就是通過TUNNEL或者DR模式作為前端模式串聯(lián)起多個(gè)NAT模式Balancer。
TUNNEL：這種模式要求操作系統(tǒng)支持IP Tunnel，通過對(duì)IP報(bào)文再次封裝轉(zhuǎn)發(fā)，達(dá)到負(fù)載均衡的目的。設(shè)計(jì)這種模式的初衷是考慮，對(duì)于互聯(lián)網(wǎng)很多服務(wù)來說，服務(wù)請(qǐng)求數(shù)據(jù)量和返回?cái)?shù)據(jù)量是不對(duì)稱的，返回的數(shù)據(jù)往往要遠(yuǎn)遠(yuǎn)大于請(qǐng)求的數(shù)據(jù)量，因此如果請(qǐng)求和返回都走Load Balancer會(huì)大量占用帶寬，影響處理能力。IP Tunnel設(shè)計(jì)中請(qǐng)求是通過Load Balancer，但是返回是直接返回到客戶端的，因此節(jié)省了返回的帶寬，提高了請(qǐng)求處理的能力。
DR：這種模式要求Load Balancer和后端服務(wù)器處于同一個(gè)局域網(wǎng)段。DR模式處理消耗最小，消息轉(zhuǎn)發(fā)和回復(fù)基本沒有損耗，因此效率應(yīng)該是最高的，但是約束是相對(duì)來說最多的。
聯(lián)系客服
