【系統架構】三大主流軟件負載均衡器(LVS、Nginx、HAproxy) 與商業SLB比較

主流軟件負載均衡概要：

1、LVS:

    1. 抗負載能力強，性能高，能達到F5的60%，對內存和CPU資源消耗比較低
    2. 工作在網絡4層，通過VRRP協議(僅作代理之用)，具體的流量是由linux內核來處理，因此沒有流量的產生。
    3. 穩定，可靠性高，自身有完美的熱備方案(Keepalived+lvs)
    4. 不支持正則處理，不能做動靜分離。
    5. 支持8種負載均衡算法：rr（輪詢）、wrr（帶權輪詢）、lc（最小連接）、wlc（帶權最小連接）、 lblc（基於局部性的最少連接調度算法）、lblcr（複雜的基於局部性最少的連接算法）、dh（目標地址散列調度算法 ）、sh（源地址散列調度算法 ）
    6. 配置相對複雜，對網絡依賴比較大，穩定性很高。
    7. LVS工作模式有4種：
        (1) nat 地址轉換
        (2) dr 直接路由
        (3) tun 隧道
        (4) full-nat 

2、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功能。

第6點補充：
    什麼是nginx的異步處理：
        squid同步處理：瀏覽器發起請求，而後請求會立刻被轉到後端，於是在瀏覽器和後臺之間就建立了一個通道。從請求發起直到請求完成，這條通道都是一直存在的。
        nginx異步處理：瀏覽器發起請求，請求不會立刻轉到後端，而是請求數據(header)先收到nignx上，然後nginx再把這個請求發到後端，後端處理完成後把數據返回到nginx上，nginx將數據流發到瀏覽器。

    使用異步處理的好處：
        1. 假設用戶執行一個上傳文件操作，因爲用戶網速又比較慢，因此需要花半個小時才能把文件傳到服務器。squid的同步代理在用戶開始上傳後就和後臺建立了連接，半小時後文件上傳結束，由此可見，後臺服務器連接保持了半個小時；而nginx異步代理就是先將此文件收到nginx上，因此僅僅是nginx和用戶保持了半小時連接，後臺服務器在這半小時內沒有爲這個請求開啓連接，半小時後用戶上傳結束，nginx纔將上傳內容發到後臺，nginx和後臺之間的帶寬是很充裕的，所以只花了一秒鐘就將請求發送到了後臺，由此可見，後臺服務器連接保持了一秒。同步傳輸花了後臺服務器半個小時，異步傳輸只花一秒，可見優化 程度很大。
        2. 在上面這個例子中，假如後臺服務器因爲種種原因重啓了，上傳文件就自然中斷了，這對用戶來說是非常惱火的一件事情，想必各位也有上傳文件傳到一半被中斷的 經歷。用nginx代理之後，後臺服務器的重啓對用戶上傳的影響減少到了極點，而nginx是非常穩定的並不需要常去重啓它，即使需要重啓，利用kill -HUP就可以做到不間斷重啓nginx。
        3. 異步傳輸可以令負載均衡器更有保障，爲什麼這麼說呢？在其它的均衡器（lvs/haproxy/apache等）裏，每個請求都是隻有一次機會的，假如用 戶發起一個請求，結果該請求分到的後臺服務器剛好掛掉了，那麼這個請求就失敗了；而nginx因爲是異步的，所以這個請求可以重新發往下一個後臺，下一個 後臺返回了正常的數據，於是這個請求就能成功了。還是用用戶上傳文件這個例子，假如不但用了nginx代理，而且用了負載均衡，nginx把上傳文件發往 其中一臺後臺，但這臺服務器突然重啓了，nginx收到錯誤後，會將這個上傳文件發到另一臺後臺，於是用戶就不用再花半小時上傳一遍。
        4. 假如用戶上傳一個10GB大小的文件，而後臺服務器沒有考慮到這個情況，那麼後臺服務器豈不要崩潰了。用nginx就可以把這些東西都攔在nginx上，通過nginx的上傳文件大小限制功能來限制，另外nginx性能非常有保障，就放心的讓互聯網上那些另類的用戶和nginx對抗去吧。
        用異步傳輸會造成問題：
            後臺服務器有提供上傳進度的功能的話，用了nginx代理就無法取得進度，這個需要使用nginx的一個第三方模塊來實現。

