分佈式系統中很常見的負載均衡方案


HTTP 重定向負載均衡


分佈式系統中很常見的負載均衡方案

這種負載均衡方式僅適合WEB 服務器。

用戶發出請求時,負載均衡服務器會根據HTTP請求,重新計算出實際的WEB服務器地址,通過302重定向響應發送給用戶瀏覽器。用戶瀏覽器再根據302響應信息,對實際的WEB服務器發出請求。

HTTP重定向方案優點是比較簡單,缺點是性能比較差,需要2次請求才能返回實際結果,還有就是僅適合HTTP服務器使用。重定向服務器也很容易成為單點故障問題。

DNS 域名解析負載均衡


分佈式系統中很常見的負載均衡方案

在DNS中存儲了一個域名的多個主機地址,每次域名解析請求,都可以根據負載均衡算法返回一個不同的IP地址。這樣多個WEB服務器就構成了一個集群,並由DNS服務器提供了負載均衡服務。

DNS域名解析負載均衡的優點是由DNS來完成負載均衡工作,服務本身不用維護負載均衡服務器的工作。

缺點也是,由於負載均衡服務器不是自己維護,沒法做精細控制,而且DNS在客戶端往往帶有緩存,服務器的變更很難及時反映到客戶端上。

反向代理負載均衡


分佈式系統中很常見的負載均衡方案

反向代理服務器位於實際的服務器之前,他能夠緩存服務器響應,加速訪問,同時也啟到了負載均衡服務器的效果。反向代理服務器解析客戶端請求,根據負載均衡算法轉發到不同的後臺服務器上。用戶和後臺服務器之間不再有直接的鏈接。請求,響應都由反向代理服務器進行轉發。

優點是和負載均衡服務集成在一起,部署簡單。

缺點是所有的請求和響應都需要經過反向代理服務器。其本身可能會成為性能的瓶頸。著名的Nginx服務器就可以部署為反向代理服務器,實現WEB 應用的負載均衡。

上面的三種都是工作在OSI網絡模型中的應用層,我們可以統稱為應用層負載均衡(七層負載均衡)。下面介紹的幾種工作在OSI網絡模型中的4層以及4層以下(四層負載均衡),解決方案也具有更大的通用性。

IP負載均衡


分佈式系統中很常見的負載均衡方案

用戶請求包到達負載均衡服務器114.100.20.200後,負載均衡服務器在操作系統內核層獲取網絡數據包,根據負載均衡算法獲取真實後臺服務器地址192.168.1.1, 然後將數據包的目標地址改為192.168.1.1, 轉發給內部服務器。整個過程都在內核層進行處理。收到192.168.1.1的響應包之後,會更改響應包的SRC IP, 轉發給客戶端用戶。

採用IP層負載均衡算法,全部處理過程都在內核層(Ring 0)進行。和七層負載均衡相比,具有更好的性能。但是由於所有的響應包都要經過負載均衡服務器,負載均衡服務器的網卡帶寬,很容易成為系統的瓶頸,如果能夠讓響應包不經過負載均衡服務器,就可以極大的提升整個負載均衡服務器的服務能力。我們下面介紹的數據鏈路層負載均衡,就具有這個能力。

數據鏈路層負載均衡


分佈式系統中很常見的負載均衡方案

數據鏈路層負載均衡,顧名思義,就是工作在TCP/IP協議最底層的數據鏈路層,進行負載均衡。我們常用的以太網中,在這一層主要採用數據幀進行通信,每個網卡都具有唯一的MAC地址,數據幀用MAC地址來標識數據的來源與目的地。

數據鏈路層負載均衡通過修改數據包的MAC地址,實現負載均衡。這種數據傳輸方式又稱為三角傳輸,負載均衡數據分發過程中不修改IP地址,只修改目的MAC地址,通過配置真實物理服務器集群所有機器虛擬IP和負載均衡服務器IP一致,從而達到不修改數據包的源地址和目的地址就可以進行數據分發的目的,由於實際處理請求的真實物理服務器IP和數據請求目的IP一致,不需要通過負載均衡服務器進行地址交換,可將響應數據包直接返回給用戶,避免負載均衡服務器網卡帶寬成為瓶頸。

這種負載均衡方式又稱之為直接路由方式(DR)。如上圖所示,用戶請求到達負載均衡服務器114.100.20.200後,負載均衡服務器將數據包的目的MAC地址更改為00:1e:ec:bc:5e:03,並不修改數據包目的IP,由於服務器集群所有服務器的虛擬IP地址和負載均衡服務器IP地址一致,因此數據可以正常傳輸到達MAC地址為00:1e:ec:bc:5e:03的機器上,該服務器處理完之後,將響應數據包發送到網關服務器,網關服務器直接將數據包發送給用戶,

響應數據不需要通過負載均衡服務器,這樣就避免了負載均衡服務器成為傳輸瓶頸的可能

數據鏈路層負載均衡是目前使用最廣泛的一種負載均衡方式。著名的負載均衡開源產品LVS(Linux Virtual Server),同時支持上面的IP負載均衡和數據鏈路層負載均衡。是學習負載均衡技術必須瞭解的產品。基於數據鏈路層的負載均衡雖然有非常好的性能,但是對網絡拓撲也有比較大的限制,負載均衡服務器和後臺服務器必須處於同一網絡環境中才可以。


分享到:


相關文章: