一文詳解 LVS、Nginx 及 HAProxy 工作原理( 附大圖 )

當(dāng)前大多數(shù)的互聯(lián)網(wǎng)系統(tǒng)都使用了服務(wù)器集群技術(shù),集群是將相同服務(wù)部署在多臺(tái)服務(wù)器上構(gòu)成一個(gè)集群整體對(duì)外提供服務(wù),這些集群可以是 Web 應(yīng)用服務(wù)器集群,也可以是數(shù)據(jù)庫服務(wù)器集群,還可以是分布式緩存服務(wù)器集群等等。

在實(shí)際應(yīng)用中,在 Web 服務(wù)器集群之前總會(huì)有一臺(tái)負(fù)載均衡服務(wù)器,負(fù)載均衡設(shè)備的任務(wù)就是作為 Web 服務(wù)器流量的入口,挑選最合適的一臺(tái) Web 服務(wù)器,將客戶端的請(qǐng)求轉(zhuǎn)發(fā)給它處理,實(shí)現(xiàn)客戶端到真實(shí)服務(wù)端的透明轉(zhuǎn)發(fā)。

最近幾年很火的「云計(jì)算」以及分布式架構(gòu),本質(zhì)上也是將后端服務(wù)器作為計(jì)算資源、存儲(chǔ)資源,由某臺(tái)管理服務(wù)器封裝成一個(gè)服務(wù)對(duì)外提供,客戶端不需要關(guān)心真正提供服務(wù)的是哪臺(tái)機(jī)器,在它看來,就好像它面對(duì)的是一臺(tái)擁有近乎無限能力的服務(wù)器,而本質(zhì)上,真正提供服務(wù)的,是后端的集群。

LVS、Nginx、HAProxy 是目前使用最廣泛的三種軟件負(fù)載均衡軟件。

一般對(duì)負(fù)載均衡的使用是隨著網(wǎng)站規(guī)模的提升根據(jù)不同的階段來使用不同的技術(shù)。具體的應(yīng)用需求還得具體分析,如果是中小型的 Web 應(yīng)用,比如日 PV 小于1000萬,用 Nginx 就完全可以了;如果機(jī)器不少,可以用 DNS 輪詢,LVS 所耗費(fèi)的機(jī)器還是比較多的;大型網(wǎng)站或重要的服務(wù),且服務(wù)器比較多時(shí),可以考慮用 LVS。

目前關(guān)于網(wǎng)站架構(gòu)一般比較合理流行的架構(gòu)方案:Web 前端采用 Nginx/HAProxy+Keepalived 作負(fù)載均衡器;后端采用 MySQ L數(shù)據(jù)庫一主多從和讀寫分離,采用 LVS+Keepalived 的架構(gòu)。

LVS

LVS 是 Linux Virtual Server 的簡稱,也就是 Linux 虛擬服務(wù)器。現(xiàn)在 LVS 已經(jīng)是 Linux 標(biāo)準(zhǔn)內(nèi)核的一部分,從 Linux2.4 內(nèi)核以后,已經(jīng)完全內(nèi)置了 LVS 的各個(gè)功能模塊,無需給內(nèi)核打任何補(bǔ)丁,可以直接使用 LVS 提供的各種功能。

LVS 自從1998年開始,發(fā)展到現(xiàn)在已經(jīng)是一個(gè)比較成熟的技術(shù)項(xiàng)目了。

LVS 的體系結(jié)構(gòu)

LVS 架設(shè)的服務(wù)器集群系統(tǒng)有三個(gè)部分組成:

(1) 最前端的負(fù)載均衡層,用 Load Balancer 表示

(2) 中間的服務(wù)器集群層,用 Server Array 表示

(3) 最底端的數(shù)據(jù)共享存儲(chǔ)層,用 Shared Storage 表示

LVS 負(fù)載均衡機(jī)制

LVS 不像 HAProxy 等七層軟負(fù)載面向的是 HTTP 包,所以七層負(fù)載可以做的 URL 解析等工作,LVS 無法完成。

