幾種常見負載均衡比較
阿新 • • 發佈:2019-02-05
現在網路中常見的的負載均衡主要分為兩種: 一種是通過硬體來進行進行, 常見的硬體有比較昂貴的NetScaler、F5、Radware和Array等商用的負載均衡器, 也有類似於LVS、Nginx、HAproxy的基於Linux的開源的負載均衡策略, 商用負載均衡裡面NetScaler從效果上比F5的效率上更高。對於負載均衡器來說, 不過商用負載均衡由於可以建立在四~七層協議之上,因此適用面更廣所以有其不可替代性, 他的優點就是有專業的維護團隊來對這些服務進行維護、缺點就是花銷太大, 所以對於規模較小的網路服務來說暫時還沒有需要使用。 另一種負載均衡的方式是通過軟體:比較常見的有LVS、Nginx、HAproxy等, 其中LVS是建立在四層協議上面的,而另外Nginx和HAproxy是建立在七層協議之上的 LVS:使用叢集技術和Linux作業系統實現一個高效能、高可用的伺服器, 它具有很好的可伸縮性(Scalability)、可靠性(Reliability)和可管理性(Manageability)。 LVS的特點是: 1、抗負載能力強、是工作在網路4層之上僅作分發之用,沒有流量的產生; 2、配置性比較低,這是一個缺點也是一個優點,因為沒有可太多配置的東西, 所以並不需要太多接觸,大大減少了人為出錯的機率; 3、工作穩定,自身有完整的雙機熱備方案; 4、無流量,保證了均衡器IO的效能不會收到大流量的影響; 5、應用範圍比較廣,可以對所有應用做負載均衡; 6、LVS需要向IDC多申請一個IP來做Visual IP,因此需要一定的網路知識,所以對操作人的要求比較高。 Nginx的特點是: 1、工作在網路的7層之上,可以針對http應用做一些分流的策略,比如針對域名、目錄結構; 2、Nginx對網路的依賴比較小; 3、Nginx安裝和配置比較簡單,測試起來比較方便; 4、也可以承擔高的負載壓力且穩定,一般能支撐超過1萬次的併發; 5、Nginx可以通過埠檢測到伺服器內部的故障, 比如根據伺服器處理網頁返回的狀態碼、超時等等, 並且會把返回錯誤的請求重新提交到另一個節點,不過其中缺點就是不支援url來檢測; 6、Nginx對請求的非同步處理可以幫助節點伺服器減輕負載; 7、Nginx能支援http和Email,這樣就在適用範圍上面小很多; 8、不支援Session的保持、對Big request header的支援不是很好, 另外預設的只有Round-robin和IP-hash兩種負載均衡演算法。 HAProxy的特點是: 1、HAProxy是工作在網路7層之上。 2、能夠補充Nginx的一些缺點比如Session的保持,Cookie的引導等工作 3、支援url檢測後端的伺服器出問題的檢測會有很好的幫助。 4、更多的負載均衡策略比如:動態加權輪循(Dynamic Round Robin), 加權源地址雜湊(Weighted Source Hash), 加權URL雜湊和加權引數雜湊(Weighted Parameter Hash)已經實現 5、單純從效率上來講HAProxy更會比Nginx有更出色的負載均衡速度。 6、HAProxy可以對Mysql進行負載均衡,對後端的DB節點進行檢測和負載均衡。 現在網站發展的趨勢對網路負載均衡的使用是隨著網站規模的提升根據不同的階段來使用不同的技術: 第一階段:利用Nginx或者HAProxy進行單點的負載均衡, 這一階段伺服器規模剛脫離開單伺服器、單資料庫的模式,需要一定的負載均衡, 但是 仍然規模較小沒有專業的維護團隊來進行維護,也沒有需要進行大規模的網站部署。 這樣利用Nginx或者HAproxy就是第一選擇,此時這些東西上手快, 配置容易, 在七層之上利用HTTP協議就可以。這時是第一選擇 第二階段:隨著網路服務進一步擴大,這時單點的Nginx已經不能滿足, 這時使用LVS或者商用F5就是首要選擇,Nginx此時就作為LVS或者 F5的節點來使用, 具體LVS或者F5的是選擇是根據公司規模,人才以及資金能力來選擇的,這裡也不做詳談, 但是一般來說這階段相關人才跟不上業務的提 升,所以購買商業負載均衡已經成為了必經之路。 第三階段:這時網路服務已經成為主流產品,此時隨著公司知名度也進一步擴充套件, 相關人才的能力以及數量也隨之提升,這時無論從開發適合自身產品的定製, 以及降低成本來講開源的LVS,已經成為首選,這時LVS會成為主流。 最終形成比較理想的狀態為:F5/LVS<—>Haproxy<—>Squid/Varnish<—>AppServer。
檢視原文:http://www.chenqmc.com/?p=444