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

網易雲社群發表於2018-11-15
負載

此文已由作者張小剛授權網易雲社群釋出。


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

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


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的掛載點：


Alt pic


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


  • 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程式通過搶佔的方式來處理請求，具體執行架構如下圖所示：


Alt pic


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


總結


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


參考文獻：





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


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


相關文章：
【推薦】 如何有效的杜絕“羊毛黨“的薅羊毛行為？
【推薦】 淺談高可用測試


相關文章