“

1. 為什么負載均衡一般采用混合方式
2. 七層負載為什么比四層負載性能要低？
3. 四層負載概念真的對嗎？
4. 文章較長，各位能不能持久到最后？

在正式開篇之前，先說幾個瓜：

1. 硬件負載均衡的性能最高，其次是軟件負載均衡的四層負載，最差的是七層負載，那為什么七層負載均衡反而應(yīng)用最廣泛呢？
2. 一般公司都會采用混合型的負載均衡，為什么四層負載一定要在七層負載之前呢？

說到負載均衡，目前可以說是程序員面試中的基礎(chǔ)題了，如果連負載均衡都沒搞過，B格多半會掉好幾個層級。遙想很多年前單體時代，一個玩過負載均衡的程序員可是很吃香的，出去面試算是自帶Buffer的那種。無論如何，在分布式橫行的現(xiàn)代擼碼過程中，負載均衡已然成為微服務(wù)乃至ServiceMesh中不可或缺的一部分。

負載均衡按照工程來說，都是圍繞“分”字來做的，無論是硬件負載均衡還是軟件負載均衡，最終目的都是為了提高系統(tǒng)整體的負載能力。

負載均衡分類

硬件負載均衡

典型的代表是F5，價格比較昂貴，一般中小企業(yè)不愿意采用。性價比不是F5的優(yōu)勢，F(xiàn)5有行業(yè)最全面和最領(lǐng)先的解決方案，志在為客戶提供更加安全、智能、高效的應(yīng)用服務(wù)。

硬件負載均衡獨立于實際應(yīng)用系統(tǒng)，所以它感知不到后端應(yīng)用的狀態(tài)，由于它處于網(wǎng)絡(luò)層，所以要想做到自動踢出有問題的業(yè)務(wù)服務(wù)器比較難。

優(yōu)點：能夠直接通過智能交換機實現(xiàn),處理能力更強，而且與系統(tǒng)無關(guān)，負載性能強，更適用大訪問量、大企業(yè)使用

缺點：成本高，除設(shè)備價格高昂，而且配置比較麻煩，需要專業(yè)的運維人員去搞。

軟件負載均衡

根據(jù)軟件負載均衡中均衡器所在的OSI網(wǎng)絡(luò)模型中的層次，業(yè)界把負載均衡分為了四層負載和七層負載。它們有著自己的優(yōu)勢和劣勢，下邊會詳細的講解。

優(yōu)點：基于系統(tǒng)與應(yīng)用的負載均衡，能夠更好地根據(jù)系統(tǒng)與應(yīng)用的狀況來分配負載。這對于復雜應(yīng)用是很重要的，性價比高，實際上如果幾臺服務(wù)器，用F5之類的硬件產(chǎn)品顯得有些浪費，而用軟件就要合算得多，因為服務(wù)器同時還可以跑應(yīng)用做集群等。

缺點：負載能力受服務(wù)器本身性能的影響，性能越好，負載能力越大。

四層負載

無論是四層負載均衡還是七層負載均衡，都離不開OSI七層網(wǎng)絡(luò)模型，如果你大學沒有掌握，現(xiàn)在再給你一次機會

數(shù)據(jù)鏈路層負載

通過OSI七層網(wǎng)絡(luò)模型可以知道，數(shù)據(jù)鏈路層傳輸?shù)膬?nèi)容是“幀”，數(shù)據(jù)幀的格式這里不做詳細介紹，我們只需要知道它包含了來源MAC地址和目標MAC地址，每一個MAC對應(yīng)一個網(wǎng)卡或者說對應(yīng)一臺服務(wù)器（多網(wǎng)卡的服務(wù)器除外）。

數(shù)據(jù)鏈路層負載均衡器的工作就是修改接收到的數(shù)據(jù)中的目標MAC地址，把目標MAC地址修改為真實服務(wù)器的MAC地址，修改之后，交換機會根據(jù)修改之后的MAC地址，把請求發(fā)送給真實的處理服務(wù)器，由于只修改了目標MAC地址，并沒有涉及網(wǎng)絡(luò)層數(shù)據(jù)的修改，所以上層依然可以正確的進行數(shù)據(jù)處理。

“OSI七層模型中，每一層關(guān)注的數(shù)據(jù)并不相同

