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