此文已由作者張小剛授權網易雲社區發布。

歡迎訪問網易雲社區，了解更多網易技術產品運營經驗。

在上一篇文章中，介紹了負載均衡服務，常用的負載均衡服務器以及負載均衡服務在公司的應用情況。這一篇文章會對上篇提到的負載均衡服務器進行較為深入的分析，對其主要功能，優缺點，使用場景進行介紹。希望可以起到拋磚引玉的左右，對大家在了解，使用不同的負載均衡服務有所幫助。

LVS

LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務器，是一個基於Linux的負載均衡服務器。LVS項目在1998年5月由章文嵩博士成立，現在已經得到了極為廣泛的應用，國內外有很多網站和組織都在生產環境中使用LVS系統。

LVS是基於Linux內核模塊，通過在協議包工作鏈上對應位置掛載hook代碼，來實現對網絡包的解析和重寫。其工作原理與iptables相同。在Linux2.4之後，LVS打入Linux標準內核，不需要安裝額外的軟件即可使用。LVS運行於Linux內核之中，用戶要通過運行於用戶態的工具（ipvsadm）來對LVS進行配置。下圖是Linux 數據包協議棧的工作鏈和LVS的掛載點：

這幾個工作鏈主要是工作時間不同：

• NF_IP_PRE_ROUTING：在報文作路由以前執行

• NF_IP_FORWARD：在報文轉向另一個NIC以前執行

• NF_IP_POST_ROUTING：在報文流出以前執行

• NF_IP_LOCAL_IN：在流入本地的報文作路由以後執行

• NF_IP_LOCAL_OUT：在本地報文做流出路由前執行

對於數據包，LVS的工作流程是:PREROUTING -> LOCAL_IN -> POSTROUTING

對於出去的包（只有NAT有效）：PREROUTING -> FORWARD -> POSTROUTING

對於Ping包：PREROUTING -> FORWARD -> POSTROUTING

主要特點：

與應用層的負載均衡不同，LVS運行在內核模式，沒有系統調用開銷。而只支持四層負載均衡模式，LVS也不用處理復雜的七層協議，因此有著很高的性能。當單臂模式的設計又可以讓LVS承載大量流量（與後端對比一般可以達到1：10左右），因此LVS常常被用作整個系統的流量入口。 由於LVS的資源占用很少，在日常的應用中，其瓶頸常在於網絡帶寬而不是CPU和內存，因此運行在物理機上的LVS一般都會配置萬兆或以上的網卡。阿裏雲的LVS集群就采用了單臺LVS配置四個萬兆網卡的形式來提高資源利用率和處理能力。

功能介紹：

LVS是一個純粹的負載均衡服務器，只支持四層負載均衡，支持三種模式，NAT，TUN和DR模式。

• NAT模式：工作在TCP層，這時LVS的功能與其他四層負載均衡服務器類似，是通過NAT協議來修改數據包中的Source IP或者Dest IP地址，來實現負載均衡。在NAT模式下，上下行的流量都需要經過LVS，因此LVS的帶寬可能成為瓶頸。

• TUN模式：工作在IP層：是通過在IP包的基礎上再進行一次獨立的IP封裝，加入額外的IP頭，來實現包轉發功能，因此TUN協議又叫做IPIP協議。TUN模式是單臂流量，只有上行數據會經過LVS，下行數據則直接通過後端服務器發給用戶。為了實現TU模式，後端服務器上需要支持IPIP協議，並綁定一個TUN設備和對應的VIP地址。

• DR模式：DR模式工作在二層，是通過直接修改mac幀中的目標mac地址，來實現數據轉發功能。因為DR模式走的是mac層的協議，因此需要負載均衡服務和後端服務器在同一個二層（同一個廣播域）之中。

總結：使用方面，NAT模式使用最為靈活，對後端無侵入性，但性能也最差。DR模式性能最好，但對網絡拓撲結構有要求。而TUN模式可以達到和DR模式相近的性能，但是需要後端對IPIP協議的支持。

優缺點分析

