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

在上一篇文章中，介紹了負載均衡服務，經常使用的負載均衡服務器以及負載均衡服務在公司的應用狀況。這一篇文章會對上篇提到的負載均衡服務器進行較爲深刻的分析，對其主要功能，優缺點，使用場景進行介紹。但願能夠起到拋磚引玉的左右，對你們在瞭解，使用不一樣的負載均衡服務有所幫助。

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對接，提供簡單的負載均衡支持。

總結

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

若是你也對Java高併發、分佈式、微服務、源碼分析技術感興趣能夠加個人Java後端架構羣，羣裏有免費的資料，也有一些一線互聯網的大牛，歡迎你們來學習交流，羣號：836036968