負載均衡在分佈式架構中是怎麼玩起來的?(老司機帶你玩起來!)

負載均衡在分佈式架構中是怎麼玩起來的?(老司機帶你玩起來!)


什麼是負載均衡(Load balancing)

在網站創立初期,我們一般都使用單臺機器對臺提供集中式服務,但隨著業務量越來越大,無論性能還是穩定性上都有了更大的挑戰。這時候我們就會想到通過擴容的方式來提供更好的服務。我們一般會把多臺機器組成一個集群對外提供服務。然而,我們的網站對外提供的訪問入口都是一個的,比如www.taobao.com。那麼當用戶在瀏覽器輸入www.taobao.com的時候如何將用戶的請求分發到集群中不同的機器上呢,這就是負載均衡在做的事情。

當前大多數的互聯網系統都使用了服務器集群技術,集群即將相同服務部署在多臺服務器上構成一個集群整體對外提供服務,這些集群可以是Web應用服務器集群,也可以是數據庫服務器集群,還可以是分佈式緩存服務器集群等。

在實際應用中,在Web服務器集群之前總會有一臺負載均衡服務器,負載均衡設備的任務就是作為Web服務器流量的入口,挑選最合適的一臺Web服務器,將客戶端的請求轉發給它處理,實現客戶端到真實服務端的透明轉發。最近幾年很火的「雲計算」以及分佈式架構,本質上也是將後端服務器作為計算資源、存儲資源,由某臺管理服務器封裝成一個服務對外提供,客戶端不需要關心真正提供服務的是哪臺機器,在它看來,就好像它面對的是一臺擁有近乎無限能力的服務器,而本質上,真正提供服務的是後端的集群。

軟件負載解決的兩個核心問題是:選誰、轉發,其中最著名的是LVS(Linux Virtual Server)。

負載均衡在分佈式架構中是怎麼玩起來的?(老司機帶你玩起來!)

一個典型的互聯網應用的拓撲結構是這樣的:

負載均衡在分佈式架構中是怎麼玩起來的?(老司機帶你玩起來!)

負載均衡分類

現在我們知道,負載均衡就是一種計算機網絡技術,用來在多個計算機(計算機集群)、網絡連接、CPU、磁碟驅動器或其它資源中分配負載,以達到最佳化資源使用、最大化吞吐率、最小化響應時間、同時避免過載的目的。那麼,這種計算機技術的實現方式有多種。大致可以分為以下幾種,其中最常用的是四層和七層負載均衡:

二層負載均衡

負載均衡服務器對外依然提供一個VIP(虛IP),集群中不同的機器採用相同IP地址,但機器的MAC地址不一樣。當負載均衡服務器接受到請求之後,通過改寫報文的目標MAC地址的方式將請求轉發到目標機器實現負載均衡。

三層負載均衡

和二層負載均衡類似,負載均衡服務器對外依然提供一個VIP(虛IP),但集群中不同的機器採用不同的IP地址。當負載均衡服務器接受到請求之後,根據不同的負載均衡算法,通過IP將請求轉發至不同的真實服務器。

四層負載均衡

四層負載均衡工作在OSI模型的傳輸層,由於在傳輸層,只有TCP/UDP協議,這兩種協議中除了包含源IP、目標IP以外,還包含源端口號及目的端口號。四層負載均衡服務器在接受到客戶端請求後,以後通過修改數據包的地址信息(IP+端口號)將流量轉發到應用服務器。

七層負載均衡

七層負載均衡工作在OSI模型的應用層,應用層協議較多,常用http、radius、DNS等。七層負載就可以基於這些協議來負載。這些應用層協議中會包含很多有意義的內容。比如同一個Web服務器的負載均衡,除了根據IP加端口進行負載外,還可根據七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。

負載均衡在分佈式架構中是怎麼玩起來的?(老司機帶你玩起來!)

對於一般的應用來說,有了Nginx就夠了。Nginx可以用於七層負載均衡。但是對於一些大的網站,一般會採用DNS+四層負載+七層負載的方式進行多層次負載均衡。

負載均衡在分佈式架構中是怎麼玩起來的?(老司機帶你玩起來!)

常用負載均衡工具

硬件負載均衡性能優越,功能全面,但價格昂貴,一般適合初期或者土豪級公司長期使用。因此軟件負載均衡在互聯網領域大量使用。常用的軟件負載均衡軟件有Nginx、LVS、HaProxy等。