第8點補充：
    Nginx upstream支持的分配策略及原理：
        1. 輪詢(默認)：每個請求按照順序逐一分配到不同的後端服務器。如後端服務器down掉，就切換到另一臺並剔除down的後端主機
        2. weight：指定輪詢機率，weight和訪問比率成正比，用於後端服務器性能不均的情況。
        3. ip_hash：每個請求按照訪問ip的hash結果分配，不同ip的請求被分配到後端不同的服務器上，可以解決session的問題。

 

3、HAProxy:

   1. 支持兩種代理模式：TCP（四層）和HTTP（七層），支持虛擬主機；
    2. 能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導等工作
    3. 支持url檢測後端的服務器出問題的檢測會有很好的幫助。
    4. 更多的負載均衡策略比如：動態加權輪循(Dynamic Round Robin)，加權源地址哈希(Weighted Source Hash)，加權URL哈希和加權參數哈希(Weighted Parameter Hash)已經實現
    5. 單純從效率上來講HAProxy更會比Nginx有更出色的負載均衡速度。
    6. HAProxy可以對Mysql進行負載均衡，對後端的DB節點進行檢測和負載均衡。
    7. 支持負載均衡算法：Round-robin（輪循）、Weight-round-robin（帶權輪循）、source（原地址保持）、RI（請求URL）、rdp-cookie（根據cookie）
    8. 不能做Web服務器即Cache。

三大主流軟件負載均衡器適用業務場景：
    1. 網站建設初期，可以選用Nginx、HAProxy作爲反向代理負載均衡(流量不大時，可以不選用負載均衡)，因爲其配置簡單，性能也能滿足一般業務場景。如果考慮到負載均衡器是有單點問題，可以採用Nginx+Keepalived/HAproxy+Keepalived避免負載均衡器自身的單點問題。
    2. 網站併發到達一定程度後，爲了提高穩定性和轉發效率，可以使用lvs，畢竟lvs比Nginx/HAProxy要更穩定，轉發效率也更高。
    注：nginx與HAProxy比較：nginx只支持七層，用戶量最大，穩定性比較可靠。Haproxy支持四層和七層，支持更多的負載均衡算法，支持session等。

衡量負載均衡器好壞的幾個重要的因素：
    1. 會話率 ：單位時間內的處理的請求數
    2. 會話併發能力：併發處理能力
    3. 數據率：處理數據能力

4、 商業SLB：

 
SLB（Server Load Balance）服務通過設置虛擬服務地址（IP），將位於同一地域（Region）的多臺雲服務器（Elastic Compute Service，簡稱ECS）資源虛擬成一個高性能、高可用的應用服務池；再根據應用指定的方式，將來自客戶端的網絡請求分發到雲服務器池中。

SLB服務會檢查雲服務器池中ECS的健康狀態，自動隔離異常狀態的ECS​​​​​​​，從而解決了單臺ECS​​​​​​​的單點問題，同時提高了應用的整體服務能力。在標準的負載均衡功能之外，SLB服務還具備TCP與HTTP抗DDoS攻擊的特性，增強了應用服務器的防護能力。
 
SLB服務是ECS面向多機方案的一個配套服務，需要同ECS結合使用。

SLB技術架構

整個SLB系統由3部分構成：四層負載均衡，七層負載均衡 和 控制系統，如下圖所示；

• 四層負載均衡，採用開源軟件LVS（linux virtual server），並根據雲計算需求對其進行了定製化；該技術已經在阿里巴巴內部業務全面上線應用2年多詳見第3節；
• 七層負載均衡，採用開源軟件Tengine；該技術已經在阿里巴巴內部業務全面上線應用3年多；參見第4節；
• 控制系統，用於 配置和監控 負載均衡系統；

 

LVS技術特點

LVS是全球最流行的四層負載均衡開源軟件，由章文嵩博士（當前阿里雲產品技術負責人）在1998年5月創立，可以實現LINUX平臺下的負載均衡。
 
LVS是 基於linux netfilter框架實現（同iptables）的一個內核模塊，名稱爲ipvs；其鉤子函數分別HOOK在LOCAL_IN和FORWARD兩個HOOK點，如下圖所示；
 
 
在雲計算大規模網絡環境下，官方LVS存在如下問題；

• 問題1：LVS支持NAT/DR/TUNNEL三種轉發模式，上述模式在多vlan網絡環境下部署時，存在網絡拓撲復雜，運維成本高的問題；
• 問題2：和商用負載均衡設備（如，F5）相比，LVS缺少DDOS攻擊防禦功能；
• 問題3：LVS採用PC服務器，常用keepalived軟件的VRRP心跳協議進行主備部署，其性能無法擴展；
• 問題4：LVS常用管理軟件keepalived的配置和健康檢查性能不足；

 