LVS 是四層負(fù)載均衡,也就是說建立在 OSI 模型的第四層——傳輸層之上,傳輸層上有我們熟悉的 TCP/UDP,LVS 支持 TCP/UDP 的負(fù)載均衡。因?yàn)?LVS 是四層負(fù)載均衡,因此它相對(duì)于其它高層負(fù)載均衡的解決辦法,比如 DNS 域名輪流解析、應(yīng)用層負(fù)載的調(diào)度、客戶端的調(diào)度等,它的效率是非常高的。

所謂四層負(fù)載均衡 ,也就是主要通過報(bào)文中的目標(biāo)地址和端口。七層負(fù)載均衡 ,也稱為“內(nèi)容交換”,也就是主要通過報(bào)文中的真正有意義的應(yīng)用層內(nèi)容。

LVS 的轉(zhuǎn)發(fā)主要通過修改 IP 地址(NAT 模式,分為源地址修改 SNAT 和目標(biāo)地址修改 DNAT)、修改目標(biāo) MAC(DR 模式)來實(shí)現(xiàn)。

NAT 模式:網(wǎng)絡(luò)地址轉(zhuǎn)換

NAT(Network Address Translation)是一種外網(wǎng)和內(nèi)網(wǎng)地址映射的技術(shù)。

NAT 模式下,網(wǎng)絡(luò)數(shù)據(jù)報(bào)的進(jìn)出都要經(jīng)過 LVS 的處理。LVS 需要作為 RS(真實(shí)服務(wù)器)的網(wǎng)關(guān)。

當(dāng)包到達(dá) LVS 時(shí),LVS 做目標(biāo)地址轉(zhuǎn)換(DNAT),將目標(biāo) IP 改為 RS 的 IP。RS 接收到包以后,仿佛是客戶端直接發(fā)給它的一樣。RS 處理完,返回響應(yīng)時(shí),源 IP 是 RS IP,目標(biāo) IP 是客戶端的 IP。這時(shí) RS 的包通過網(wǎng)關(guān)(LVS)中轉(zhuǎn),LVS 會(huì)做源地址轉(zhuǎn)換(SNAT),將包的源地址改為 VIP,這樣,這個(gè)包對(duì)客戶端看起來就仿佛是 LVS 直接返回給它的。

DR 模式:直接路由

DR 模式下需要 LVS 和 RS 集群綁定同一個(gè) VIP(RS 通過將 VIP 綁定在 loopback 實(shí)現(xiàn)),但與 NAT 的不同點(diǎn)在于:請(qǐng)求由 LVS 接受,由真實(shí)提供服務(wù)的服務(wù)器(RealServer,RS)直接返回給用戶,返回的時(shí)候不經(jīng)過 LVS。

詳細(xì)來看,一個(gè)請(qǐng)求過來時(shí),LVS 只需要將網(wǎng)絡(luò)幀的 MAC 地址修改為某一臺(tái) RS 的 MAC,該包就會(huì)被轉(zhuǎn)發(fā)到相應(yīng)的 RS 處理,注意此時(shí)的源 IP 和目標(biāo) IP 都沒變,LVS 只是做了一下移花接木。RS 收到 LVS 轉(zhuǎn)發(fā)來的包時(shí),鏈路層發(fā)現(xiàn) MAC 是自己的,到上面的網(wǎng)絡(luò)層,發(fā)現(xiàn) IP 也是自己的,于是這個(gè)包被合法地接受,RS 感知不到前面有 LVS 的存在。而當(dāng) RS 返回響應(yīng)時(shí),只要直接向源 IP(即用戶的 IP)返回即可,不再經(jīng)過 LVS。

DR 負(fù)載均衡模式數(shù)據(jù)分發(fā)過程中不修改 IP 地址,只修改 mac 地址,由于實(shí)際處理請(qǐng)求的真實(shí)物理 IP 地址和數(shù)據(jù)請(qǐng)求目的 IP 地址一致,所以不需要通過負(fù)載均衡服務(wù)器進(jìn)行地址轉(zhuǎn)換,可將響應(yīng)數(shù)據(jù)包直接返回給用戶瀏覽器,避免負(fù)載均衡服務(wù)器網(wǎng)卡帶寬成為瓶頸。因此,DR 模式具有較好的性能,也是目前大型網(wǎng)站使用最廣泛的一種負(fù)載均衡手段。

