?
?
負載均衡（Load Balancing），簡單地說就是將多臺服務器組成一個服務器集群,然後根據我們設置的規則給服務器集群分配“工作任務”。
?
典型的互聯網應用的拓撲結構

?
負載均衡的多種解決方案：

HTTP重定向

當用戶發來請求的時候，Web服務器通過修改HTTP響應頭中的Location標記來返回一個新的url，然後瀏覽器再繼續請求這個新url，實際上就是頁面重定向。
通過重定向，來達到“負載均衡”的目標。例如，我們在下載PHP源碼包的時候，點擊下載鏈接時，為了解決不同國家和地域下載速度的問題，它會返回一個離我們近的下載地址。重定向的HTTP返回碼是302
這個重定向非常容易實現，並且可以自定義各種策略。但是，它在大規模訪問量下，性能不佳。而且，給用戶的體驗也不好，實際請求發生重定向，增加了網絡延時。

反向代理負載均衡

反向代理服務的核心工作主要是轉發HTTP請求，扮演了瀏覽器端和後臺Web服務器中轉的角色。因為它工作在HTTP層（應用層），也就是網絡七層結構中的第七層，因此也被稱為“七層負載均衡”。可以做反向代理的軟件很多，比較常見的一種是Nginx。
Nginx是一種非常靈活的反向代理軟件，可以自由定制化轉發策略，分配服務器流量的權重等。反向代理中，常見的一個問題，就是Web服務器存儲的session數據，因為一般負載均衡的策略都是隨機分配請求的。同一個登錄用戶的請求，無法保證一定分配到相同的Web機器上，會導致無法找到session的問題。

解決方案主要有兩種：
1)配置反向代理的轉發規則，讓同一個用戶的請求一定落到同一臺機器上（通過分析cookie），復雜的轉發規則將會消耗更多的CPU，也增加了代理服務器的負擔。

反向代理服務，也是可以開啟緩存的，如果開啟了，會增加反向代理的負擔，需要謹慎使用。這種負載均衡策略實現和部署非常簡單，而且性能表現也比較好。
但是，它有“單點故障”的問題，如果掛了，會帶來很多的麻煩。而且，到了後期Web服務器繼續增加，它本身可能成為系統的瓶頸。
?

DNS負載均衡

DNS（Domain Name System）負責域名解析的服務，域名url實際上是服務器的別名，實際映射是一個IP地址，解析過程，就是DNS完成域名到IP的映射。而一個域名是可以配置成對應多個IP的。因此，DNS也就可以作為負載均衡服務。

DNS/GSLB負載均衡

我們常用的CDN（Content Delivery Network，內容分發網絡）實現方式，其實就是在同一個域名映射為多IP的基礎上更進一步，通過GSLB（Global Server Load Balance，全局負載均衡）按照指定規則映射域名的IP。
一般情況下都是按照地理位置，將離用戶近的IP返回給用戶，減少網絡傳輸中的路由節點之間的跳躍消耗。

CDN在Web系統中，一般情況下是用來解決較大的靜態資源（html/Js/Css/圖片/視頻/文件等）的加載問題，讓這些比較依賴網絡下載的內容，盡可能離用戶更近，提升用戶體驗。
這種方式，和前面的DNS負載均衡一樣，性能極佳，而且支持配置多種策略。但是，搭建和維護成本非常高。互聯網一線公司，會自建CDN服務，中小型公司一般使用第三方提供的CDN。

IP負載均衡

IP負載均衡服務是工作在網絡層（修改IP）和傳輸層（修改端口，第四層），比起工作在應用層（第七層）性能要高出非常多。
原理是，他是對IP層的數據包的IP地址和端口信息進行修改，達到負載均衡的目的。這種方式，也被稱為“四層負載均衡”。
常見的負載均衡方式，是LVS，通過IPVS（IP Virtual Server，IP虛擬服務）來實現。

LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務器，是一個虛擬的服務器集群系統。

?
這個項目在1998年5月由章文嵩博士成立，是中國國內最早出現的自由軟件項目之一。
?

Lvs 提供幾種負載均衡集群機制：

?

DR模式  直接路由模式
NAT模式 網絡地址轉換模式
TUN模式 隧道模式
FULLNAT模式 

LB 負載均衡（Load Balance） 
RS 真實服務器（Real Server）  

?

1.DR模式（Direct Routing）

　　DR模式下，客戶端的請求包到達負載均衡器的虛擬服務IP端口後，負載均衡器不會改寫請求包的IP和端口，但是會改寫請求包的MAC地址為後端RS的MAC地址，然後將數據包轉發；真實服務器處理請求後，響應包直接回給客戶端，不再經過負載均衡器。所以DR模式的轉發效率是最高的，特別適合下行流量較大的業務場景，比如請求視頻等大文件。
?
　　DR模式的特點：
數據包在LB轉發過程中，源/目的IP端口都不會變化
　　LB只是將數據包的MAC地址改寫為RS的MAC地址，然後轉發給相應的RS。
?
每臺RS上都必須在環回網卡上綁定LB的虛擬服務IP
　　因為LB轉發時並不會改寫數據包的目的IP，所以RS收到的數據包的目的IP仍是LB的虛擬服務IP。為了保證RS能夠正確處理該數據包，而不是丟棄，必須在RS的環回網卡上綁定LB的虛擬服務IP。這樣RS會認為這個虛擬服務IP是自己的IP，自己是能夠處理這個數據包的。否則RS會直接丟棄該數據包！
?
RS上的業務進程必須監聽在環回網卡的虛擬服務IP上，且端口必須和LB上的虛擬服務端口一致
　　因為LB不會改寫數據包的目的端口，所以RS服務的監聽端口必須和虛擬服務端口一致，否則RS會直接拒絕該數據包。
?
RS處理完請求後，響應直接回給客戶端，不再經過LB
　　因為RS收到的請求數據包的源IP是客戶端的IP，所以理所當然RS的響應會直接回給客戶端，而不會再經過LB。這時候要求RS和客戶端之間的網絡是可達的。
?
LB和RS須位於同一個子網
　　因為LB在轉發過程中需要改寫數據包的MAC為RS的MAC地址，所以要能夠查詢到RS的MAC。而要獲取到RS的MAC，則需要保證二者位於一個子網，否則LB只能獲取到RS網關的MAC地址。

?

2.NAT模式（Network Address Translation）

　　NAT模式下，請求包和響應包都需要經過LB處理。當客戶端的請求到達虛擬服務後，LB會對請求包做目的地址轉換（DNAT），將請求包的目的IP改寫為RS的IP。當收到RS的響應後，LB會對響應包做源地址轉換（SNAT），將響應包的源IP改寫為LB的IP。

?
　　NAT模式的特點：

LB會修改數據包的地址
　　對於請求包，會進行DNAT；對於響應包，會進行SNAT。
?
LB會透傳客戶端IP到RS（DR模式也會透傳）
　　雖然LB在轉發過程中做了NAT轉換，但是因為只是做了部分地址轉發，所以RS收到的請求包裏是能看到客戶端IP的。
?
需要將RS的默認網關地址配置為LB的浮動IP地址
　　因為RS收到的請求包源IP是客戶端的IP，為了保證響應包在返回時能走到LB上面，所以需要將RS的默認網關地址配置為LB的虛擬服務IP地址。當然，如果客戶端的IP是固定的，也可以在RS上添加明細路由指向LB的虛擬服務IP，不用改默認網關。
?
LB和RS須位於同一個子網，並且客戶端不能和LB/RS位於同一子網
　　因為需要將RS的默認網關配置為LB的虛擬服務IP地址，所以需要保證LB和RS位於同一子網。
?
　　又因為需要保證RS的響應包能走回到LB上，則客戶端不能和RS位於同一子網。否則RS直接就能獲取到客戶端的MAC，響應包就直接回給客戶端了，不會走網關，也就走不到LB上面了。這時候由於沒有LB做SNAT，客戶端收到的響應包源IP是RS的IP，而客戶端的請求包目的IP是LB的虛擬服務IP，這時候客戶端無法識別響應包，會直接丟棄。
?

3.TUN模式 (tunnel)

　　采用NAT模式時，由於請求和響應的報文必須通過調度器地址重寫，當客戶請求越來越多時，調度器處理能力將成為瓶頸。
為了解決這個問題，調度器把請求的報文通過IP隧道轉發到真實的服務器。真實的服務器將響應處理後的數據直接返回給客戶端。
這樣調度器就只處理 入站請求報文，由於一般網絡服務應答數據比請求報文大很多，采用TUN模式後，集群系統的最大吞吐量可以提高10倍。
　　?
　　TUN和NAT模式不同的是，它在LB和RS之間的傳輸不用改寫IP地址。而是把客戶請求包封裝在一個IP tunnel裏面，然後發送給RS節點服務器，節點服務器接收到之後解開IP tunnel後，進行響應處理。
並且直接把包發送給客戶端，不用經過LB服務器。
?

4.FULLNAT模式

FULLNAT模式
　　FULLNAT模式下，LB會對請求包和響應包都做SNAT+DNAT。
?
　　FULLNAT模式的特點：

LB完全作為一個代理服務器
　　FULLNAT下，客戶端感知不到RS，RS也感知不到客戶端，它們都只能看到LB。此種模式和七層負載均衡有點相似，只不過不會去解析應用層協議，而是在TCP層將消息轉發
LB和RS對於組網結構沒有要求
　　不同於NAT和DR要求LB和RS位於一個子網，FULLNAT對於組網結構沒有要求。只需要保證客戶端和LB、LB和RS之間網絡互通即可。

負載均衡 （一） 工作模式以及工作原理