昨晚發(fā)興讀了一下《構(gòu)建高性能Web站點(diǎn)》Web負(fù)載均衡一節(jié)，好記性不如爛鍵盤，筆記梳理一遍。
最簡(jiǎn)單的負(fù)載均衡模式：HTTP重定向
對(duì)外入口服務(wù)器只有一臺(tái)，請(qǐng)求到達(dá)后根據(jù)請(qǐng)求URL內(nèi)容將該請(qǐng)求重定向到特定服務(wù)器。這種負(fù)載均衡方法的特點(diǎn)是
（1）一個(gè)請(qǐng)求實(shí)際會(huì)產(chǎn)生兩次http ping pong
（2）最大帶寬取決于入口服務(wù)器帶寬，由于入口服務(wù)器只需要處理路由信息，所以可以處理的請(qǐng)求數(shù)量可以比較高。
最適合中等規(guī)模公司的負(fù)載均衡模式：DNS負(fù)載均衡
將負(fù)載均衡的壓力交給了DNS系統(tǒng)。一個(gè)域名對(duì)應(yīng)多個(gè)IP地址。這種負(fù)載均衡的特點(diǎn)是：
（1）當(dāng)部分server故障時(shí)，只需要從DNS中將server ip移除即可。對(duì)應(yīng)用透明。
（2）選擇哪一個(gè)IP地址是DNS內(nèi)置負(fù)載均衡策略決定的，一般DNS服務(wù)商都支持RR（輪詢）策略。
（3）DNS方案淡化了主站的概念。主站被“分布式”了。
（4）如果要完全控制DNS的均衡策略，公司需要有自己的DNS服務(wù)器。bind這樣的DNS服務(wù)軟件可以提供豐富的DNS路由策略，例如根據(jù)IP選擇最近的目標(biāo)服務(wù)器IP。
（5）由于DNS緩存的存在，DNS的修改不能立即被用戶感知到（TTL的限制）。服務(wù)端故障后修改DNS記錄需要等一段時(shí)間后才能被用戶感知。這是個(gè)比較麻煩的問題，不知線上如何解決？
一種“被誤用”的負(fù)載均衡模式：反向代理負(fù)載均衡
前面講的DNS和HTTP重定向模式實(shí)現(xiàn)的是請(qǐng)求的”轉(zhuǎn)移“。反向代理要實(shí)現(xiàn)的是請(qǐng)求的”轉(zhuǎn)發(fā)“。一個(gè)請(qǐng)求到達(dá)，反向代理會(huì)根據(jù)請(qǐng)求類型自主將請(qǐng)求轉(zhuǎn)發(fā)到內(nèi)部的某個(gè)服務(wù)器上，內(nèi)部服務(wù)器完成任務(wù)后會(huì)把結(jié)構(gòu)返回給代理服務(wù)器，代理服務(wù)器將最終結(jié)果返回給用戶。不過，這種模式的確會(huì)被很多公司用到，但是用的角度不是從負(fù)載均衡出發(fā)，而是用于功能“服務(wù)化”。例如在淘寶，一個(gè)用戶請(qǐng)求到達(dá)前端”代理服務(wù)器“后，代理服務(wù)器會(huì)去并發(fā)請(qǐng)求商品、庫(kù)存、評(píng)論等多個(gè)服務(wù)器，將結(jié)果合并，然后返回給用戶。
該模式最適用的場(chǎng)景是：很消耗計(jì)算資源，但結(jié)果集很小的情況。
順便說一下的負(fù)載均衡模式：DNAT
這種模式的思路跟反向代理類似，只不過它是工作在傳輸層。它的性能也受制于網(wǎng)絡(luò)出口帶寬。
這才是王道：LVS
LVS有三種模式：LVS-NAT（Network Address Translation），LVS-DR（Direct Routing），LVS-TUN（Tunneling）
第一種NAT與上面的DNAT一樣，沒什么好說的。出口帶寬是瓶頸。
LVS-DR是最適合搭建可擴(kuò)展的負(fù)載均衡系統(tǒng)。理解LVS-DR的工作原理十分重要，否則你總會(huì)覺得這是一個(gè)魔法。
LVS-TUN也比較魔法，具體原理需要學(xué)習(xí)。
LVS-DR工作在數(shù)據(jù)鏈路層，它通過修改數(shù)據(jù)包目標(biāo)的MAC地址，將數(shù)據(jù)包轉(zhuǎn)發(fā)到實(shí)際服務(wù)器上。實(shí)際服務(wù)器處理完請(qǐng)求后直接把結(jié)果發(fā)送給客戶端。
通過MAC找到目標(biāo)服務(wù)器后，為什么目標(biāo)服務(wù)器不吃驚呢？這個(gè)包的目標(biāo)IP不是自己呀！為了解決這個(gè)問題，引入了IP別名的概念。每個(gè)服務(wù)器可以最多有256個(gè)IP別名。剛才這個(gè)服務(wù)器只要配置一個(gè)IP別名與網(wǎng)關(guān)服務(wù)器的IP一樣即可。同一個(gè)網(wǎng)段，一個(gè)IP對(duì)應(yīng)多個(gè)主機(jī)會(huì)比較混亂，不過網(wǎng)關(guān)服務(wù)器了解這個(gè)混亂的現(xiàn)狀，它與這些服務(wù)器都是通過MAC通信，所以混亂對(duì)他來說不存在。
我們不妨這么理解這個(gè)過程：網(wǎng)關(guān)服務(wù)器收到一個(gè)數(shù)據(jù)包后，查看這個(gè)包的IP地址，然后用RARP協(xié)議問內(nèi)網(wǎng)中的所有服務(wù)器，誰(shuí)的IP地址是xxx.xxxx呢。馬上有好幾個(gè)服務(wù)器應(yīng)答：是我！是我！應(yīng)答中帶著MAC地址。網(wǎng)關(guān)服務(wù)器從這些MAC中選出一個(gè)，填寫到數(shù)據(jù)包中，然后發(fā)出去。底層硬件網(wǎng)絡(luò)是通過MAC來尋址的，于是這個(gè)數(shù)據(jù)包順利的流到了目標(biāo)服務(wù)器。
為什么有了LVS-DR后還需要LVS-TUN呢？DR模式有一個(gè)要求：后端服務(wù)器與網(wǎng)管服務(wù)器必須處于同一個(gè)網(wǎng)段。這是基于MAC通信的基本要求。如果需要進(jìn)行跨網(wǎng)段的負(fù)載均衡呢？這時(shí)候就需要隧道出馬了。網(wǎng)關(guān)服務(wù)器把數(shù)據(jù)包原封不動(dòng)的包裝一下，利用普通的網(wǎng)絡(luò)協(xié)議（所有l(wèi)inux都支持的隧道協(xié)議）把這個(gè)包發(fā)給目標(biāo)網(wǎng)段的服務(wù)器，服務(wù)器收到包后會(huì)基于隧道協(xié)議把數(shù)據(jù)解出來，然后直接服務(wù)-----怎樣才能直接服務(wù)呢？！當(dāng)然了，LVS-TUN模式下的服務(wù)器也都必須支持IP別名的功能。凡是參與了服務(wù)的機(jī)器，都必須有一個(gè)與網(wǎng)管服務(wù)器IP一樣的IP別名。
在學(xué)校的時(shí)候，大家不知是否有過這種經(jīng)歷：windows彈框曰：IP沖突，局域網(wǎng)中已經(jīng)有人使用相同的IP。LVS下如何避免這個(gè)呢？需要告訴linux這個(gè)事實(shí)，遇到ARP異常的時(shí)候，just shut-up。例如：net.ipv4.conf.lo.arp_ignore = 1。具體可以參考：
http://blog.chinaunix.net/uid-24960107-id-193084.html
負(fù)載均衡的共性問題：
（1）如果需要維護(hù)連接狀態(tài)，負(fù)載均衡策略需要保證同一個(gè)客戶端請(qǐng)求總被路由到同一個(gè)服務(wù)器（或同一組共享狀態(tài)的服務(wù)器）。大中型公司解決這個(gè)問題的一般方法是客戶端（browser端）保留一個(gè)cookie，存儲(chǔ)部分常用數(shù)據(jù)，服務(wù)端采用共享存儲(chǔ)，存儲(chǔ)部分key-value，key來自cookie。
（2）真正做到“均衡”并不容易，上面只是講了負(fù)載均衡的基本方法，如何做到真的均衡，還有很多細(xì)節(jié)去解決。最完美的方式是能夠?qū)崿F(xiàn)反饋調(diào)節(jié)，動(dòng)態(tài)均衡。
聯(lián)系客服
