Windows下做7層軟負(fù)載的經(jīng)驗(yàn)分享

　　本文將為大家介紹在windows下做7層軟負(fù)載做了一些分析，對(duì)負(fù)載這塊有興趣的你，可以來看看哦。其實(shí)所謂四層就是基于IP+端口的負(fù)載均衡;七層就是基于URL等應(yīng)用層信息的負(fù)載均衡;你對(duì)7層,有了淺顯的印象吧,那大家有啥做7層軟負(fù)載的經(jīng)驗(yàn)可以討論分享一下呢，當(dāng)然最好是windows平臺(tái)下的。

　　性能分析

　　1、 對(duì)外網(wǎng)的連接管理和協(xié)議解析使用http.sys(HttpApi.dll,HttpListener)內(nèi)置機(jī)制，http.sys在內(nèi)核級(jí)別進(jìn)行HTTP的連接管理和協(xié)議解析，性能應(yīng)該可以保證。

　　2、 對(duì)內(nèi)網(wǎng)RealServer的連接管理和拼包使用HttpWebRequest的內(nèi)置機(jī)制，但有如下問題

　　a) 連接管理：默認(rèn)Proxy向RealServer發(fā)送請(qǐng)求會(huì)新建立一個(gè)連接，收到應(yīng)答后會(huì)拆除連接，也就是說Proxy和RealServer之間會(huì)建立大量連接，但是由于受端口(65535)限制，出站連接不可能太多。這個(gè)問題要想辦法解決，可以嘗試把RealServer啟用KeepAlive解決。

　　b) 拼包：HttpListener收到包后，雖然自動(dòng)已經(jīng)解析成對(duì)象，但是還要把這些包重新拼成HttpWebRequest的格式發(fā)給 RealServer，這里面包括拷貝Uri,HttpHeader，Cookies,Body等，這些數(shù)據(jù)量挺大的，在內(nèi)存中拷貝一遍肯定損耗性能。該問題應(yīng)該無法規(guī)避。

　　3、如果是常規(guī)的web應(yīng)用(資源訪問類)，Request小，Response很大，RealServer返回Response時(shí)還要經(jīng)過Proxy，還要進(jìn)行內(nèi)存拷貝，這個(gè)也非常影響性能。然后7層又做不到LVS的那種DirectRoute機(jī)制(需要修改網(wǎng)絡(luò)包的mac地址)，實(shí)現(xiàn)IP隧道和TCP的狀態(tài)遷移需要修改操作系統(tǒng)的TCP/IP協(xié)議棧。鑒于代價(jià)太大，該問題也無法規(guī)避。

　　4、 Http協(xié)議規(guī)定請(qǐng)求和應(yīng)答必須成對(duì)出現(xiàn)，默認(rèn)情況下一條連接上發(fā)送出去請(qǐng)求后要等到收到該請(qǐng)求對(duì)應(yīng)的應(yīng)答后才能發(fā)送下一個(gè)請(qǐng)求，雖然Http1.1有 pipeline功能，可以成批發(fā)送請(qǐng)求，不必先等待應(yīng)答，但是也有諸多限制，比如規(guī)定了POST不應(yīng)該使用pipeline，一條連接上第一次發(fā)送請(qǐng)求也不可以使用pipeline機(jī)制，還有每批請(qǐng)求的請(qǐng)求數(shù)也不好定奪，批量發(fā)送請(qǐng)求后，如果連接斷開，會(huì)有多個(gè)請(qǐng)求失敗，等等。HTTP協(xié)議不像SIP協(xié)議那樣靠CallID和Cseq來匹配請(qǐng)求和應(yīng)答，那樣可以純異步的收發(fā)請(qǐng)求和應(yīng)答，所以在實(shí)現(xiàn)Http協(xié)議棧時(shí)要同步等待應(yīng)答，然后該連接上才能發(fā)送下一批請(qǐng)求，這必然會(huì)影響性能。

　　5、 HttpListener的異步接收請(qǐng)求和發(fā)送應(yīng)答是普通的APM模式(BeginXXX,EndXXX格式)，這種異步模式在頻繁調(diào)用時(shí)會(huì)大量產(chǎn)生和銷毀IAsyncRequest對(duì)象，從而增加了GC的壓力，而且IAsyncRequest對(duì)象還沒有提供自定義池化的接口。如果 HttpListener提供了新的基于事件的異步模式(XXXAsync(eventargs)模式，參考Socket.ReceiveAsync方法)會(huì)解決這個(gè)問題。

　　6、另外由于HttpLisenter是.net的包裝類，在用戶態(tài)執(zhí)行，而HTTP.SYS是內(nèi)核態(tài)運(yùn)行，在接受請(qǐng)求，返回應(yīng)答會(huì)進(jìn)行兩次用戶態(tài)和內(nèi)核態(tài)之間的切換，從而降低性能，如果能在內(nèi)核態(tài)直接進(jìn)行7層轉(zhuǎn)發(fā)就好了，在linux下LVS(KTCPVS)可以做到內(nèi)核態(tài)的基于內(nèi)容的7層轉(zhuǎn)發(fā)，在 windows下可能需要做TDI或者NDIS開發(fā)，查了些資料，太復(fù)雜了，所以也不考慮了先。

　　可靠性分析

　　為了容災(zāi)，提高可靠性，考慮如下方案

　　1. 7層軟負(fù)載的前面要有4層負(fù)載設(shè)備，7層軟負(fù)載多臺(tái)，且共享哈希策略，4層設(shè)備按Session做隨機(jī)負(fù)載，這樣所有的7層軟負(fù)載機(jī)器均可正確處理任何一個(gè)請(qǐng)求，且某臺(tái)7層軟負(fù)載宕機(jī)后，剩下的7層軟負(fù)載可繼續(xù)工作，由于4層負(fù)載有keepalive功能，可以檢測(cè)出哪臺(tái)7層軟負(fù)載宕機(jī)了，并且不給其轉(zhuǎn)發(fā)請(qǐng)求。

　　2. 7層軟負(fù)載做雙擊熱備，7層軟負(fù)載直接接入外網(wǎng)，正常情況下由主服務(wù)器處理請(qǐng)求，如果主服務(wù)器宕機(jī)，備份服務(wù)器發(fā)現(xiàn)后，通過ARP欺騙獲取主服務(wù)器原有 IP，以把請(qǐng)求吸引到備份服務(wù)器上處理(硬件如果支持可能可以考慮主備機(jī)共享一個(gè)MAC地址)，主備切換時(shí)可能會(huì)造成短時(shí)請(qǐng)求失敗的現(xiàn)象。

　　綜合考慮，第二個(gè)方案有些山寨和不保險(xiǎn)，優(yōu)先考慮第一個(gè)方案。