爲了解決上述問題，我們在官方LVS基礎上進行了定製化；

• 解決1：新增轉發模式FULLNAT，實現LVS-RealServer間跨vlan通訊；
• 解決2：新增synproxy等攻擊TCP標誌位DDOS攻擊防禦功能，；
• 解決3：採用LVS集羣部署方式；
• 解決4：優化keepalived性能；

注1：ali-LVS開源地址https://github.com/alibaba/LVS；
 

FULLNAT技術

FULLNAT實現主要思想：引入local address（內網ip地址），cip-vip轉換爲lip->rip，而 lip和rip均爲IDC內網ip，可以跨vlan通訊；
 
IN/OUT的數據流全部經過LVS，爲了保證帶寬，採用萬兆（10G）網卡；
 
FULLNAT轉發模式，當前僅支持TCP協議；
 

SYNPROXY技術

LVS針對TCP標誌位DDOS攻擊，採取如下策略；

1. Synflood攻擊，利用synproxy模塊進行防禦，如下圖所示；實現主要思想：參照linux tcp協議棧中syncookies的思想，LVS代理TCP三次握手；代理過程：client發送syn包給LVS，LVS構造特殊seq的synack包給client，client回覆ack給LVS，LVS驗證ack包中ack_seq是否合法；如果合法，則LVS再和Realserver建立3次握手；
2. Ack/fin/rstflood攻擊，查找連接表，如果不存在，則直接丟棄；

 

集羣部署方式

LVS集羣部署方式實現的主要思想：LVS和上聯交換機間運行OSPF協議，上聯交換機通過ECMP等價路由，將數據流分發給LVS集羣，LVS集羣再轉發給業務服務器；
 
健壯性：lvs和交換機間運行ospf心跳，1個vip配置在集羣的所有LVS上，當一臺LVS down，交換機會自動發現並將其從ECMP等價路由中剔除；
 
可擴展：如果當前LVS集羣無法支撐某個vip的流量，LVS集羣可以進行水平擴容；
 
集羣部署方式極大的保證了異常情況下，負載均衡服務的穩定性；
 

keepalived優化

對LVS管理軟件keepalived進行了全面優化；

1. 優化了網絡異步模型，select改爲epoll方式；
2. 優化了reload過程；

綜上所述，四層負載均衡產品有如下特點；

1. 高可用，LVS集羣保證了冗餘性，無單點；
2. 安全，LVS自生攻擊防禦+雲盾，提供了近實時防禦能力；
3. 健康檢查：對後端ECS進行健康檢查，自動屏蔽異常狀態的ECS，待該ECS恢復正常後自動解除屏蔽；

Tengine技術特點

Tengine是阿里巴巴發起的web服務器項目，其在Nginx的基礎上，針對大訪問量網站的需求，添加了很多高級功能和特性；Nginx是當前最流行的7層負載均衡開源軟件之一；
 
注：Tengine開源地址http://tengine.taobao.org/；

針對雲計算場景，tengine定製的主要特性如下；

1. 繼承Nginx-1.4.6的所有特性，100%兼容Nginx的配置；
2. 動態模塊加載（DSO）支持。加入一個模塊不再需要重新編譯整個Tengine；
3. 更加強大的負載均衡能力，包括一致性hash模塊、會話保持模塊，還可以對後端的服務器進行主動健康檢查，根據服務器狀態自動上線下線；
4. 監控系統的負載和資源佔用從而對系統進行保護；
5. 顯示對運維人員更友好的出錯信息，便於定位出錯機器；
6. 更強大的防攻擊（訪問速度限制）模塊；

採用Tengine作爲SLB的基礎模塊，阿里七層負載均衡產品有如下特點；

1. 高可用，Tengine集羣保證了冗餘性，無單點；
2. 安全，多維度的CC攻擊防禦能力；；
3. 健康檢查，對後端ECS進行健康檢查，自動屏蔽異常狀態的ECS，待該ECS恢復正常後自動解除屏蔽；
4. 支持7層會話保持功能；
5. 支持一致性hash調度；

技術展望

SLB作爲負載均衡設備，其最重要的指標是 穩定性，在進一步提高穩定性方面，主要工作有2點;

1. 支持集羣內部 session同步；
2. 採用anycast技術實現同城雙A；

同時，在功能方面有更多支持；

1. 白名單訪問控制。從SLB層面實現訪問控制，用戶可以在SLB系統上配置白名單，便於用戶靈活限定外部訪問請求；
2. 更多服務協議的支持。如：HTTPS、UDP等；