我把負載均衡講出了花，領導卻不給我漲工資
[導讀]“為什么負載均衡一般采用混合方式七層負載為什么比四層負載性能要低？四層負載概念真的對嗎？文章較長，各位能不能持久到最后？image在正式開篇之前，先說幾個瓜：硬件負載均衡的性能最高，其次是軟件負載均衡的四層負載，最差的是七層負載，那為什么七層負載均衡反而應用最廣泛呢？一般公司都會...
“
- 為什么負載均衡一般采用混合方式
- 七層負載為什么比四層負載性能要低？
- 四層負載概念真的對嗎？
- 文章較長，各位能不能持久到最后？
- 硬件負載均衡的性能最高，其次是軟件負載均衡的四層負載，最差的是七層負載，那為什么
七層負載均衡反而應用最廣泛呢？ - 一般公司都會采用混合型的負載均衡，為什么
四層負載一定要在七層負載之前呢？
提高系統(tǒng)整體的負載能力。負載均衡分類
硬件負載均衡
典型的代表是F5，價格比較昂貴，一般中小企業(yè)不愿意采用。性價比不是F5的優(yōu)勢，F(xiàn)5有行業(yè)最全面和最領先的解決方案，志在為客戶提供更加安全、智能、高效的應用服務。硬件負載均衡獨立于實際應用系統(tǒng)，所以它感知不到后端應用的狀態(tài)，由于它處于網(wǎng)絡層，所以要想做到自動踢出有問題的業(yè)務服務器比較難。優(yōu)點：能夠直接通過智能交換機實現(xiàn),處理能力更強，而且與系統(tǒng)無關，負載性能強，更適用大訪問量、大企業(yè)使用缺點：成本高，除設備價格高昂，而且配置比較麻煩，需要專業(yè)的運維人員去搞。軟件負載均衡
根據(jù)軟件負載均衡中均衡器所在的OSI網(wǎng)絡模型中的層次，業(yè)界把負載均衡分為了四層負載和七層負載。它們有著自己的優(yōu)勢和劣勢，下邊會詳細的講解。優(yōu)點：基于系統(tǒng)與應用的負載均衡，能夠更好地根據(jù)系統(tǒng)與應用的狀況來分配負載。這對于復雜應用是很重要的，性價比高，實際上如果幾臺服務器，用F5之類的硬件產(chǎn)品顯得有些浪費，而用軟件就要合算得多，因為服務器同時還可以跑應用做集群等。缺點：負載能力受服務器本身性能的影響，性能越好，負載能力越大。四層負載
無論是四層負載均衡還是七層負載均衡，都離不開OSI七層網(wǎng)絡模型，如果你大學沒有掌握，現(xiàn)在再給你一次機會數(shù)據(jù)鏈路層負載
通過OSI七層網(wǎng)絡模型可以知道，數(shù)據(jù)鏈路層傳輸?shù)膬热菔恰皫?，?shù)據(jù)幀的格式這里不做詳細介紹，我們只需要知道它包含了來源MAC地址和目標MAC地址，每一個MAC對應一個網(wǎng)卡或者說對應一臺服務器（多網(wǎng)卡的服務器除外）。數(shù)據(jù)鏈路層負載均衡器的工作就是修改接收到的數(shù)據(jù)中的目標MAC地址，把目標MAC地址修改為真實服務器的MAC地址，修改之后，交換機會根據(jù)修改之后的MAC地址，把請求發(fā)送給真實的處理服務器，由于只修改了目標MAC地址，并沒有涉及網(wǎng)絡層數(shù)據(jù)的修改，所以上層依然可以正確的進行數(shù)據(jù)處理。“OSI七層模型中，每一層關注的數(shù)據(jù)并不相同在數(shù)據(jù)鏈路層
只能做到修改MAC地址，這也就意味著目標機器必須要和負載均衡器能夠聯(lián)通才可以，不可以跨越網(wǎng)段，一般情況下，他們都處于同一個子網(wǎng)中。“計算機要想正確的處理請求，數(shù)據(jù)包中的MAC和IP地址必須要和自己對應，所以數(shù)據(jù)鏈路層負載均衡模式中，真實服務器的IP要和負載均衡器一樣才可以，這也是VIP的用武之地數(shù)據(jù)包的返回道理類似，只要目標機器的IP和MAC正確，服務器就可以直接把數(shù)據(jù)包返回，在數(shù)據(jù)鏈路層負載中，這兩個數(shù)據(jù)并沒有被修改，所以真實服務器處理完請求就可以繞過負載均衡器而直接返回數(shù)據(jù)包，整個的流程如下：網(wǎng)絡層負載
在OSI的網(wǎng)絡層中，數(shù)據(jù)包中最重要的包含了請求的目標IP和來源IP，和數(shù)據(jù)鏈路層道理類似，網(wǎng)絡層的負載均衡設備是通過修改目標IP來達到負載均衡的目的。交換機把請求轉發(fā)到真實服務器之后，由于IP和MAC就是當前真實服務器IP和MAC，所以數(shù)據(jù)包可以被正確處理。但是，當應答數(shù)據(jù)包返回的時候就有問題了，由于數(shù)據(jù)包目標IP被修改為了真實服務器IP（原來為負載均衡器的IP），如果直接返回給來客戶端服務器，數(shù)據(jù)包將不會得到處理。因此，只能將應答數(shù)據(jù)包重新發(fā)回負載均衡器，負載均衡器把應答IP修改為自己的IP再發(fā)回客戶端服務器，這樣才可以保證和客戶端服務器的正常通信。相比較數(shù)據(jù)鏈路層負載來說，通過修改來源IP方式的負載均衡方式性能是比較低的，因為數(shù)據(jù)包的返回需要再次經(jīng)過負載均衡器，這不僅使負載均衡器的工作量增加，而且占用了更多的出口帶寬。“其實還有一種數(shù)據(jù)包二次包裝的方式來實現(xiàn)網(wǎng)絡層負載均衡，負載均衡器在真實的數(shù)據(jù)包外層又增加了一層數(shù)據(jù)包，然后發(fā)往真實處理服務器，有興趣的同學可以研究一下“IP隧道”
七層負載
四層負載均衡通過直接修改數(shù)據(jù)包的方式來達到負載均衡功能，此時，客戶端和真實應用服務器本質上維持著同一條TCP通道，或者說，OSI模型的下三層的數(shù)據(jù)包還未到達真實服務器。當數(shù)據(jù)包一旦到達真實服務器，也就是OSI是上四層，數(shù)據(jù)包的MAC和IP地址就無法被修改了。所以基于七層的負載均衡器只能通過代理的方式把數(shù)據(jù)包發(fā)送給后端真實的服務器，這個過程會新建TCP連接，這也是七層負載均衡性能要比四層負載均衡器性能要低的重要原因。而且，由于七層負載均衡器，無法修改IP和MAC信息，所以應答數(shù)據(jù)包只能通過再次返回負載均衡器的方式來應答客戶端服務器，這同樣會降低負載均衡器的性能以及占用出口帶寬問題。由于七層負載均衡器工作在應用層，它能夠明確的感知應用層的協(xié)議內容，比如最常見的Http協(xié)議。這樣就可以根據(jù)協(xié)議的具體內容來實現(xiàn)更加靈活的控制規(guī)則，像Nginx最常見的Session粘性規(guī)則，或者對資源的緩存等。負載均衡策略
DNS響應均衡（Flash DNS）
在Internet上，無論是HTTP、FTP或是其它的服務請求，客戶端一般都是通過域名解析來找到服務器確切的IP地址的。在此均衡算法下，分處在不同地理位置的負載均衡設備收到同一個客戶端的域名解析請求，并在同一時間內把此域名解析成各自相對應服務器的IP地址（即與此負載均衡設備在同一位地理位置的服務器的IP地址）并返回給客戶端，則客戶端將以最先收到的域名解析IP地址來繼續(xù)請求服務，而忽略其它的IP地址響應。在種均衡策略適合應用在全局負載均衡的情況下，對本地負載均衡是沒有意義的。輪循均衡（Round Robin）
這是最簡單的一種負載均衡策略，每次網(wǎng)絡請求都會依次分配給后端服務器，即：第一個請求分配給第一臺服務器，第二個請求分配給第二臺服務器，以此類推，然后不斷重復循環(huán)。如果后端服務器配置不盡相同，可能會造成有的服務器負載過高或者負載過低的現(xiàn)象。權重輪循均衡（Weighted Round Robin）
此策略在輪訓的基礎上增加了權重的概念，根據(jù)服務器的處理能力分配不同的權重，處理能力強的權重會高一些，處理能力低的權重會低一些，這在一定程度上平衡了服務器處理能力，也很好的提高了服務器的利用率，盡量避免了造成服務器負載過高或過低的極端情況。隨機均衡（Random）
說實話，這種策略不提也罷，我覺得沒有任何意義，本質上和輪訓策略沒有什么不同。一致性哈希均衡（Consistency Hash）
一致性哈希策略其實是一種比較重要的規(guī)則，負載均衡器可以根據(jù)請求中的某些數(shù)據(jù)特征保證同樣的請求會分配給同樣的處理服務器，也就是會話粘性。最常見的，我們在nginx中利用此策略來實現(xiàn)Session機制，可以保證同一個用戶的請求被分配到同一臺服務器上，這種一致性的結果，就可以做很多事情了，完全可以玩出進程內緩存的花樣。響應速度均衡（Response Time）
響應速度策略是依據(jù)負載均衡器和真實服務器之間的響應時間來確定的，這種策略理論上可以自動踢出有故障的服務器，因為服務器超時或者無響應，負載均衡器將不會分配請求到此服務器。最少連接數(shù)均衡（Least Connection）
這種方式可以保證每臺真實服務器的連接均衡，站在連接數(shù)的維度來說，這才是真正的均衡，但是會造成不同配置的服務器的過高或者過低負載的現(xiàn)象發(fā)生。故障探測
一個好的負載均衡器一定會有自動故障探測功能，即：當后端服務器發(fā)生問題或者down機的時候，會自動剔除有問題的服務器。一般主流的探測方式有以下幾種：- Ping偵測：通過ping的方式檢測服務器及網(wǎng)絡系統(tǒng)狀況，此種方式簡單快速，但只能大致檢測出網(wǎng)絡及服務器上的操作系統(tǒng)是否正常，對服務器上的應用服務檢測就無能為力了。
- TCP Open偵測：每個服務都會開放某個通過TCP連接，檢測服務器上某個TCP端口（如Telnet的23口，HTTP的80口等）是否開放來判斷服務是否正常。
- HTTP URL偵測：比如向HTTP服務器發(fā)出一個對main.html文件的訪問請求，如果收到錯誤信息，則認為服務器出現(xiàn)故障。
下載文檔
