歡迎光臨
每天分享高質量文章

淺談幾種常用負載均衡架構

什麼是負載均衡(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 在繁忙的業務系統中,性能並不是很好,此時可以採用集群檔案系統,例如 Redhat 的 GFS 檔案系統、Oracle 提供的 OCFS2 檔案系統等。

 

從整個 LVS 結構可以看出,Director Server 是整個 LVS 的核心,目前用於 Director Server 的操作系統只能是 Linux 和 FreeBSD,Linux 2.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.5 MB 記憶體。

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

  • 併發能力強:官方資料每秒支持 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 中標識)負載均衡對資料流進行分配。

 

規則樣式:針對不同的資料流設置導向規則,用戶可自行。

來源:本文轉自公眾號“運維之美”

原文鏈接:http://t.cn/Ea8JcrS

 

溫馨提示:

請識別二維碼關註公眾號,點擊原文鏈接獲取更多雲計算、微服務架構等技術資料總結

    閱讀原文

    已同步到看一看

    赞(0)

    分享創造快樂