LVS 的優(yōu)點(diǎn)

抗負(fù)載能力強(qiáng)、是工作在傳輸層上僅作分發(fā)之用,沒有流量的產(chǎn)生,這個(gè)特點(diǎn)也決定了它在負(fù)載均衡軟件里的性能最強(qiáng)的,對(duì)內(nèi)存和 cpu 資源消耗比較低。

配置性比較低,這是一個(gè)缺點(diǎn)也是一個(gè)優(yōu)點(diǎn),因?yàn)闆]有可太多配置的東西,所以并不需要太多接觸,大大減少了人為出錯(cuò)的幾率。

工作穩(wěn)定,因?yàn)槠浔旧砜关?fù)載能力很強(qiáng),自身有完整的雙機(jī)熱備方案,如 LVS + Keepalived。

無流量,LVS 只分發(fā)請(qǐng)求,而流量并不從它本身出去,這點(diǎn)保證了均衡器 IO 的性能不會(huì)受到大流量的影響。

應(yīng)用范圍比較廣,因?yàn)?LVS 工作在傳輸層,所以它幾乎可以對(duì)所有應(yīng)用做負(fù)載均衡,包括 http、數(shù)據(jù)庫、在線聊天室等等。

LVS 的缺點(diǎn)

軟件本身不支持正則表達(dá)式處理,不能做動(dòng)靜分離;而現(xiàn)在許多網(wǎng)站在這方面都有較強(qiáng)的需求,這個(gè)是 Nginx、HAProxy + Keepalived 的優(yōu)勢所在。

如果是網(wǎng)站應(yīng)用比較龐大的話,LVS/DR + Keepalived 實(shí)施起來就比較復(fù)雜了,相對(duì)而言,Nginx / HAProxy + Keepalived 就簡單多了。

Nginx

Nginx 是一個(gè)強(qiáng)大的 Web 服務(wù)器軟件,用于處理高并發(fā)的 HTTP 請(qǐng)求和作為反向代理服務(wù)器做負(fù)載均衡。具有高性能、輕量級(jí)、內(nèi)存消耗少,強(qiáng)大的負(fù)載均衡能力等優(yōu)勢。

Nignx 的架構(gòu)設(shè)計(jì)

相對(duì)于傳統(tǒng)基于進(jìn)程或線程的模型(Apache就采用這種模型)在處理并發(fā)連接時(shí)會(huì)為每一個(gè)連接建立一個(gè)單獨(dú)的進(jìn)程或線程,且在網(wǎng)絡(luò)或者輸入/輸出操作時(shí)阻塞。這將導(dǎo)致內(nèi)存和 CPU 的大量消耗,因?yàn)樾缕鹨粋€(gè)單獨(dú)的進(jìn)程或線程需要準(zhǔn)備新的運(yùn)行時(shí)環(huán)境,包括堆和棧內(nèi)存的分配,以及新的執(zhí)行上下文,當(dāng)然,這些也會(huì)導(dǎo)致多余的 CPU 開銷。最終,會(huì)由于過多的上下文切換而導(dǎo)致服務(wù)器性能變差。

反過來,Nginx 的架構(gòu)設(shè)計(jì)是采用模塊化的、基于事件驅(qū)動(dòng)、異步、單線程且非阻塞。

Nginx 大量使用多路復(fù)用和事件通知,Nginx 啟動(dòng)以后,會(huì)在系統(tǒng)中以 daemon 的方式在后臺(tái)運(yùn)行,其中包括一個(gè) master 進(jìn)程,n(n>=1) 個(gè) worker 進(jìn)程。所有的進(jìn)程都是單線程(即只有一個(gè)主線程)的,且進(jìn)程間通信主要使用共享內(nèi)存的方式。

其中,master 進(jìn)程用于接收來自外界的信號(hào),并給 worker 進(jìn)程發(fā)送信號(hào),同時(shí)監(jiān)控 worker 進(jìn)程的工作狀態(tài)。worker 進(jìn)程則是外部請(qǐng)求真正的處理者,每個(gè) worker 請(qǐng)求相互獨(dú)立且平等的競爭來自客戶端的請(qǐng)求。請(qǐng)求只能在一個(gè) worker 進(jìn)程中被處理,且一個(gè) worker 進(jìn)程只有一個(gè)主線程,所以同時(shí)只能處理一個(gè)請(qǐng)求。(原理同 Netty 很像)

