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

LVS

LVS是Linux Virtual Server的簡(jiǎn)寫，意即Linux虛擬服務(wù)器，是一個(gè)基于Linux的負(fù)載均衡服務(wù)器。LVS項(xiàng)目在1998年5月由章文嵩博士成立，現(xiàn)在已經(jīng)得到了極為廣泛的應(yīng)用，國(guó)內(nèi)外有很多網(wǎng)站和組織都在生產(chǎn)環(huán)境中使用LVS系統(tǒng)。

LVS是基于Linux內(nèi)核模塊，通過在協(xié)議包工作鏈上對(duì)應(yīng)位置掛載hook代碼，來實(shí)現(xiàn)對(duì)網(wǎng)絡(luò)包的解析和重寫。其工作原理與iptables相同。在Linux2.4之后，LVS打入Linux標(biāo)準(zhǔn)內(nèi)核，不需要安裝額外的軟件即可使用。LVS運(yùn)行于Linux內(nèi)核之中，用戶要通過運(yùn)行于用戶態(tài)的工具（ipvsadm）來對(duì)LVS進(jìn)行配置。下圖是Linux 數(shù)據(jù)包協(xié)議棧的工作鏈和LVS的掛載點(diǎn)：

這幾個(gè)工作鏈主要是工作時(shí)間不同：

NF_IP_PRE_ROUTING：在報(bào)文作路由以前執(zhí)行

NF_IP_FORWARD：在報(bào)文轉(zhuǎn)向另一個(gè)NIC以前執(zhí)行

NF_IP_POST_ROUTING：在報(bào)文流出以前執(zhí)行

NF_IP_LOCAL_IN：在流入本地的報(bào)文作路由以后執(zhí)行

NF_IP_LOCAL_OUT：在本地報(bào)文做流出路由前執(zhí)行

對(duì)于數(shù)據(jù)包，LVS的工作流程是:PREROUTING -> LOCAL_IN -> POSTROUTING

對(duì)于出去的包（只有NAT有效）：PREROUTING -> FORWARD -> POSTROUTING

對(duì)于Ping包：PREROUTING -> FORWARD -> POSTROUTING

主要特點(diǎn)：

與應(yīng)用層的負(fù)載均衡不同，LVS運(yùn)行在內(nèi)核模式，沒有系統(tǒng)調(diào)用開銷。而只支持四層負(fù)載均衡模式，LVS也不用處理復(fù)雜的七層協(xié)議，因此有著很高的性能。當(dāng)單臂模式的設(shè)計(jì)又可以讓LVS承載大量流量（與后端對(duì)比一般可以達(dá)到1：10左右），因此LVS常常被用作整個(gè)系統(tǒng)的流量入口。 由于LVS的資源占用很少，在日常的應(yīng)用中，其瓶頸常在于網(wǎng)絡(luò)帶寬而不是CPU和內(nèi)存，因此運(yùn)行在物理機(jī)上的LVS一般都會(huì)配置萬兆或以上的網(wǎng)卡。阿里云的LVS集群就采用了單臺(tái)LVS配置四個(gè)萬兆網(wǎng)卡的形式來提高資源利用率和處理能力。

功能介紹：

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

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

TUN模式：工作在IP層：是通過在IP包的基礎(chǔ)上再進(jìn)行一次獨(dú)立的IP封裝，加入額外的IP頭，來實(shí)現(xiàn)包轉(zhuǎn)發(fā)功能，因此TUN協(xié)議又叫做IPIP協(xié)議。TUN模式是單臂流量，只有上行數(shù)據(jù)會(huì)經(jīng)過LVS，下行數(shù)據(jù)則直接通過后端服務(wù)器發(fā)給用戶。為了實(shí)現(xiàn)TU模式，后端服務(wù)器上需要支持IPIP協(xié)議，并綁定一個(gè)TUN設(shè)備和對(duì)應(yīng)的VIP地址。

