想實現高可用?先搞定負載均衡原理
原創【51CTO.com原創稿件】在互聯網大行其道的今天,隨著業務的迅猛增長,技術上我們常常要面對高并發,大流量。
圖片來自 Pexels
為了實現高可用,高性能我們采用了很多的技術手段,負載均衡就是其中之一。作為外部流量與內部應用的“接引者”,它占據了重要的地位。
我們是否了解整個負載均衡技術?它的分類?它的原理?它的特點?今天讓我們一起來漫談負載均衡吧。
負載均衡的分類
談到負載均衡,大家都會想到 Nginx,通常我們會用它做應用服務的負載均衡。
一般它的并發量在 5W 左右,如果并發量再高就需要做 Nginx 的集群了。但 Nginx 之上還有一層負載均衡器,是它把網絡請求轉發給 Nginx 的,同時還會肩負網絡鏈路,防火墻等工作。
它就是“硬件負載均衡器”,一般安裝在外部網絡與內網服務器之間。比較流行的有 NetScaler,F5,Radware,Array 等產品。
硬件負載均衡器在外網和內網之間
相對于“硬件負載均衡器”來說,對內網服務器進行負載均衡就屬于“軟件負載均衡器”。例如:LVS,HAProxy,Nginx。
硬件負載均衡工作在“接入層”,主要任務是多鏈路負載均衡,防火墻負載均衡,服務器負載均衡。
軟件負載均衡工作在“代理層”,主要任務是反向代理,緩存,數據驗證等等。
硬件負載均衡和軟件負載均衡工作在不同的層
硬件負載均衡在接入層獲得網絡請求,然后轉交給軟件負載均衡,用同樣的方式處理返回的請求。
接入層,代理層,應服務器示意圖
我們知道了負載均衡分為“硬件負載均衡”和“軟件負載均衡”,那么來逐一看看他們是如何工作的吧。
硬件負載均衡
既然前面提到了負載均衡器的分類,那么我們就來聊聊他們的特點。硬件負載均衡技術只專注網絡判斷,不考慮業務系統與應用使用的情況。
看上去它對處理網絡請求是非常專業的,但有趣的是,如果應用服務出現了流量瓶頸,而“接入層”的硬件負載均衡沒有發現異常,還是讓流量繼續進入到應用服務器,并沒有阻止,就會造成應用服務器流量過大。
所以,為了保證高可用,可以在“接入層”和“代理層”同時考慮限流的問題。
作為硬件負載均衡器,常在大企業使用。下面我們以 F5 公司的“F5 BIG-IP”產品為藍本給大家介紹(下面簡稱 F5)。
實際上它是一個集成的解決方案,對于研發的同學來說,主要理解其原理。
硬件負載均衡器三大功能
上面談到硬件負載均衡器的作用和特點,它具備哪三大功能?實現原理又是怎樣的?
①多鏈路負載均衡
關鍵業務都需要安排和配置多條 ISP(網絡服務供應商)接入鏈路來保證網絡服務的可靠性。
如果某個 ISP 停止服務或者服務異常了,那么可以利用另一個 ISP 替代服務,提高了網絡的可用性。
不同的 ISP 有不同自治域,因此需要考慮兩種情況:
- INBOUND
- OUTBOUND
INBOUND,來自網絡的請求信息。F5 分別綁定兩個 ISP 服務商的公網地址,解析來自兩個 ISP 服務商的 DNS 解析請求。
F5 可以根據服務器狀況和響應情況對 DNS 進行發送,也可以通過多條鏈路分別建立 DNS 連接。
OUTBOUND,返回給請求者的應答信息。F5 可以將流量分配到不同的網絡接口,并做源地址的 NAT(網絡地址轉換),即通過 IP 地址轉換為源請求地址。
也可以用接口地址自動映射,保證數據包返回時能夠被源頭正確接收。
多路負載的方式增強了網絡接入層的可靠性
②防火墻負載均衡
針對大量網絡請求的情況,單一防火墻的能力就有限了,而且防火墻本身要求數據同進同出,為了解決多防火墻負載均衡的問題,F5 提出了防火墻負載均衡的“防火墻三明治"方案。
防火墻會對用戶會話的雙向數據流進行監控,從而確定數據的合法性。如果采取多臺防火墻進行負載均衡,有可能會造成同一個用戶會話的雙向數據在多臺防火墻上都進行處理。
而單個防火墻上看不到完成用戶會話的信息,就會認為數據非法因此拋棄數據。
所以在每個防火墻的兩端要架設四層交換機,可以在作流量分發的同時,維持用戶會話的完整性,使同一用戶的會話由一個防火墻來處理。而這種場景就需要 F5 負載均衡器協助才能完成轉發。
有趣的是,F5 協調上述方案的配置和實現后,會把“交換機”,“防火墻”,“交換機”夾在了一起好像三明治一樣。
防火墻“三明治”
③服務器負載均衡
在硬件負載均衡器掛接多個應用服務器時,需要為這些服務做負載均衡,根據規則,讓請求發送到服務器上去:
- 對于服務器的負載均衡的前提是,服務器都提供同樣的服務,也就是同樣的業務同時部署在多個服務器上。
- 對于應用服務器可以在 F5 上配置并且實現負載均衡,F5 可以檢查服務器的健康狀態,如果發現故障,將其從負載均衡組中移除。
- F5 對于外網而言有一個真實的 IP,對于內網的每個服務器都生成一個虛擬 IP,進行負載均衡和管理工作。因此,它能夠為大量的基于 TCP/IP 的網絡應用提供服務器負載均衡服務。
- 根據服務類型不同定義不同的服務器群組。
- 根據不同服務端口將流量導向對應的服務器。甚至可以對 VIP 用戶的請求進行特殊的處理,把這類請求導入到高性能的服務器使 VIP 客戶得到最好的服務響應。
- 根據用戶訪問內容的不同將流量導向指定服務器。
優缺點總結
聊完了硬件負載均衡器的特點和功能以后,讓我們來總結一下它的優缺點:
- 優點:直接連接交換機,處理網絡請求能力強,與系統無關,負載性能強??梢詰糜诖罅吭O施,適應大訪問量、使用簡單。
- 缺點:成本高,配置冗余。即使網絡請求分發到服務器集群,負載均衡設施卻是單點配置;無法有效掌握服務器及應使用狀態。
軟件負載均衡
說完硬件負載均衡,再來談談軟件負載均衡。軟件負載均衡是指在一臺或多臺服務器的操作系統上安裝一個或多個軟件來實現負載均衡。
它的優點是基于特定環境,配置簡單,使用靈活,成本低廉,可以滿足一般的負載均衡需求。
代理層通常起到承上啟下的作用,上連“接入層”,下接應用服務器(上游服務器),可以做反向代理,緩存,數據驗證,限流。本文會一一為各位介紹。
目前市面上比較流行的軟件負載均衡有 LVS,HAProxy,Ngnix。由于篇幅有限我們通過應用廣泛的 Nginx 為切入點,給大家講解,之后會把上面三類軟件進行一個對比。
功能描述和原理分析
對于程序員來說,接觸最多的就是軟件負載均衡。不僅要知道如何使用,同時也要了解背后的原理,下面列舉了其最常用到的 4 大功能。
①反向代理與負載均衡
第一個功能是反向代理與負載均衡,如下圖:
客戶端是如何把請求發送到應用服務器的
客戶端把請求發送到應用服務器有如下幾個步驟:
- 客戶端請求 URL 給 DNS。
- DNS 將 URL 轉化成對應的 IP。
- 通過 IP 找到服務器。
- 服務器接受到請求的報文,轉交給接入層處理,接入層由于采用了硬件負載均衡器,所以能夠扛住大數據量。
- 接入層把報文再次轉交給代理層(并發 5W),代理層的 Nginx 收到報文再根據反向代理的策略發送給上游服務器(應用服務器)。
負載均衡的算法/策略
實際上負載均衡的算法是很多的,這里以 Nginx 為例,介紹五種算法:
- Round-Robin:輪詢算法,默認算法。對上游的服務器進行挨個輪詢,這個算法是可以配合 Weight(權重)來實現的。
- Weight:權重算法,給應用服務器設置 Weight 的值。Weight 默認值為 1,Weight 參數越大被訪問的幾率越大??梢愿鶕掌鞯呐渲煤唾Y源情況配置 Weight 值,讓資源情況樂觀的服務器承擔更多的訪問量。
- IP-Hash:這個算法可以根據用戶 IP 進行負載均衡,同一 IP 的用戶端請求報文是會被同一臺上游服務器響應的。也就是讓同一客戶端的回話(Session)保持一致。
- Least_conn:把請求轉發給連接數較少的后端服務器。輪詢算法是把請求平均的轉發給各個后端,使它們的負載大致相同;但是,有些請求占用的時間很長,會導致其所在的后端負載較高。這種情況下,Least_conn 這種方式就可以達到更好的負載均衡效果。
- Hash Key:這個算法是對 Hash 算法的補充,主要是考慮當出現上游服務器增加/刪除的情況,請求無法正確的被同一服務器處理。
所以對每個請求都設置 Hash Key,這樣就算服務器發生了變化,Key 的值沒有變,也可以找到對應的服務器。
②動態負載均衡
一般上游服務器都采用微服務的架構,那么負載均衡會把數據報發給哪個服務呢?如果服務出現了問題如何通知負載均衡器呢?有新的服務注冊怎么辦呢?
動態負載均衡流程
微服務首先會注冊到“服務注冊發現”中心(Consul,Eureka)。注冊中心包含微服務的信息,Nginx 會定期從這里拉取服務信息(Lua)。
獲取微服務信息以后,Nginx 收到數據報的時候,就可以從注冊中心獲取的服務地址,把信息傳遞給服務了。
③限流
限流的工作可以在接入層用硬件負載均衡器來完成,也可以在代理層來完成。
限流實際上就是限制流入請求的數量,其算法不少,有令牌桶算法,漏桶算法,連接數限制等等。這里我們就介紹三個常用的。一般通過 Nignx+Lua 來實現。
連接數限流:通過 ngx_http_limit_conn_module 模塊實現。設置最大的連接數以及共享內存的區域大小,請求的時候判斷是否超過了最大連接數。
如果超過最大連接數就被限流,否則針對連接數就 +1,請求結束以后會將連接數 -1。
漏桶算法:通過 ngx_http_limit_req_module 模塊實現。一個固定容量的桶,數據報按照固定的速度流出。
數據報可以按照任意的速度流入桶中,如果數據報的容量超過了桶的容量,再流入的數據報將會被丟棄。
按照這個規則,需要設置限流的區域以及桶的容量,以及是否延遲。
漏桶策略
令牌桶算法,桶的大小是固定的,以固定的速度往桶里丟令牌。桶滿了后,后面添加的令牌無法添加。
數據報到來時從桶中取令牌,如果桶中有令牌,憑借令牌處理請求,處理完畢令牌銷毀;數據報到來時發現桶中沒令牌,該請求將被拒絕。
請求在發往令牌桶之前需要經過過濾/分類器,可以對報文進行分類,例如:某類報文可以直接發往應用服務器,某類報文需要經過令牌桶獲取令牌以后才能發。
又例如:VIP 就可以直接把請求發往服務器,用不著經過令牌桶。
令牌桶示意圖
④緩存
Nginx 本地緩存機制
接入層發送請求,如果能夠在 Nginx 本地緩存命中,直接返回緩存數據,如果沒有命中回源到應用服務器。
緩存更新服務器定時更新 Nginx 本地緩存信息。這些需要考慮數據的一致性,何時更新以及何時失效等情況。
Nginx 緩存可以大大提高請求響應時間,可以把不經常更改的信息,例如:用戶信息,提前放入緩存中,每次請求就不用再去請求應用服務器了。一旦用戶信息更新,可以按照一定時鐘頻率寫入緩存中。
另外,一般 HTTPHEAD 中都帶有一些信息更新的信息。Nginx 也可以通過 expires,etag,if-modified-since 來實現瀏覽器緩存的控制。
其他的幾個功能如下:
- 客戶端超時重試
- DNS 超時重試
- 代理超時重試
- 失敗重試
- 心跳檢測
- 配置上有服務器
流行的軟件負載均衡器
目前比較流行的有 LVS,Nginx 和 HAProxy,逐個看看他們的特點。
LVS
LVS(Linux Virtual Server) 是使用 Linux 內核集群實現的一個高性能、高可用的負載均衡服務器,它具有很好的可伸縮性(Scalability)、可靠性(Reliability)和可管理性(Manageability)。
LVS 特點是:
- 僅作分發之用,即把請求直接分發給應用服務器,因此沒有流量的產生,對資源的消耗低。
- 配置簡單,能夠配置的項目少。
- 工作在第四層(傳輸層),支持 TCP/UDP,對應用的支持廣泛。
HAProxy
HAProxy 實現了一種事件驅動,單一進程模型,此模型支持非常大的并發連接數。
多進程或多線程模型受內存限制 、系統調度器限制以及無處不在的鎖限制,很少能處理數千并發連接。
HAProxy 特點是:
- 支持虛擬主機。
- 支持 Session 保持,Cookie 引導。
- 通過指定的 URL 來檢測應用服務器的狀態。
- 支持 TCP/HTTP 協議轉發。
Nginx
Nginx 是一款輕量級的 Web 服務器/反向代理服務器及電子郵件(IMAP/POP3)代理服務器,并在一個 BSD-like 協議下發行。
Nginx 特點是:
- 工作在網絡的 4/7 層,對 HTTP 應用做負載均衡策略,如:域名、目錄結構。
- 對網絡的穩定性依賴小,可以區分內網和外網的訪問。
- 安裝和配置相對簡單。
- 能承受很高負載且穩定,處理的流量依賴于按照 Nginx 服務器的配置。
- 可以檢測服務器的問題,可以對服務器返回的信息進行處理和過濾,避免讓無法工作的服務器響應請求。
- 對請求可以進行異步處理。
- 支持 HTTP、HTTPS 和 EMAIL。
網絡負載均衡的技術選型
既然上面對軟/硬件負載均衡有了總體的了解,那么按照“技術服務業務”的原則,在業務發展的不同階段,如何使用這兩類負載均衡技術呢?
發展階段
企業業務從 0 到 1,從無到有,數據量和訪問量都不大。Nginx 或 HAProxy 進行單點的負載均衡就已經足夠了。
這階段剛剛采用多臺應用服務器、數據庫,需要一定的負載均衡做支撐。由于業務量不大,所以沒有專業的維護團隊來維護,也沒有大規模的網站部署的需求。
因此 Nginx 或 HAproxy 是第一選擇,因為其上手快, 配置容易,在七層之上利用 HTTP 協議就能滿足要求了。
擴張階段
隨著業務量增大,用戶訪問和交易量也在逐步增加,這時單點的 Nginx 或 HAProxy 已經無法滿足之前的需求了。
使用 LVS 或者硬件負載均衡(F5/Array)就是架構師需要考慮的問題了,Nginx 此時就作為 LVS 或者硬件負載均衡(F5/Array)的節點來處理。
軟件負載均衡+硬件負載均衡的架構配置在這個階段就需要考慮了,也是對架構設計者的挑戰。
成熟階段
隨著公司業務擴張到達頂峰,之前的網絡服務已經升級成主流服務產品,需要考慮在開源產品上進行業務定制,所以開源的 LVS,已經成為首選。其在深度定制之后依舊會和硬件負載均衡器配合完成業務服務。
總結
今天內容比較多,總結下來,三句話:
- 硬件和軟件負載均衡,分別工作在“接入層”和“代理層”。
- 一個專注于網絡,負責多鏈路,防火墻以及服務器的負載均衡,例如:F5 BIG-IP。
- 另一個偏向于業務,主要功能是反向代理,動態代理,緩存,限流,例如:LVS,Nginx,HAProxy。
作者:崔皓
簡介:十六年開發和架構經驗,曾擔任過惠普武漢交付中心技術專家,需求分析師,項目經理,后在創業公司擔任技術/產品經理。善于學習,樂于分享。目前專注于技術架構與研發管理。
【51CTO原創稿件,合作站點轉載請注明原文作者和出處為51CTO.com】