Nginx 負(fù)載均衡

Nginx 負(fù)載均衡主要是對(duì)七層網(wǎng)絡(luò)通信模型中的第七層應(yīng)用層上的 http、https 進(jìn)行支持。

Nginx 是以反向代理的方式進(jìn)行負(fù)載均衡的。反向代理(Reverse Proxy)方式是指以代理服務(wù)器來接受 Internet 上的連接請(qǐng)求,然后將請(qǐng)求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器,并將從服務(wù)器上得到的結(jié)果返回給 Internet 上請(qǐng)求連接的客戶端,此時(shí)代理服務(wù)器對(duì)外就表現(xiàn)為一個(gè)服務(wù)器。

Nginx 實(shí)現(xiàn)負(fù)載均衡的分配策略有很多,Nginx 的 upstream 目前支持以下幾種方式:

輪詢(默認(rèn)):每個(gè)請(qǐng)求按時(shí)間順序逐一分配到不同的后端服務(wù)器,如果后端服務(wù)器 down 掉,能自動(dòng)剔除。

weight:指定輪詢幾率,weight 和訪問比率成正比,用于后端服務(wù)器性能不均的情況。

ip_hash:每個(gè)請(qǐng)求按訪問 ip 的 hash 結(jié)果分配,這樣每個(gè)訪客固定訪問一個(gè)后端服務(wù)器,可以解決 session 的問題。

fair(第三方):按后端服務(wù)器的響應(yīng)時(shí)間來分配請(qǐng)求,響應(yīng)時(shí)間短的優(yōu)先分配。

url_hash(第三方):按訪問 url 的 hash 結(jié)果來分配請(qǐng)求,使每個(gè) url 定向到同一個(gè)后端服務(wù)器,后端服務(wù)器為緩存時(shí)比較有效。

Nginx 的優(yōu)點(diǎn)

跨平臺(tái):Nginx 可以在大多數(shù) Unix like OS編譯運(yùn)行,而且也有 Windows 的移植版本

配置異常簡單:非常容易上手。配置風(fēng)格跟程序開發(fā)一樣,神一般的配置

非阻塞、高并發(fā)連接:官方測試能夠支撐5萬并發(fā)連接,在實(shí)際生產(chǎn)環(huán)境中跑到2~3萬并發(fā)連接數(shù)

事件驅(qū)動(dòng):通信機(jī)制采用 epoll 模型,支持更大的并發(fā)連接

Master/Worker 結(jié)構(gòu):一個(gè) master 進(jìn)程,生成一個(gè)或多個(gè) worker 進(jìn)程

內(nèi)存消耗小:處理大并發(fā)的請(qǐng)求內(nèi)存消耗非常小。在3萬并發(fā)連接下,開啟的10個(gè) Nginx 進(jìn)程才消耗150M 內(nèi)存(15M*10=150M)

內(nèi)置的健康檢查功能:如果 Nginx 代理的后端的某臺(tái) Web 服務(wù)器宕機(jī)了,不會(huì)影響前端訪問

節(jié)省帶寬:支持 GZIP 壓縮,可以添加瀏覽器本地緩存的 Header 頭

穩(wěn)定性高:用于反向代理,宕機(jī)的概率微乎其微

Nginx 的缺點(diǎn)

Nginx 僅能支 持http、https 和 Email 協(xié)議,這樣就在適用范圍上面小些,這個(gè)是它的缺點(diǎn)

對(duì)后端服務(wù)器的健康檢查,只支持通過端口來檢測,不支持通過 ur l來檢測。不支持 Session 的直接保持,但能通過 ip_hash 來解決

HAProxy

HAProxy 支持兩種代理模式 TCP(四層)和HTTP(七層),也是支持虛擬主機(jī)的。

HAProxy 的優(yōu)點(diǎn)能夠補(bǔ)充 Nginx 的一些缺點(diǎn),比如支持 Session 的保持,Cookie 的引導(dǎo);同時(shí)支持通過獲取指定的 url 來檢測后端服務(wù)器的狀態(tài)。

