複雜均衡方案

二層負載均衡：

經過改寫報文的目標MAC地址爲上游服務MAC地址。源IP地址和目標IP地址是沒有改變的，負載均衡服務器和真實服務器共享同一個VIP，如LVS DR工做模式。

四層負載均衡：

根據端口將報文轉發到上游服務器（不一樣的IP地址+端口），如LVS NAT模式、HaProxy。

七層負載均衡：

根據端口號和應用協議如HTTP協議的主機名、URL，轉發報文到上游服務器（不一樣的IP地址+端口，如Haproxy、Nginx）。

須要reload nginx的方式

consul+consul-template方式, reload是有損耗的。

不須要reload nginx方式（動態實現負載均衡）

• Tengine的Dyups模塊
• 微博的Upsync
• OpenResty的balancer_by_lua

微博採用Upsync+consul,又拍雲使用開源的slardar(Consul+balancer_by_lua)

動態添加/刪除上有吧服務器，須要重啓nginx，像HTTP動態負載均衡那樣。

• nginxu商業版
• nginx-strean-upsync-module
• openResty提供的stream-lua-nginx-model還沒有實現balancer_by_lua,暫時沒法使用。

擴展：

Liunx 三大主流（LVS、Nginx、HAproxy）負載均衡對比

• LVS：

1.抗負載能力強，性能高，能達到F5的60%，對內存和cpu資源消耗比較低

2.工做在網絡4層，經過VRRP協議（僅作代理使用），具體的流量是由liunx內核來處理，所以沒有流量的產生。

3.穩定，可靠性強，自身有完美的熱備方案（Keepalived+LVS）

4.不支持正則處理，不能作動靜分離

5.支持多種負載均衡算法：rr（輪詢），wrr（帶權輪詢）、lc（最小鏈接）、wlc（帶權最小鏈接）

6.配置相對複雜，對網絡依賴比較大，穩定性很高。

7.LVS工做模式有4種：

​ （1）nat地址轉換

​ （2）dr直接路由

​ （3）tun隧道

​ （4）full-nat

• Nginx：

1.工做在網絡7層，能夠針對http應用作一些分流的策略，好比針對域名，目錄結構

2.Nginx對網絡的依賴較小，理論上能ping通就能進行敷在功能

3.Nginx安裝配置比較簡單，測試起來很方便

4.也能夠承擔較高的負載壓力且穩定，Nginx是爲了解決c10k問題而誕生的

5.對後端服務器的健康檢查，只支持經過端口來檢測，不支持經過url來檢測

6.Nginx對請求的異步處理能夠幫助節點服務器減輕負載壓力

7.Nginx僅能支持http、https和Email協議，這樣就在適用範圍較小

8.不支持Session的直接保持，但能經過ip_hash來解決，對Big request header的支持不是很好

9.Nginx還能作Web服務器即Cache功能。

• HAproxy：

1.支持兩種代理模式：TCP（四層）和HTTP（七層），支持虛擬主機

2.可以補充Nginx的一些缺點好比Session的保持，Cookie引導等工做

3.支持url檢測後端的服務器出問題的檢測會有很好的幫助。

4.更多負載均衡策略好比：動態加權輪循，加權源地址哈希，加權URL哈希加權等參數哈希已經實現。

5.單純從效率上來說HAproxy更會比Nginx有更出色的負載均衡

6.HAproxy能夠對MYsql進行負載均衡，對後端的DB節點進行檢測和負載均衡

7.支持負載均衡算法：輪循、帶權輪循、源地址保持、請求URL、根據Cookie

8.不能作Web服務器即Cache。

總結：

三大主流軟件負載均衡器適用的生產場景：

1.網站建設初期，能夠選用Nginx、HAproxy做爲反向代理負載均衡（流量不大時能夠選擇不用負載均衡）由於其配置簡單，性能也能知足通常業務場景。若是考慮到負載均衡器是有單點失敗問題，能夠採用Nginx+Keepalived避免負載均衡器自身單點問題。

2.網站併發達到必定程度後，爲了提升穩定性和轉發效率，可使用LVS，畢竟LVS比Nginx/HAproxy要更穩定，轉發效率也高。