在數(shù)據(jù)鏈路層只能做到修改MAC地址，這也就意味著目標機器必須要和負載均衡器能夠聯(lián)通才可以，不可以跨越網(wǎng)段，一般情況下，他們都處于同一個子網(wǎng)中。

“計算機要想正確的處理請求，數(shù)據(jù)包中的MAC和IP地址必須要和自己對應(yīng)，所以數(shù)據(jù)鏈路層負載均衡模式中，真實服務(wù)器的IP要和負載均衡器一樣才可以，這也是VIP的用武之地

數(shù)據(jù)包的返回道理類似，只要目標機器的IP和MAC正確，服務(wù)器就可以直接把數(shù)據(jù)包返回，在數(shù)據(jù)鏈路層負載中，這兩個數(shù)據(jù)并沒有被修改，所以真實服務(wù)器處理完請求就可以繞過負載均衡器而直接返回數(shù)據(jù)包，整個的流程如下：

網(wǎng)絡(luò)層負載

在OSI的網(wǎng)絡(luò)層中，數(shù)據(jù)包中最重要的包含了請求的目標IP和來源IP，和數(shù)據(jù)鏈路層道理類似，網(wǎng)絡(luò)層的負載均衡設(shè)備是通過修改目標IP來達到負載均衡的目的。交換機把請求轉(zhuǎn)發(fā)到真實服務(wù)器之后，由于IP和MAC就是當前真實服務(wù)器IP和MAC，所以數(shù)據(jù)包可以被正確處理。

但是，當應(yīng)答數(shù)據(jù)包返回的時候就有問題了，由于數(shù)據(jù)包目標IP被修改為了真實服務(wù)器IP（原來為負載均衡器的IP），如果直接返回給來客戶端服務(wù)器，數(shù)據(jù)包將不會得到處理。因此，只能將應(yīng)答數(shù)據(jù)包重新發(fā)回負載均衡器，負載均衡器把應(yīng)答IP修改為自己的IP再發(fā)回客戶端服務(wù)器，這樣才可以保證和客戶端服務(wù)器的正常通信。

相比較數(shù)據(jù)鏈路層負載來說，通過修改來源IP方式的負載均衡方式性能是比較低的，因為數(shù)據(jù)包的返回需要再次經(jīng)過負載均衡器，這不僅使負載均衡器的工作量增加，而且占用了更多的出口帶寬。

“其實還有一種數(shù)據(jù)包二次包裝的方式來實現(xiàn)網(wǎng)絡(luò)層負載均衡，負載均衡器在真實的數(shù)據(jù)包外層又增加了一層數(shù)據(jù)包，然后發(fā)往真實處理服務(wù)器，有興趣的同學可以研究一下“IP隧道”

七層負載

四層負載均衡通過直接修改數(shù)據(jù)包的方式來達到負載均衡功能，此時，客戶端和真實應(yīng)用服務(wù)器本質(zhì)上維持著同一條TCP通道，或者說，OSI模型的下三層的數(shù)據(jù)包還未到達真實服務(wù)器。

當數(shù)據(jù)包一旦到達真實服務(wù)器，也就是OSI是上四層，數(shù)據(jù)包的MAC和IP地址就無法被修改了。所以基于七層的負載均衡器只能通過代理的方式把數(shù)據(jù)包發(fā)送給后端真實的服務(wù)器，這個過程會新建TCP連接，這也是七層負載均衡性能要比四層負載均衡器性能要低的重要原因。

而且，由于七層負載均衡器，無法修改IP和MAC信息，所以應(yīng)答數(shù)據(jù)包只能通過再次返回負載均衡器的方式來應(yīng)答客戶端服務(wù)器，這同樣會降低負載均衡器的性能以及占用出口帶寬問題。

由于七層負載均衡器工作在應(yīng)用層，它能夠明確的感知應(yīng)用層的協(xié)議內(nèi)容，比如最常見的Http協(xié)議。這樣就可以根據(jù)協(xié)議的具體內(nèi)容來實現(xiàn)更加靈活的控制規(guī)則，像Nginx最常見的Session粘性規(guī)則，或者對資源的緩存等。

負載均衡策略

DNS響應(yīng)均衡（Flash DNS）

在Internet上，無論是HTTP、FTP或是其它的服務(wù)請求，客戶端一般都是通過域名解析來找到服務(wù)器確切的IP地址的。在此均衡算法下，分處在不同地理位置的負載均衡設(shè)備收到同一個客戶端的域名解析請求，并在同一時間內(nèi)把此域名解析成各自相對應(yīng)服務(wù)器的IP地址（即與此負載均衡設(shè)備在同一位地理位置的服務(wù)器的IP地址）并返回給客戶端，則客戶端將以最先收到的域名解析IP地址來繼續(xù)請求服務(wù)，而忽略其它的IP地址響應(yīng)。在種均衡策略適合應(yīng)用在全局負載均衡的情況下，對本地負載均衡是沒有意義的。

輪循均衡（Round Robin）

這是最簡單的一種負載均衡策略，每次網(wǎng)絡(luò)請求都會依次分配給后端服務(wù)器，即：第一個請求分配給第一臺服務(wù)器，第二個請求分配給第二臺服務(wù)器，以此類推，然后不斷重復循環(huán)。

如果后端服務(wù)器配置不盡相同，可能會造成有的服務(wù)器負載過高或者負載過低的現(xiàn)象。

權(quán)重輪循均衡（Weighted Round Robin）

此策略在輪訓的基礎(chǔ)上增加了權(quán)重的概念，根據(jù)服務(wù)器的處理能力分配不同的權(quán)重，處理能力強的權(quán)重會高一些，處理能力低的權(quán)重會低一些，這在一定程度上平衡了服務(wù)器處理能力，也很好的提高了服務(wù)器的利用率，盡量避免了造成服務(wù)器負載過高或過低的極端情況。

隨機均衡（Random）

說實話，這種策略不提也罷，我覺得沒有任何意義，本質(zhì)上和輪訓策略沒有什么不同。

一致性哈希均衡（Consistency Hash）

一致性哈希策略其實是一種比較重要的規(guī)則，負載均衡器可以根據(jù)請求中的某些數(shù)據(jù)特征保證同樣的請求會分配給同樣的處理服務(wù)器，也就是會話粘性。最常見的，我們在nginx中利用此策略來實現(xiàn)Session機制，可以保證同一個用戶的請求被分配到同一臺服務(wù)器上，這種一致性的結(jié)果，就可以做很多事情了，完全可以玩出進程內(nèi)緩存的花樣。

響應(yīng)速度均衡（Response Time）

響應(yīng)速度策略是依據(jù)負載均衡器和真實服務(wù)器之間的響應(yīng)時間來確定的，這種策略理論上可以自動踢出有故障的服務(wù)器，因為服務(wù)器超時或者無響應(yīng)，負載均衡器將不會分配請求到此服務(wù)器。

最少連接數(shù)均衡（Least Connection）

這種方式可以保證每臺真實服務(wù)器的連接均衡，站在連接數(shù)的維度來說，這才是真正的均衡，但是會造成不同配置的服務(wù)器的過高或者過低負載的現(xiàn)象發(fā)生。

故障探測

一個好的負載均衡器一定會有自動故障探測功能，即：當后端服務(wù)器發(fā)生問題或者down機的時候，會自動剔除有問題的服務(wù)器。一般主流的探測方式有以下幾種：

1. Ping偵測：通過ping的方式檢測服務(wù)器及網(wǎng)絡(luò)系統(tǒng)狀況，此種方式簡單快速，但只能大致檢測出網(wǎng)絡(luò)及服務(wù)器上的操作系統(tǒng)是否正常，對服務(wù)器上的應(yīng)用服務(wù)檢測就無能為力了。
2. TCP Open偵測：每個服務(wù)都會開放某個通過TCP連接，檢測服務(wù)器上某個TCP端口（如Telnet的23口，HTTP的80口等）是否開放來判斷服務(wù)是否正常。
3. HTTP URL偵測：比如向HTTP服務(wù)器發(fā)出一個對main.html文件的訪問請求，如果收到錯誤信息，則認為服務(wù)器出現(xiàn)故障。

寫在最后

負載均衡已經(jīng)成為了分布式中不可或缺的基礎(chǔ)設(shè)施，基于四層負載的高性能和七層負載的高靈活性，很多公司都是采用混合型負載均衡，流量的入口處為四層負載，有的甚至有多層四層負載，四層負載之后是七層負載，然后是真實服務(wù)器。例如最常用的部署架構(gòu)為：四層的LVS 七層Nginx 真實服務(wù)器，這也是為了把每層的負載均衡的優(yōu)勢最大化的一種體現(xiàn)。