本文將為大家介紹在windows下做7層軟負載做了一些分析，對負載這塊有興趣的你，可以來看看哦。其實所謂四層就是基於IP+端口的負載均衡;七層就是基於URL等應用層信息的負載均衡;你對7層,有了淺顯的印象吧,那大家有啥做7層軟負載的經驗可以討論分享一下呢，當然最好是Windows平台下的。
性能分析
1、對外網的連接管理和協議解析使用http.sys(HttpApi.dll,HttpListener)內置機制，http.sys在內核級別進行HTTP的連接管理和協議解析，性能應該可以保證。
2、對內網RealServer的連接管理和拼包使用HttpWebRequest的內置機制，但有如下問題
a)連接管理：默認Proxy向RealServer發送請求會新建立一個連接，收到應答後會拆除連接，也就是說Proxy和RealServer之間會建立大量連接，但是由於受端口(65535)限制，出站連接不可能太多。這個問題要想辦法解決，可以嘗試把RealServer啟用KeepAlive解決。
b)拼包：HttpListener收到包後，雖然自動已經解析成對象，但是還要把這些包重新拼成HttpWebRequest的格式發給RealServer，這裡面包括拷貝Uri,HttpHeader，CookIEs,Body等，這些數據量挺大的，在內存中拷貝一遍肯定損耗性能。該問題應該無法規避。
3、如果是常規的web應用(資源訪問類)，Request小，Response很大，RealServer返回Response時還要經過Proxy，還要進行內存拷貝，這個也非常影響性能。然後7層又做不到LVS的那種DirectRoute機制(需要修改網絡包的Mac地址)，實現IP隧道和TCP的狀態遷移需要修改操作系統的TCP/IP協議棧。鑒於代價太大，該問題也無法規避。
4、Http協議規定請求和應答必須成對出現，默認情況下一條連接上發送出去請求後要等到收到該請求對應的應答後才能發送下一個請求，雖然Http1.1有pipeline功能，可以成批發送請求，不必先等待應答，但是也有諸多限制，比如規定了POST不應該使用pipeline，一條連接上第一次發送請求也不可以使用pipeline機制，還有每批請求的請求數也不好定奪，批量發送請求後，如果連接斷開，會有多個請求失敗，等等。HTTP協議不像SIP協議那樣靠CallID和Cseq來匹配請求和應答，那樣可以純異步的收發請求和應答，所以在實現Http協議棧時要同步等待應答，然後該連接上才能發送下一批請求，這必然會影響性能。
5、HttpListener的異步接收請求和發送應答是普通的APM模式(BeginXXX,EndXXX格式)，這種異步模式在頻繁調用時會大量產生和銷毀IAsyncRequest對象，從而增加了GC的壓力，而且IAsyncRequest對象還沒有提供自定義池化的接口。如果HttpListener提供了新的基於事件的異步模式(XXXAsync(eventargs)模式，參考Socket.ReceiveAsync方法)會解決這個問題。
6、另外由於HttpLisenter是.Net的包裝類，在用戶態執行，而HTTP.SYS是內核態運行，在接受請求，返回應答會進行兩次用戶態和內核態之間的切換，從而降低性能，如果能在內核態直接進行7層轉發就好了，在Linux下LVS(KTCPVS)可以做到內核態的基於內容的7層轉發，在Windows下可能需要做TDI或者NDIS開發，查了些資料，太復雜了，所以也不考慮了先。
可靠性分析
為了容災，提高可靠性，考慮如下方案
1.7層軟負載的前面要有4層負載設備，7層軟負載多台，且共享哈希策略，4層設備按Session做隨機負載，這樣所有的7層軟負載機器均可正確處理任何一個請求，且某台7層軟負載宕機後，剩下的7層軟負載可繼續工作，由於4層負載有keepalive功能，可以檢測出哪台7層軟負載宕機了，並且不給其轉發請求。
2.7層軟負載做雙擊熱備，7層軟負載直接接入外網，正常情況下由主服務器處理請求，如果主服務器宕機，備份服務器發現後，通過ARP欺騙獲取主服務器原有IP，以把請求吸引到備份服務器上處理(硬件如果支持可能可以考慮主備機共享一個Mac地址)，主備切換時可能會造成短時請求失敗的現象。
綜合考慮，第二個方案有些山寨和不保險，優先考慮第一個方案。