DR模式：DR模式工作在二層，是通過直接修改mac幀中的目標(biāo)mac地址，來實(shí)現(xiàn)數(shù)據(jù)轉(zhuǎn)發(fā)功能。因?yàn)镈R模式走的是mac層的協(xié)議，因此需要負(fù)載均衡服務(wù)和后端服務(wù)器在同一個(gè)二層（同一個(gè)廣播域）之中。

總結(jié)：使用方面，NAT模式使用最為靈活，對(duì)后端無侵入性，但性能也最差。DR模式性能最好，但對(duì)網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)有要求。而TUN模式可以達(dá)到和DR模式相近的性能，但是需要后端對(duì)IPIP協(xié)議的支持。

優(yōu)缺點(diǎn)分析

優(yōu)點(diǎn)：LVS運(yùn)行簡(jiǎn)單，性能非常強(qiáng)大(運(yùn)行在DR或者TUN模式下的一臺(tái)LVS可以支持后端上百臺(tái)服務(wù)器的需要），而且服務(wù)十分穩(wěn)定（代碼很少有改動(dòng)）。同時(shí)，由于直接集成在Linux內(nèi)核中，使用簡(jiǎn)單，不需要額外安裝。

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

應(yīng)用場(chǎng)景：

LVS一般是用在網(wǎng)絡(luò)入口的位置，使用一組高可用的LVS集群后面會(huì)再接Haproxy，Nginx，Apache等七層負(fù)載均衡服務(wù)。對(duì)于一些四層的應(yīng)用，也會(huì)在前面直接架設(shè)一套LVS，使用LVS的NAT模式進(jìn)行請(qǐng)求轉(zhuǎn)發(fā)和負(fù)載均衡。

Nginx/Tengine/Open Resty

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

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

主要功能：

作為一個(gè)web服務(wù)器，可以提供HTTP資源的訪問，還可以與php結(jié)合，提供動(dòng)態(tài)頁面支持。而作為負(fù)載均衡服務(wù)器，Nginx除了HTTP/HTTPS協(xié)議之外，Nginx還支持IMAP/POP3協(xié)議，可以作為郵件的代理服務(wù)器使用。除了基本的負(fù)載均衡功能外，Nginx還支持URL重寫，基于Cookie，URL的轉(zhuǎn)發(fā)等功能。

Nginx還有良好的擴(kuò)展性，支持通過lua腳本進(jìn)行功能擴(kuò)展，可以根據(jù)自己的需要，開發(fā)具體的業(yè)務(wù)邏輯。 Nginx基于多進(jìn)程模型，首先啟動(dòng)一個(gè)master進(jìn)程，然后fork出多個(gè)worker進(jìn)程（可配置），worker進(jìn)程通過搶占的方式來處理請(qǐng)求，具體運(yùn)行架構(gòu)如下圖所示：

Master進(jìn)程只負(fù)責(zé)接受連接，不會(huì)執(zhí)行具體的業(yè)務(wù)邏輯。Worker進(jìn)程通過搶占的方式從master那里得到請(qǐng)求，處理具體的業(yè)務(wù)邏輯，包括請(qǐng)求解析，提供http服務(wù)，請(qǐng)求轉(zhuǎn)發(fā)等。 當(dāng)重新reload時(shí)，Master會(huì)根據(jù)配置重新啟動(dòng)一組新的worker進(jìn)程，同時(shí)把請(qǐng)求全部轉(zhuǎn)發(fā)給新的worker。老的worker不再處理請(qǐng)求，當(dāng)當(dāng)前請(qǐng)求處理完畢之后才會(huì)退出。因此Nginx可以在運(yùn)行時(shí)無縫加載和reload。

優(yōu)缺點(diǎn)分析

優(yōu)點(diǎn)：Nginx基于epoll的異步模型，資源占用很少，在實(shí)際測(cè)試中，在處理4000并發(fā)連接時(shí)，內(nèi)存資源占用也僅僅只有123.63MB。而Nginx對(duì)于運(yùn)維操作也非常友好，支持運(yùn)行時(shí)reload，并且不會(huì)丟失用戶請(qǐng)求。Nginx的多進(jìn)程模型可以方便的使用多核資源，同時(shí)支持CPU綁定，可以把具體的Nginx worker進(jìn)程綁定在具體的物理CPU之上。

缺點(diǎn)：Nginx在處理大的post請(qǐng)求時(shí)，會(huì)將請(qǐng)求先緩存在本地磁盤，當(dāng)請(qǐng)求很大且并發(fā)請(qǐng)求很多時(shí)，磁盤性能會(huì)成為瓶頸，而且出現(xiàn)過由于硬盤寫滿導(dǎo)致請(qǐng)求失敗的情況。同時(shí)，Nginx也不支持會(huì)話保持和主動(dòng)監(jiān)測(cè)，健康檢查結(jié)果展示也不大優(yōu)好。

衍生版本

Nginx社區(qū)十分活躍，并且在應(yīng)用中有基于Ningx開發(fā)的很多衍生版本，這里就介紹兩個(gè)版本：Tengine和OpenResty。

Tengine：是阿里基于Nginx開發(fā)的衍生版本，補(bǔ)齊了Nginx的短板（Post緩存，主動(dòng)健康檢查，監(jiān)控頁面等），并在此基礎(chǔ)上進(jìn)行了二次開發(fā)，對(duì)性能和易用性（加入了很多自動(dòng)配置的選項(xiàng)）進(jìn)行了優(yōu)化。

優(yōu)點(diǎn)：已經(jīng)在阿里內(nèi)部得到了廣泛的應(yīng)用，有大量的實(shí)踐基礎(chǔ)和調(diào)優(yōu)經(jīng)驗(yàn)。性能，穩(wěn)定性方面有保障。

缺點(diǎn)：直接更改Nginx內(nèi)核，因此需要通過人工兼容的方式來跟隨Nginx主版本升級(jí)。

OpenResty:基于Nginx開發(fā)的另一個(gè)衍生版本，直接加入了很多優(yōu)質(zhì)的Nginx模塊，從而大大擴(kuò)展了Nginx本身的功能。與Tengine不同，它沒有直接更改Nginx內(nèi)核，而是通過加入模塊的方式來提供功能擴(kuò)展。

應(yīng)用場(chǎng)景

Nginx可以直接運(yùn)行在系統(tǒng)最前面，通過Keepalived實(shí)現(xiàn)高可用，作為系統(tǒng)流量的入口使用。也可以對(duì)接LVS，Haproxy等四層負(fù)載均衡，對(duì)流量進(jìn)行二次分流。

Haproxy：

Haproxy是一個(gè)專門的負(fù)載均衡服務(wù)器，支持四層/七層負(fù)載均衡。與Nginx，apache等不同，Haproxy不提供靜態(tài)資源訪問，URL重寫等web服務(wù)器相關(guān)功能。

功能介紹

Haproxy也是基于事件機(jī)制的異步模型，但與nginx不同，Haproxy是基于單進(jìn)程模型，沒有提供天然的多進(jìn)程擴(kuò)展。雖然可以通過fork進(jìn)程來實(shí)現(xiàn)多進(jìn)程模型，但是會(huì)引起一些問題，因此官方并不推薦這種做法。在實(shí)際應(yīng)用中一般都是把它作為一個(gè)單進(jìn)程負(fù)載均衡服務(wù)使用。

優(yōu)缺點(diǎn)分析

優(yōu)點(diǎn)：可以同時(shí)支持四層，七層負(fù)載均衡，有很高的性能。支持Seesion Sticky，有良好的監(jiān)控頁面，同時(shí)不存在Post緩存問題。

缺點(diǎn)：由于Haproxy是基于但進(jìn)程模型，在reload時(shí)會(huì)導(dǎo)致短暫的不可用，同時(shí)不支持https。在作為四層四層負(fù)載均衡服務(wù)器時(shí)無法獲取原始IP。單進(jìn)程模型，對(duì)多核支持不好（需要多個(gè)實(shí)例），雖然可以運(yùn)作在多核模式下，但存在著一些問題。

應(yīng)用場(chǎng)景：

作為四層負(fù)載均衡服務(wù)，可以直接接后端服務(wù)使用，但由于是采用雙臂模式和單進(jìn)程模型，并不適合作為單獨(dú)的流量入口。在不需要獲取源IP或者對(duì)性能要求不是很高的情況下作為四層負(fù)載均衡服務(wù)器使用?；蛘咦鳛槠邔迂?fù)載均衡服務(wù)器，專門處理七層的上傳請(qǐng)求。

Apache

Apache 起初由伊利諾伊大學(xué)香檳分校的國(guó)家超級(jí)電腦應(yīng)用中心（NCSA）開發(fā)，是現(xiàn)在互聯(lián)網(wǎng)中使用最熱門和訪問量最大的HTTP服務(wù)器，同時(shí)還可以通過加載模塊來完成反向代理功能，但嚴(yán)格來說Apache并不是一個(gè)很好的負(fù)載均衡服務(wù)器，在性能，功能上與較為專業(yè)的負(fù)載均衡服務(wù)相比并無優(yōu)勢(shì)，而功能也乏善可陳。但是考慮到Apache的廣泛應(yīng)用以及基于Apache的負(fù)載均衡服務(wù)在實(shí)際的生產(chǎn)環(huán)境中還是有不少應(yīng)用。

功能介紹：

Apache是一個(gè)web服務(wù)器，通過可以通過加載模塊來實(shí)現(xiàn)負(fù)載均衡服務(wù)。作為一個(gè)強(qiáng)大的web服務(wù)器，Apache在解析HTTP協(xié)議有天然的優(yōu)勢(shì)，支持基于域名分流，URL分析，URL重寫，轉(zhuǎn)發(fā)等功能。

Apache支持兩種模式的負(fù)載均衡：基于mod_proxy模塊的一般負(fù)載均衡和基于mod_proxy_ajp模塊的二進(jìn)制負(fù)載均衡。這兩種模式的主要區(qū)別在于Apache和后端服務(wù)之間的連接方式。一般的負(fù)載均衡是采用HTTP協(xié)議，使用文本傳輸，而ajp模式則采用二進(jìn)制模式，因此性能上會(huì)更好。但相對(duì)的，AJP模式需要后端服務(wù)器的支持，在一般應(yīng)用時(shí)，會(huì)通過跟tomcat結(jié)合來提供負(fù)載均衡服務(wù)。