HAProxy 跟 LVS 類似,本身就只是一款負(fù)載均衡軟件;單純從效率上來講 HAProxy 會(huì)比 Nginx 有更出色的負(fù)載均衡速度,在并發(fā)處理上也是優(yōu)于 Nginx 的。

HAProxy 支持 TCP 協(xié)議的負(fù)載均衡轉(zhuǎn)發(fā),可以對(duì) MySQL 讀進(jìn)行負(fù)載均衡,對(duì)后端的 MySQL 節(jié)點(diǎn)進(jìn)行檢測和負(fù)載均衡,大家可以用 LVS+Keepalived 對(duì) MySQL 主從做負(fù)載均衡。

HAProxy 負(fù)載均衡策略非常多:Round-robin(輪循)、Weight-round-robin(帶權(quán)輪循)、source(原地址保持)、RI(請(qǐng)求URL)、rdp-cookie(根據(jù)cookie)。

Reference:

鐘武

https://zhongwuzw.github.io

王晨純

http://www.importnew.com/11229.html

周旭龍

http://edisonchou.cnblogs.com

原文:http://www.sohu.com/a/233936157_262549

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。
  • 序言:七十年代末,一起剝皮案震驚了整個(gè)濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,646評(píng)論 6 533
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 98,595評(píng)論 3 418
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,560評(píng)論 0 376
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經(jīng)常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,035評(píng)論 1 314
  • 正文 為了忘掉前任,我火速辦了婚禮,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 71,814評(píng)論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 55,224評(píng)論 1 324
  • 那天,我揣著相機(jī)與錄音,去河邊找鬼。 笑死,一個(gè)胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,301評(píng)論 3 442
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 42,444評(píng)論 0 288
  • 序言:老撾萬榮一對(duì)情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個(gè)月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 48,988評(píng)論 1 335
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 40,804評(píng)論 3 355
  • 正文 我和宋清朗相戀三年,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 42,998評(píng)論 1 370
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,544評(píng)論 5 360
  • 正文 年R本政府宣布,位于F島的核電站,受9級(jí)特大地震影響,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 44,237評(píng)論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,665評(píng)論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,927評(píng)論 1 287
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個(gè)月前我還...
    沈念sama閱讀 51,706評(píng)論 3 393
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對(duì)象是個(gè)殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 47,993評(píng)論 2 374

推薦閱讀更多精彩內(nèi)容

  • 當(dāng)前大多數(shù)的互聯(lián)網(wǎng)系統(tǒng)都使用了服務(wù)器集群技術(shù),集群是將相同服務(wù)部署在多臺(tái)服務(wù)器上構(gòu)成一個(gè)集群整體對(duì)外提供服務(wù),這些...
    JAVA伯樂閱讀 416評(píng)論 0 1
  • 當(dāng)前大多數(shù)的互聯(lián)網(wǎng)系統(tǒng)都使用了服務(wù)器集群技術(shù),集群是將相同服務(wù)部署在多臺(tái)服務(wù)器上構(gòu)成一個(gè)集群整體對(duì)外提供服務(wù),這些...
    IT高薪愛好者閱讀 671評(píng)論 0 0
  • 當(dāng)前大多數(shù)的互聯(lián)網(wǎng)系統(tǒng)都使用了服務(wù)器集群技術(shù),集群是將相同服務(wù)部署在多臺(tái)服務(wù)器上構(gòu)成一個(gè)集群整體對(duì)外提供服務(wù),這些...
    jiangmo閱讀 12,894評(píng)論 3 36
  • 當(dāng)前大多數(shù)的互聯(lián)網(wǎng)系統(tǒng)都使用了服務(wù)器集群技術(shù),集群是將相同服務(wù)部署在多臺(tái)服務(wù)器上構(gòu)成一個(gè)集群整體對(duì)外提供服務(wù),這些...
    LinkedKeeper閱讀 1,101評(píng)論 0 8
  • 【轉(zhuǎn)自】:https://forum.huawei.com/enterprise/zh/thread-478965...
    lxqfirst閱讀 1,789評(píng)論 0 0