Nginx/LVS/HAProxy是目前使用最廣泛的三種負載均衡軟件。

1

、 LVS

LVS(Linux Virtual Server),也就是Linux虛擬服務器,是一個由章文嵩博士發起的自由軟件項目。使用LVS技術要達到的目標是:通過LVS提供的負載均衡技術和Linux操作系統實現一個高性能、高可用的服務器群集,它具有良好可靠性、可擴展性和可操作性。從而以低廉的成本實現最優的服務性能。

LVS主要用來做四層負載均衡。

LVS架構

LVS架設的服務器集群系統由三個部分組成:最前端的負載均衡層(Loader Balancer),中間的服務器群組層,用Server Array表示,最底層的數據共享存儲層,用Shared Storage表示。在用戶看來所有的應用都是透明的,用戶只是在使用一個虛擬服務器提供的高性能服務。

負載均衡在分佈式架構中是怎麼玩起來的?(老司機帶你玩起來!)

LVS的各個層次的詳細介紹:

Load Balancer層:位於整個集群系統的最前端,有一臺或者多臺負載調度器(Director Server)組成,LVS模塊就安裝在Director Server上,而Director的主要作用類似於一個路由器,它含有完成LVS功能所設定的路由表,通過這些路由表把用戶的請求分發給Server Array層的應用服務器(Real Server)上。同時,在Director Server上還要安裝對Real Server服務的監控模塊Ldirectord,此模塊用於監測各個Real Server服務的健康狀況。在Real Server不可用時把它從LVS路由表中剔除,恢復時重新加入。

Server Array層:由一組實際運行應用服務的機器組成,Real Server可以是Web服務器、Mail服務器、FTP服務器、DNS服務器、視頻服務器中的一個或者多個,每個Real Server之間通過高速的LAN或分佈在各地的WAN相連接。在實際的應用中,Director Server也可以同時兼任Real Server的角色。

Shared Storage層:是為所有Real Server提供共享存儲空間和內容一致性的存儲區域,在物理上一般由磁盤陣列設備組成,為了提供內容的一致性,一般可以通過NFS網絡文件系統共享數 據,但NFS在繁忙的業務系統中,性能並不是很好,此時可以採用集群文件系統,例如Red hat的GFS文件系統、Oracle提供的OCFS2文件系統等。

從整個LVS結構可以看出,Director Server是整個LVS的核心,目前用於Director Server的操作系統只能是Linux和FreeBSD,Linux2.6內核不用任何設置就可以支持LVS功能,而FreeBSD作為 Director Server的應用還不是很多,性能也不是很好。對於Real Server,幾乎可以是所有的系統平臺,Linux、windows、Solaris、AIX、BSD系列都能很好地支持。

2、Nginx

Nginx(發音同engine x)是一個網頁服務器,它能反向代理HTTP、HTTPS,、SMTP、POP3、IMAP的協議鏈接,以及一個負載均衡器和一個HTTP緩存。

Nginx主要用來做七層負載均衡。

併發性能:官方支持每秒5萬併發,實際國內一般到每秒2萬併發,有優化到每秒10萬併發的。具體性能看應用場景。

特點:

  • 模塊化設計:良好的擴展性,可以通過模塊方式進行功能擴展。

  • 高可靠性:主控進程和worker是同步實現的,一個worker出現問題,會立刻啟動另一個worker。

  • 內存消耗低:一萬個長連接(keep-alive),僅消耗2.5MB內存。

  • 支持熱部署:不用停止服務器,實現更新配置文件,更換日誌文件、更新服務器程序版本。

  • 併發能力強:官方數據每秒支持5萬併發;

  • 功能豐富:優秀的反向代理功能和靈活的負載均衡策略

Nginx的基本工作模式

負載均衡在分佈式架構中是怎麼玩起來的?(老司機帶你玩起來!)

一個master進程,生成一個或者多個worker進程。但這裡master是使用root身份啟動的,因為nginx要工作在80端口。而只有管理員才有權限啟動小於低於1023的端口。master主要是負責的作用只是啟動worker,加載配置文件,負責系統的平滑升級。其它的工作是交給worker。那當worker被啟動之後,也只是負責一些web最簡單的工作,而其它的工作都是由worker中調用的模塊來實現的。

模塊之間是以流水線的方式實現功能的。流水線,指的是一個用戶請求,由多個模塊組合各自的功能依次實現完成的。比如:第一個模塊只負責分析請求首部,第二個模塊只負責查找數據,第三個模塊只負責壓縮數據,依次完成各自工作。來實現整個工作的完成。

它們是如何實現熱部署的呢?是這樣的,我們前面說master不負責具體的工作,而是調用worker工作,它只是負責讀取配置文件,因此當一個模塊修改或者配置文件發生變化,是由master進行讀取,因此此時不會影響到worker工作。在master進行讀取配置文件之後,不會立即把修改的配置文件告知worker。而是讓被修改的worker繼續使用老的配置文件工作,當worker工作完畢之後,直接當掉這個子進程,更換新的子進程,使用新的規則。

3、HAProxy

HAProxy也是使用較多的一款負載均衡軟件。HAProxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代理,支持虛擬主機,是免費、快速並且可靠的一種解決方案。特別適用於那些負載特大的web站點。運行模式使得它可以很簡單安全的整合到當前的架構中,同時可以保護你的web服務器不被暴露到網絡上。

HAProxy是一個使用C語言編寫的自由及開放源代碼軟件,其提供高可用性、負載均衡,以及基於TCP和HTTP的應用程序代理。

Haproxy主要用來做七層負載均衡。

常見負載均衡算法

上面介紹負載均衡技術的時候提到過,負載均衡服務器在決定將請求轉發到具體哪臺真實服務器時,是通過負載均衡算法來實現的。負載均衡算法可以分為兩類:靜態負載均衡算法和動態負載均衡算法。

  • 靜態負載均衡算法包括:輪詢、比率、優先權。

  • 動態負載均衡算法包括:最少連接數、最快響應速度、觀察方法、預測法、動態性能分配、動態服務器補充、服務質量、服務類型、規則模式。

輪詢(Round Robin):順序循環將請求一次順序循環地連接每個服務器。當其中某個服務器發生第二到第7 層的故障,BIG-IP 就把其從順序循環隊列中拿出,不參加下一次的輪詢,直到其恢復正常。

以輪詢的方式依次請求調度不同的服務器; 實現時,一般為服務器帶上權重;這樣有兩個好處:

  • 針對服務器的性能差異可分配不同的負載;

  • 當需要將某個結點剔除時,只需要將其權重設置為0即可;

優點:實現簡單、高效;易水平擴展

缺點:請求到目的結點的不確定,造成其無法適用於有寫的場景(緩存,數據庫寫)

應用場景:數據庫或應用服務層中只有讀的場景

隨機方式:請求隨機分佈到各個結點;在數據足夠大的場景能達到一個均衡分佈;

優點:實現簡單、易水平擴展

缺點:同Round Robin,無法用於有寫的場景

應用場景:數據庫負載均衡,也是隻有讀的場景

哈希方式:根據key來計算需要落在的結點上,可以保證一個同一個鍵一定落在相同的服務器上;

優點:相同key一定落在同一個結點上,這樣就可用於有寫有讀的緩存場景

缺點:在某個結點故障後,會導致哈希鍵重新分佈,造成命中率大幅度下降

解決:一致性哈希 or 使用keepalived保證任何一個結點的高可用性,故障後會有其它結點頂上來

應用場景:緩存,有讀有寫

一致性哈希:在服務器一個結點出現故障時,受影響的只有這個結點上的key,最大程度的保證命中率; 如twemproxy中的ketama方案; 生產實現中還可以規劃指定子key哈希,從而保證局部相似特徵的鍵能分佈在同一個服務器上;

優點:結點故障後命中率下降有限

應用場景:緩存

根據鍵的範圍來負載:根據鍵的範圍來負載,前1億個鍵都存放到第一個服務器,1~2億在第二個結點。

優點:水平擴展容易,存儲不夠用時,加服務器存放後續新增數據

缺點:負載不均;數據庫的分佈不均衡;

(數據有冷熱區分,一般最近註冊的用戶更加活躍,這樣造成後續的服務器非常繁忙,而前期的結點空閒很多)

適用場景:數據庫分片負載均衡

根據鍵對服務器結點數取模來負載:

根據鍵對服務器結點數取模來負載;比如有4臺服務器,key取模為0的落在第一個結點,1落在第二個結點上。

優點:數據冷熱分佈均衡,數據庫結點負載均衡分佈;

缺點:水平擴展較難;

適用場景:數據庫分片負載均衡

純動態結點負載均衡:根據CPU、IO、網絡的處理能力來決策接下來的請求如何調度。

優點:充分利用服務器的資源,保證個結點上負載處理均衡

缺點:實現起來複雜,真實使用較少

不用主動負載均衡:使用消息隊列轉為異步模型,將負載均衡的問題消滅;負載均衡是一種推模型,一直向你發數據,那麼將所有的用戶請求發到消息隊列中,所有的下游結點誰空閒,誰上來取數據處理;轉為拉模型之後,消除了對下行結點負載的問題。

優點:通過消息隊列的緩衝,保護後端系統,請求劇增時不會沖垮後端服務器;水平擴展容易,加入新結點後,直接取queue即可;

缺點:不具有實時性;

應用場景:不需要實時返回的場景;

比如,12036下訂單後,立刻返回提示信息:您的訂單進去排隊了...等處理完畢後,再異步通知;

比率(Ratio):給每個服務器分配一個加權值為比例,根椐這個比例,把用戶的請求分配到每個服務器。當其中某個服務器發生第2到第7 層的故障,BIG-IP 就把其從服務器隊列中拿出,不參加下一次的用戶請求的分配,直到其恢復正常。

優先權(Priority):給所有服務器分組,給每個組定義優先權,BIG-IP 用戶的請求,分配給優先級最高的服務器組(在同一組內,採用輪詢或比率算法,分配用戶的請求);當最高優先級中所有服務器出現故障,BIG-IP 才將請求送給次優先級的服務器組。這種方式,實際為用戶提供一種熱備份的方式。

最少的連接方式(Least Connection):傳遞新的連接給那些進行最少連接處理的服務器。當其中某個服務器發生第2到第7 層的故障,BIG-IP 就把其從服務器隊列中拿出,不參加下一次的用戶請求的分配,直到其恢復正常。

最快模式(Fastest):傳遞連接給那些響應最快的服務器。當其中某個服務器發生第二到第7 層的故障,BIG-IP 就把其從服務器隊列中拿出,不參加下一次的用戶請求的分配,直到其恢復正常。

觀察模式(Observed):連接數目和響應時間以這兩項的最佳平衡為依據為新的請求選擇服務器。當其中某個服務器發生第二到第7 層的故障,BIG-IP就把其從服務器隊列中拿出,不參加下一次的用戶請求的分配,直到其恢復正常。

預測模式(Predictive):BIG-IP利用收集到的服務器當前的性能指標,進行預測分析,選擇一臺服務器在下一個時間片內,其性能將達到最佳的服務器相應用戶的請求。(被BIG-IP 進行檢測)

動態性能分配(Dynamic Ratio-APM):BIG-IP 收集到的應用程序和應用服務器的各項性能參數,動態調整流量分配。

動態服務器補充(Dynamic Server Act.):當主服務器群中因故障導致數量減少時,動態地將備份服務器補充至主服務器群。

服務質量(QoS):按不同的優先級對數據流進行分配。

服務類型(ToS): 按不同的服務類型(在Type of Field中標識)負載均衡對數據流進行分配。

規則模式:針對不同的數據流設置導向規則,用戶可自行。

負載均衡的幾種算法Java實現代碼

  • 輪詢

負載均衡在分佈式架構中是怎麼玩起來的?(老司機帶你玩起來!)

負載均衡在分佈式架構中是怎麼玩起來的?(老司機帶你玩起來!)

負載均衡在分佈式架構中是怎麼玩起來的?(老司機帶你玩起來!)

  • 加權隨機負載均衡算法

負載均衡在分佈式架構中是怎麼玩起來的?(老司機帶你玩起來!)

負載均衡在分佈式架構中是怎麼玩起來的?(老司機帶你玩起來!)

  • 隨機負載均衡算法

負載均衡在分佈式架構中是怎麼玩起來的?(老司機帶你玩起來!)

負載均衡在分佈式架構中是怎麼玩起來的?(老司機帶你玩起來!)

  • 負載均衡 ip_hash算法.

負載均衡在分佈式架構中是怎麼玩起來的?(老司機帶你玩起來!)

負載均衡在分佈式架構中是怎麼玩起來的?(老司機帶你玩起來!)


分享到:


相關文章: