溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
下文給大家帶來什么是負載均衡？優點有哪些？為什么需要負載均衡？負載均衡涉及的東西比較多，理論也不多，網上有很多書籍，今天我們就用億速云在行業內累計的經驗來做一個解答。
拔了一篇文章，不容易找到一個。
然后是對負載均衡介紹比較詳細的一篇文章了：https://www.jianshu.com/p/9826d866080a
總結一下吧：
1. 什么是負載均衡
負載均衡 建立在現有網絡結構之上，它提供了一種廉價有效透明的方法擴展網絡設備和云服務器的帶寬、增加吞吐量、加強網絡數據處理能力、提高網絡的靈活性和可用性。
2. 負載均衡分類
負載均衡根據所采用的設備對象（軟/硬件負載均衡），應用的OSI網絡層次（網絡層次上的負載均衡），及應用的地理結構（本地/全局負載均衡）等來分類。本文著重介紹的是根據應用的 OSI 網絡層次來分類的兩個負載均衡類型。
我們先來看一張圖，相信很多同學對這張圖都不陌生，這是一張網絡模型圖，包含了 OSI 模型及 TCP/IP 模型，兩個模型雖然有一點點區別，但主要的目的是一樣的，模型圖描述了通信是怎么進行的。它解決了實現有效通信所需要的所有過程，并將這些過程劃分為邏輯上的層。層可以簡單地理解成數據通信需要的步驟。
二層負載均衡（mac）
根據OSI模型分的二層負載，一般是用虛擬mac地址方式，外部對虛擬MAC地址請求，負載均衡接收后分配后端實際的MAC地址響應。
三層負載均衡（ip）
一般采用虛擬IP地址方式，外部對虛擬的ip地址請求，負載均衡接收后分配后端實際的IP地址響應。
四層負載均衡（tcp）
在三層負載均衡的基礎上，用ip+port接收請求，再轉發到對應的機器。
七層負載均衡（http）
根據虛擬的url或IP，主機名接收請求，再轉向相應的處理服務器。
在實際應用中，比較常見的就是四層負載及七層負載。這里也重點說下這兩種負載。
3. 四層負載均衡（基于IP+端口的負載均衡）
所謂四層負載均衡，也就是主要通過報文中的目標地址和端口，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。
layer4
在三層負載均衡的基礎上，通過發布三層的IP地址（VIP），然后加四層的端口號，來決定哪些流量需要做負載均衡，對需要處理的流量進行NAT處理，轉發至后臺服務器，并記錄下這個TCP或者UDP的流量是由哪臺服務器處理的，后續這個連接的所有流量都同樣轉發到同一臺服務器處理。
以常見的TCP為例，負載均衡設備在接收到第一個來自客戶端的SYN 請求時，即通過上述方式選擇一個最佳的服務器，并對報文中目標IP地址進行修改(改為后端服務器IP），直接轉發給該服務器。TCP的連接建立，即三次握手是客戶端和服務器直接建立的，負載均衡設備只是起到一個類似路由器的轉發動作。在某些部署情況下，為保證服務器回包可以正確返回給負載均衡設備，在轉發報文的同時可能還會對報文原來的源地址進行修改。
對應的負載均衡器稱為四層交換機（L4 switch），主要分析IP層及TCP/UDP層，實現四層負載均衡。此種負載均衡器不理解應用協議（如HTTP/FTP/MySQL等等）
要處理的流量進行NAT處理，轉發至后臺服務器，并記錄下這個TCP或者UDP的流量是由哪臺服務器處理的，后續這個連接的所有流量都同樣轉發到同一臺服務器處理。
實現四層負載均衡的軟件有：
F5：硬件負載均衡器，功能很好，但是成本很高。
lvs：重量級的四層負載軟件
nginx：輕量級的四層負載軟件，帶緩存功能，正則表達式較靈活
haproxy：模擬四層轉發，較靈活
4. 七層的負載均衡（基于虛擬的URL或主機IP的負載均衡)
所謂七層負載均衡，也稱為“內容交換”，也就是主要通過報文中的真正有意義的應用層內容，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。
layer7
在四層負載均衡的基礎上（沒有四層是絕對不可能有七層的），再考慮應用層的特征，比如同一個Web服務器的負載均衡，除了根據VIP加80端口辨別是否需要處理的流量，還可根據七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。舉個例子，如果你的Web服務器分成兩組，一組是中文語言的，一組是英文語言的，那么七層負載均衡就可以當用戶來訪問你的域名時，自動辨別用戶語言，然后選擇對應的語言服務器組進行負載均衡處理。
以常見的TCP為例，負載均衡設備如果要根據真正的應用層內容再選擇服務器，只能先代理最終的服務器和客戶端建立連接(三次握手)后，才可能接受到客戶端發送的真正應用層內容的報文，然后再根據該報文中的特定字段，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。負載均衡設備在這種情況下，更類似于一個代理服務器。負載均衡和前端的客戶端以及后端的服務器會分別建立TCP連接。所以從這個技術原理上來看，七層負載均衡明顯的對負載均衡設備的要求更高，處理七層的能力也必然會低于四層模式的部署方式。
對應的負載均衡器稱為七層交換機（L7 switch），除了支持四層負載均衡以外，還有分析應用層的信息，如HTTP協議URI或Cookie信息，實現七層負載均衡。此種負載均衡器能理解應用協議。
實現七層負載均衡的軟件有：
haproxy：天生負載均衡技能，全面支持七層代理，會話保持，標記，路徑轉移；
nginx：只在http協議和mail協議上功能比較好，性能與haproxy差不多；
apache：功能較差
Mysql proxy：功能尚可。
5. 兩者之間的區別
舉個例子形象的說明：四層負載均衡就像銀行的自助排號機，每一個達到銀行的客戶根據排號機的順序，選擇對應的窗口接受服務；而七層負載均衡像銀行大堂經理，先確認客戶需要辦理的業務，再安排排號。這樣辦理理財、存取款等業務的客戶，會根據銀行內部資源得到統一協調處理，加快客戶業務辦理流程。
| | 四層負載均衡（layer 4） | 七層負載均衡（layer 7） |
+----------+-------------------------+--------------------------------------------------+
| 基于 | 基于IP+Port的 | 基于虛擬的URL或主機IP等。 |
+----------+-------------------------+--------------------------------------------------+
| 類似于 | 路由器 | 代理服務器 |
+----------+-------------------------+--------------------------------------------------+
| 握手次數 | 1 次 | 2 次 |
+----------+-------------------------+--------------------------------------------------+
| 復雜度 | 低 | 高 |
+----------+-------------------------+--------------------------------------------------+
| 性能 | 高；無需解析內容 | 中；需要算法識別 URL，Cookie 和 HTTP head 等信息 |
+----------+-------------------------+--------------------------------------------------+
| 安全性 | 低，無法識別 DDoS等××× | 高， 可以防御SYN cookie以SYN flood等 |
+----------+-------------------------+--------------------------------------------------+
| 額外功能 | 無 | 會話保持，圖片壓縮，防盜鏈等 |
總結：從上面的對比看來四層負載與七層負載最大的區別就是效率與功能的區別。四層負載架構設計比較簡單，無需解析具體的消息內容，在網絡吞吐量及處理能力上會相對比較高，而七層負載均衡的優勢則體現在功能多，控制靈活強大。在具體業務架構設計時，使用七層負載或者四層負載還得根據具體的情況綜合考慮。
然后是下面這篇，感覺這篇介紹相關負載均衡設備比較多一些 https://www.jianshu.com/p/fa937b8e6712
負載均衡 （Load Balancing） 建立在現有網絡結構之上，它提供了一種廉價有效透明的方法擴展網絡設備和服務器的帶寬、增加吞吐量、加強網絡數據處理能力，同時能夠提高網絡的靈活性和可用性。
Nginx/LVS/HAProxy是目前使用最廣泛的三種負載均衡軟件。
一般對負載均衡的使用是隨著網站規模的提升根據不同的階段來使用不同的技術。具體的應用需求還得具體分析，如果是中小型的Web應用，比如日PV小于1000萬，用Nginx就完全可以了；如果機器不少，可以用DNS輪詢，LVS所耗費的機器還是比較多的；大型網站或重要的服務，且服務器比較多時，可以考慮用LVS。
一種是通過硬件來進行，常見的硬件有比較昂貴的F5和Array等商用的負載均衡器，它的優點就是有專業的維護團隊來對這些服務進行維護、缺點就是花銷太大，所以對于規模較小的網絡服務來說暫時還沒有需要使用；另外一種就是類似于Nginx/LVS/HAProxy的基于 Linux的開源免費的負載均衡軟件，這些都是通過軟件級別來實現，所以費用非常低廉。
目前關于網站架構一般比較合理流行的架構方案：Web前端采用Nginx/HAProxy+ Keepalived作負載均衡器；后端采用 MySQL數據庫一主多從和讀寫分離，采用LVS+Keepalived的架構。當然要根據項目具體需求制定方案。
下面說說各自的特點和適用場合。
Nginx的優點是：
工作在網絡的7層之上，可以針對http應用做一些分流的策略，比如針對域名、目錄結構，它的正則規則比HAProxy更為強大和靈活，這也是它目前廣泛流行的主要原因之一，Nginx單憑這點可利用的場合就遠多于LVS了。
Nginx對網絡穩定性的依賴非常小，理論上能ping通就就能進行負載功能，這個也是它的優勢之一；相反LVS對網絡穩定性依賴比較大。
Nginx安裝和配置比較簡單，測試起來比較方便，它基本能把錯誤用日志打印出來。LVS的配置、測試就要花比較長的時間了，LVS對網絡依賴比較大。
可以承擔高負載壓力且穩定，在硬件不差的情況下一般能支撐幾萬次的并發量，負載度比LVS相對小些。
Nginx可以通過端口檢測到服務器內部的故障，比如根據服務器處理網頁返回的狀態碼、超時等等，并且會把返回錯誤的請求重新提交到另一個節點，不過其中缺點就是不支持url來檢測。比如用戶正在上傳一個文件，而處理該上傳的節點剛好在上傳過程中出現故障，Nginx會把上傳切到另一臺服務器重新處理，而LVS就直接斷掉了，如果是上傳一個很大的文件或者很重要的文件的話，用戶可能會因此而不滿。
Nginx不僅僅是一款優秀的負載均衡器/反向代理軟件，它同時也是功能強大的Web應用服務器。LNMP也是近幾年非常流行的web架構，在高流量的環境中穩定性也很好。
Nginx現在作為Web反向加速緩存越來越成熟了，速度比傳統的Squid服務器更快，可以考慮用其作為反向代理加速器。
Nginx可作為中層反向代理使用，這一層面Nginx基本上無對手，唯一可以對比Nginx的就只有 lighttpd了，不過 lighttpd目前還沒有做到Nginx完全的功能，配置也不那么清晰易讀，社區資料也遠遠沒Nginx活躍。
Nginx也可作為靜態網頁和圖片服務器，這方面的性能也無對手。還有Nginx社區非常活躍，第三方模塊也很多。
Nginx的缺點是：
Nginx僅能支持http、https和Email協議，這樣就在適用范圍上面小些，這個是它的缺點。
對后端服務器的健康檢查，只支持通過端口來檢測，不支持通過url來檢測。不支持Session的直接保持，但能通過ip_hash來解決。
LVS：使用Linux內核集群實現一個高性能、高可用的負載均衡服務器，它具有很好的可伸縮性（Scalability)、可靠性（Reliability)和可管理性（Manageability)。
LVS的優點是：
抗負載能力強、是工作在網絡4層之上僅作分發之用，沒有流量的產生，這個特點也決定了它在負載均衡軟件里的性能最強的，對內存和cpu資源消耗比較低。
配置性比較低，這是一個缺點也是一個優點，因為沒有可太多配置的東西，所以并不需要太多接觸，大大減少了人為出錯的幾率。
工作穩定，因為其本身抗負載能力很強，自身有完整的雙機熱備方案，如LVS+Keepalived。
無流量，LVS只分發請求，而流量并不從它本身出去，這點保證了均衡器IO的性能不會受到大流量的影響。
應用范圍比較廣，因為LVS工作在4層，所以它幾乎可以對所有應用做負載均衡，包括http、數據庫、在線聊天室等等。
LVS的缺點是：
軟件本身不支持正則表達式處理，不能做動靜分離；而現在許多網站在這方面都有較強的需求，這個是Nginx/HAProxy+Keepalived的優勢所在。
如果是網站應用比較龐大的話，LVS/DR+Keepalived實施起來就比較復雜了，特別后面有 Windows Server的機器的話，如果實施及配置還有維護過程就比較復雜了，相對而言，Nginx/HAProxy+Keepalived就簡單多了。
HAProxy的特點是：
HAProxy也是支持虛擬主機的。
HAProxy的優點能夠補充Nginx的一些缺點，比如支持Session的保持，Cookie的引導；同時支持通過獲取指定的url來檢測后端服務器的狀態。
HAProxy跟LVS類似，本身就只是一款負載均衡軟件；單純從效率上來講HAProxy會比Nginx有更出色的負載均衡速度，在并發處理上也是優于Nginx的。
HAProxy支持TCP協議的負載均衡轉發，可以對MySQL讀進行負載均衡，對后端的MySQL節點進行檢測和負載均衡，大家可以用LVS+Keepalived對MySQL主從做負載均衡。
HAProxy負載均衡策略非常多，HAProxy的負載均衡算法現在具體有如下8種：
① roundrobin，表示簡單的輪詢，這個不多說，這個是負載均衡基本都具備的；
② static-rr，表示根據權重，建議關注；
③ leastconn，表示最少連接者先處理，建議關注；
④ source，表示根據請求源IP，這個跟Nginx的IP_hash機制類似，我們用其作為解決session問題的一種方法，建議關注；
⑤ ri，表示根據請求的URI；
⑥ rl_param，表示根據請求的URl參數’balance url_param’ requires an URL parameter name；
⑦ hdr(name)，表示根據HTTP請求頭來鎖定每一次HTTP請求；
⑧ rdp-cookie(name)，表示根據據cookie(name)來鎖定并哈希每一次TCP請求。
Nginx和LVS對比的總結：
Nginx工作在網絡的7層，所以它可以針對http應用本身來做分流策略，比如針對域名、目錄結構等，相比之下LVS并不具備這樣的功能，所以Nginx單憑這點可利用的場合就遠多于LVS了；但Nginx有用的這些功能使其可調整度要高于LVS，所以經常要去觸碰觸碰，觸碰多了，人為出問題的幾率也就會大。
Nginx對網絡穩定性的依賴較小，理論上只要ping得通，網頁訪問正常，Nginx就能連得通，這是Nginx的一大優勢！Nginx同時還能區分內外網，如果是同時擁有內外網的節點，就相當于單機擁有了備份線路；LVS就比較依賴于網絡環境，目前來看服務器在同一網段內并且LVS使用direct方式分流，效果較能得到保證。另外注意，LVS需要向托管商至少申請多一個ip來做Visual IP，貌似是不能用本身的IP來做VIP的。要做好LVS管理員，確實得跟進學習很多有關網絡通信方面的知識，就不再是一個HTTP那么簡單了。
Nginx安裝和配置比較簡單，測試起來也很方便，因為它基本能把錯誤用日志打印出來。LVS的安裝和配置、測試就要花比較長的時間了；LVS對網絡依賴比較大，很多時候不能配置成功都是因為網絡問題而不是配置問題，出了問題要解決也相應的會麻煩得多。
Nginx也同樣能承受很高負載且穩定，但負載度和穩定度差LVS還有幾個等級：Nginx處理所有流量所以受限于機器IO和配置；本身的bug也還是難以避免的。
Nginx可以檢測到服務器內部的故障，比如根據服務器處理網頁返回的狀態碼、超時等等，并且會把返回錯誤的請求重新提交到另一個節點。目前LVS中 ldirectd也能支持針對服務器內部的情況來監控，但LVS的原理使其不能重發請求。比如用戶正在上傳一個文件，而處理該上傳的節點剛好在上傳過程中出現故障，Nginx會把上傳切到另一臺服務器重新處理，而LVS就直接斷掉了，如果是上傳一個很大的文件或者很重要的文件的話，用戶可能會因此而惱火。
Nginx對請求的異步處理可以幫助節點服務器減輕負載，假如使用 apache直接對外服務，那么出現很多的窄帶鏈接時apache服務器將會占用大 量內存而不能釋放，使用多一個Nginx做apache代理的話，這些窄帶鏈接會被Nginx擋住，apache上就不會堆積過多的請求，這樣就減少了相當多的資源占用。這點使用squid也有相同的作用，即使squid本身配置為不緩存，對apache還是有很大幫助的。
Nginx能支持http、https和email（email的功能比較少用），LVS所支持的應用在這點上會比Nginx更多。在使用上，一般最前端所采取的策略應是LVS，也就是DNS的指向應為LVS均衡器，LVS的優點令它非常適合做這個任務。重要的ip地址，最好交由LVS托管，比如數據庫的 ip、webservice服務器的ip等等，這些ip地址隨著時間推移，使用面會越來越大，如果更換ip則故障會接踵而至。所以將這些重要ip交給 LVS托管是最為穩妥的，這樣做的唯一缺點是需要的VIP數量會比較多。Nginx可作為LVS節點機器使用，一是可以利用Nginx的功能，二是可以利用Nginx的性能。當然這一層面也可以直接使用squid，squid的功能方面就比Nginx弱不少了，性能上也有所遜色于Nginx。Nginx也可作為中層代理使用，這一層面Nginx基本上無對手，唯一可以撼動Nginx的就只有lighttpd了，不過lighttpd目前還沒有能做到 Nginx完全的功能，配置也不那么清晰易讀。另外，中層代理的IP也是重要的，所以中層代理也擁有一個VIP和LVS是最完美的方案了。具體的應用還得具體分析，如果是比較小的網站（日PV小于1000萬），用Nginx就完全可以了，如果機器也不少，可以用DNS輪詢，LVS所耗費的機器還是比較多的；大型網站或者重要的服務，機器不發愁的時候，要多多考慮利用LVS。
現在對網絡負載均衡的使用是隨著網站規模的提升根據不同的階段來使用不同的技術：
第一階段：利用Nginx或HAProxy進行單點的負載均衡，這一階段服務器規模剛脫離開單服務器、單數據庫的模式，需要一定的負載均衡，但是仍然規模較小沒有專業的維護團隊來進行維護，也沒有需要進行大規模的網站部署。這樣利用Nginx或HAproxy就是第一選擇，此時這些東西上手快， 配置容易，在七層之上利用HTTP協議就可以。這時是第一選擇。
第二階段：隨著網絡服務進一步擴大，這時單點的Nginx已經不能滿足，這時使用LVS或者商用Array就是首要選擇，Nginx此時就作為LVS或者Array的節點來使用，具體LVS或Array的是選擇是根據公司規模和預算來選擇，Array的應用交付功能非常強大，本人在某項目中使用過，性價比也遠高于F5，商用首選，但是一般來說這階段相關人才跟不上業務的提升，所以購買商業負載均衡已經成為了必經之路。
第三階段：這時網絡服務已經成為主流產品，此時隨著公司知名度也進一步擴展，相關人才的能力以及數量也隨之提升，這時無論從開發適合自身產品的定制，以及降低成本來講開源的LVS，已經成為首選，這時LVS會成為主流。
最終形成比較理想的基本架構為：Array/LVS — Nginx/Haproxy — Squid/Varnish — AppServer。
看了以上關于什么是負載均衡？優點有哪些？的解答，如果大家還有什么地方需要了解的可以在億速云行業資訊里查找自己感興趣的或者找我們的專業技術工程師解答的，億速云技術工程師在行業內擁有十幾年的經驗了。億速云官網鏈接www.mlszssj.com
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