• 優點：LVS運行簡單，性能非常強大(運行在DR或者TUN模式下的一臺LVS可以支持後端上百臺服務器的需要），而且服務十分穩定（代碼很少有改動）。同時，由於直接集成在Linux內核中，使用簡單，不需要額外安裝。

• 缺點：模式不夠靈活，可配置項少，只支持三種固定模式，很難滿足一些自定義的需求。而LVS服務本身也十分簡單，沒有其他負載均衡服務所帶的健康檢查等功能，需要其他工具（keepalived，OSPF等）支持。社區不夠活躍，代碼更新和活躍度不高。

應用場景：

LVS一般是用在網絡入口的位置，使用一組高可用的LVS集群後面會再接Haproxy，Nginx，Apache等七層負載均衡服務。對於一些四層的應用，也會在前面直接架設一套LVS，使用LVS的NAT模式進行請求轉發和負載均衡。

Nginx/Tengine/Open Resty

Nginx是一款輕量級的Web 服務器/反向代理服務器及電子郵件（IMAP/POP3）代理服務器，並在一個BSD-like 協議下發行。Nginx 是由 Igor Sysoev 為俄羅斯訪問量第二的 Rambler.ru 站點開發的，第一個公開版本0.1.0發布於2004年10月4日。其將源代碼以類BSD許可證的形式發布，因它的穩定性、豐富的功能集、示例配置文件和低系統資源的消耗而聞名。

Nginx起源也是web服務器，但是與Apache不同，Nginx采用的是異步模式，epoll模型來實現，與Apache相比，Nginx在性能，資源消耗方面都有很大的提高。Nginx也是為了解決C 10K問題而開發的服務器之一。

主要功能：

作為一個web服務器，可以提供HTTP資源的訪問，還可以與php結合，提供動態頁面支持。而作為負載均衡服務器，Nginx除了HTTP/HTTPS協議之外，Nginx還支持IMAP/POP3協議，可以作為郵件的代理服務器使用。除了基本的負載均衡功能外，Nginx還支持URL重寫，基於Cookie，URL的轉發等功能。

Nginx還有良好的擴展性，支持通過lua腳本進行功能擴展，可以根據自己的需要，開發具體的業務邏輯。 Nginx基於多進程模型，首先啟動一個master進程，然後fork出多個worker進程（可配置），worker進程通過搶占的方式來處理請求，具體運行架構如下圖所示：

Master進程只負責接受連接，不會執行具體的業務邏輯。Worker進程通過搶占的方式從master那裏得到請求，處理具體的業務邏輯，包括請求解析，提供http服務，請求轉發等。 當重新reload時，Master會根據配置重新啟動一組新的worker進程，同時把請求全部轉發給新的worker。老的worker不再處理請求，當當前請求處理完畢之後才會退出。因此Nginx可以在運行時無縫加載和reload。

優缺點分析

• 優點：Nginx基於epoll的異步模型，資源占用很少，在實際測試中，在處理4000並發連接時，內存資源占用也僅僅只有123.63MB。而Nginx對於運維操作也非常友好，支持運行時reload，並且不會丟失用戶請求。Nginx的多進程模型可以方便的使用多核資源，同時支持CPU綁定，可以把具體的Nginx worker進程綁定在具體的物理CPU之上。

• 缺點：Nginx在處理大的post請求時，會將請求先緩存在本地磁盤，當請求很大且並發請求很多時，磁盤性能會成為瓶頸，而且出現過由於硬盤寫滿導致請求失敗的情況。同時，Nginx也不支持會話保持和主動監測，健康檢查結果展示也不大優好。

衍生版本

Nginx社區十分活躍，並且在應用中有基於Ningx開發的很多衍生版本，這裏就介紹兩個版本：Tengine和OpenResty。

• Tengine：是阿裏基於Nginx開發的衍生版本，補齊了Nginx的短板（Post緩存，主動健康檢查，監控頁面等），並在此基礎上進行了二次開發，對性能和易用性（加入了很多自動配置的選項）進行了優化。

• 優點：已經在阿裏內部得到了廣泛的應用，有大量的實踐基礎和調優經驗。性能，穩定性方面有保障。

• 缺點：直接更改Nginx內核，因此需要通過人工兼容的方式來跟隨Nginx主版本升級。

• OpenResty:基於Nginx開發的另一個衍生版本，直接加入了很多優質的Nginx模塊，從而大大擴展了Nginx本身的功能。與Tengine不同，它沒有直接更改Nginx內核，而是通過加入模塊的方式來提供功能擴展。

應用場景

Nginx可以直接運行在系統最前面，通過Keepalived實現高可用，作為系統流量的入口使用。也可以對接LVS，Haproxy等四層負載均衡，對流量進行二次分流。

Haproxy：

Haproxy是一個專門的負載均衡服務器，支持四層/七層負載均衡。與Nginx，apache等不同，Haproxy不提供靜態資源訪問，URL重寫等web服務器相關功能。

功能介紹

Haproxy也是基於事件機制的異步模型，但與nginx不同，Haproxy是基於單進程模型，沒有提供天然的多進程擴展。雖然可以通過fork進程來實現多進程模型，但是會引起一些問題，因此官方並不推薦這種做法。在實際應用中一般都是把它作為一個單進程負載均衡服務使用。

優缺點分析

• 優點：可以同時支持四層，七層負載均衡，有很高的性能。支持Seesion Sticky，有良好的監控頁面，同時不存在Post緩存問題。

• 缺點：由於Haproxy是基於但進程模型，在reload時會導致短暫的不可用，同時不支持https。在作為四層四層負載均衡服務器時無法獲取原始IP。單進程模型，對多核支持不好（需要多個實例），雖然可以運作在多核模式下，但存在著一些問題。

應用場景：

作為四層負載均衡服務，可以直接接後端服務使用，但由於是采用雙臂模式和單進程模型，並不適合作為單獨的流量入口。在不需要獲取源IP或者對性能要求不是很高的情況下作為四層負載均衡服務器使用。或者作為七層負載均衡服務器，專門處理七層的上傳請求。

Apache

Apache 起初由伊利諾伊大學香檳分校的國家超級電腦應用中心（NCSA）開發，是現在互聯網中使用最熱門和訪問量最大的HTTP服務器，同時還可以通過加載模塊來完成反向代理功能，但嚴格來說Apache並不是一個很好的負載均衡服務器，在性能，功能上與較為專業的負載均衡服務相比並無優勢，而功能也乏善可陳。但是考慮到Apache的廣泛應用以及基於Apache的負載均衡服務在實際的生產環境中還是有不少應用。

功能介紹：

Apache是一個web服務器，通過可以通過加載模塊來實現負載均衡服務。作為一個強大的web服務器，Apache在解析HTTP協議有天然的優勢，支持基於域名分流，URL分析，URL重寫，轉發等功能。

Apache支持兩種模式的負載均衡：基於mod_proxy模塊的一般負載均衡和基於mod_proxy_ajp模塊的二進制負載均衡。這兩種模式的主要區別在於Apache和後端服務之間的連接方式。一般的負載均衡是采用HTTP協議，使用文本傳輸，而ajp模式則采用二進制模式，因此性能上會更好。但相對的，AJP模式需要後端服務器的支持，在一般應用時，會通過跟tomcat結合來提供負載均衡服務。

優缺點分析

• 優點：Apache是應用最廣的web服務器，因此在服務應用上面有著天然的優勢。而Apache+Tomcat的模式可以滿足現在大部分網站對於靜態資源和動態資源的需求。而作為一個強大的web服務器，Apache還支持URL重寫，URL轉發等web服務相關的操作，可以對後端服務提供更多支持。

• 缺點：作為負載均衡服務器，主要問題是采用的多進程模式，每個連接在處理時都會開獨立的線程，當連接請求數據很多時，會有在處理高並發時會有性能隱患。

應用場景：

因為無論從性能還是功能上看，都有更好的選擇，因此Apache一般不會單獨作為負載均衡服務器使用。一般是采用Apache服務作為靜態文件服務器使用的時候，使用AJP模塊與後端的Tomcat對接，提供簡單的負載均衡支持。

總結

本文對常用的四種負載均衡服務進行了簡單的介紹，在之後的文章中，會對具體的負載均衡服務進行更為深入的分析和說明。

參考文獻：

• LVS服務器：http://www.linuxvirtualserver.org/

• Netfiler：http://www.netfilter.org/

• Nginx：http://nginx.org/en/index.html

• Tengine：http://tengine.taobao.org/

• OpenResty：http://www.openresty.org/

• Haproxy：http://www.haproxy.org/

• Apache：http://httpd.apache.org/

免費體驗雲安全(易盾)內容安全、驗證碼等服務

更多網易技術、產品、運營經驗分享請點擊。

相關文章：
【推薦】 線上日誌集中化可視化管理：ELK

負載均衡技術(二）———常用負載均衡服務介紹