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

負載均衡（科普篇）

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

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

HTTP重定向

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

反向代理負載均衡

反向代理服務的核心工做主要是轉發HTTP請求，扮演了瀏覽器端和後臺Web服務器中轉的角色。由於它工做在HTTP層（應用層），也就是網絡七層結構中的第七層，所以也被稱爲「七層負載均衡」。能夠作反向代理的軟件不少，比較常見的一種是Nginx。
Nginx是一種很是靈活的反向代理軟件，能夠自由定製化轉發策略，分配服務器流量的權重等。反向代理中，常見的一個問題，就是Web服務器存儲的session數據，由於通常負載均衡的策略都是隨機分配請求的。同一個登陸用戶的請求，沒法保證必定分配到相同的Web機器上，會致使沒法找到session的問題。

解決方案主要有兩種：
1)配置反向代理的轉發規則，讓同一個用戶的請求必定落到同一臺機器上（經過分析cookie），複雜的轉發規則將會消耗更多的CPU，也增長了代理服務器的負擔。
2)將session這類的信息，專門用某個獨立服務來存儲，例如Redis/memchache，這個方案是比較推薦的。

反向代理服務，也是能夠開啓緩存的，若是開啓了，會增長反向代理的負擔，須要謹慎使用。這種負載均衡策略實現和部署很是簡單，並且性能表現也比較好。
可是，它有「單點故障」的問題，若是掛了，會帶來不少的麻煩。並且，到了後期Web服務器繼續增長，它自己可能成爲系統的瓶頸。
 

DNS負載均衡

DNS（Domain Name System）負責域名解析的服務，域名url其實是服務器的別名，實際映射是一個IP地址，解析過程，就是DNS完成域名到IP的映射。而一個域名是能夠配置成對應多個IP的。所以，DNS也就能夠做爲負載均衡服務。
這種負載均衡策略，配置簡單，性能極佳。可是，不能自由定義規則，並且，變動被映射的IP或者機器故障時很麻煩，還存在DNS生效延遲的問題。
 

CDN/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之間網絡互通便可。