優(yōu)缺點(diǎn)分析

優(yōu)點(diǎn)：Apache是應(yīng)用最廣的web服務(wù)器，因此在服務(wù)應(yīng)用上面有著天然的優(yōu)勢(shì)。而Apache+Tomcat的模式可以滿足現(xiàn)在大部分網(wǎng)站對(duì)于靜態(tài)資源和動(dòng)態(tài)資源的需求。而作為一個(gè)強(qiáng)大的web服務(wù)器，Apache還支持URL重寫，URL轉(zhuǎn)發(fā)等web服務(wù)相關(guān)的操作，可以對(duì)后端服務(wù)提供更多支持。

缺點(diǎn)：作為負(fù)載均衡服務(wù)器，主要問題是采用的多進(jìn)程模式，每個(gè)連接在處理時(shí)都會(huì)開獨(dú)立的線程，當(dāng)連接請(qǐng)求數(shù)據(jù)很多時(shí)，會(huì)有在處理高并發(fā)時(shí)會(huì)有性能隱患。

應(yīng)用場(chǎng)景：

因?yàn)闊o論從性能還是功能上看，都有更好的選擇，因此Apache一般不會(huì)單獨(dú)作為負(fù)載均衡服務(wù)器使用。一般是采用Apache服務(wù)作為靜態(tài)文件服務(wù)器使用的時(shí)候，使用AJP模塊與后端的Tomcat對(duì)接，提供簡(jiǎn)單的負(fù)載均衡支持。

總結(jié)

本文對(duì)常用的四種負(fù)載均衡服務(wù)進(jìn)行了簡(jiǎn)單的介紹，在之后的文章中，會(huì)對(duì)具體的負(fù)載均衡服務(wù)進(jìn)行更為深入的分析和說明。