你真的掌握LVS、Nginx及HAProxy工作原理嗎？-魔扣目錄

當(dāng)前大多數(shù)的互聯(lián)網(wǎng)系統(tǒng)都使用了服務(wù)器集群技術(shù)，集群是將相同服務(wù)部署在多臺(tái)服務(wù)器上構(gòu)成一個(gè)集群整體對(duì)外提供服務(wù)。

圖片來(lái)自 Unsplash

這些集群可以是 Web 應(yīng)用服務(wù)器集群，也可以是數(shù)據(jù)庫(kù)服務(wù)器集群，還可以是分布式緩存服務(wù)器集群等等。

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

最近幾年很火的云計(jì)算以及分布式架構(gòu)，本質(zhì)上也是將后端服務(wù)器作為計(jì)算資源、存儲(chǔ)資源，由某臺(tái)管理服務(wù)器封裝成一個(gè)服務(wù)對(duì)外提供，客戶(hù)端不需要關(guān)心真正提供服務(wù)的是哪臺(tái)機(jī)器。

在它看來(lái)，就好像它面對(duì)的是一臺(tái)擁有近乎無(wú)限能力的服務(wù)器，而本質(zhì)上，真正提供服務(wù)的，是后端的集群。

LVS、Nginx、HAProxy 是目前使用很廣泛的三種軟件負(fù)載均衡軟件。一般對(duì)負(fù)載均衡的使用是隨著網(wǎng)站規(guī)模的提升根據(jù)不同的階段來(lái)使用不同的技術(shù)。

具體的應(yīng)用需求還得具體分析，如果是中小型的 Web 應(yīng)用，比如日 PV 小于 1000 萬(wàn)，用 Nginx 就完全可以了。

如果機(jī)器不少，可以用 DNS 輪詢(xún)，LVS 所耗費(fèi)的機(jī)器還是比較多的;大型網(wǎng)站或重要的服務(wù)，且服務(wù)器比較多時(shí)，可以考慮用 LVS。

目前關(guān)于網(wǎng)站架構(gòu)一般比較合理流行的架構(gòu)方案：

Web 前端采用 Nginx/HAProxy+Keepalived 作負(fù)載均衡器。
后端采用 MySQL 數(shù)據(jù)庫(kù)一主多從和讀寫(xiě)分離，采用 LVS+Keepalived 的架構(gòu)。

LVS

LVS 是 linux Virtual Server 的簡(jiǎn)稱(chēng)，也就是 Linux 虛擬服務(wù)器?，F(xiàn)在 LVS 已經(jīng)是 Linux 標(biāo)準(zhǔn)內(nèi)核的一部分。

從 Linux 2.4 內(nèi)核以后，已經(jīng)完全內(nèi)置了 LVS 的各個(gè)功能模塊，無(wú)需給內(nèi)核打任何補(bǔ)丁，可以直接使用 LVS 提供的各種功能。

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

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

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

最前端的負(fù)載均衡層，用 Load Balancer 表示。
中間的服務(wù)器集群層，用 Server Array 表示。
最底端的數(shù)據(jù)共享存儲(chǔ)層，用 Shared Storage 表示。

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

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

LVS 是四層負(fù)載均衡，也就是說(shuō)建立在 OSI 模型的第四層，傳輸層之上，傳輸層上有我們熟悉的 TCP/UDP，LVS 支持 TCP/UDP 的負(fù)載均衡。

因?yàn)?LVS 是四層負(fù)載均衡，因此它相對(duì)于其它高層負(fù)載均衡的解決辦法，比如 DNS 域名輪流解析、應(yīng)用層負(fù)載的調(diào)度、客戶(hù)端的調(diào)度等，它的效率是非常高的。

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

LVS 的轉(zhuǎn)發(fā)主要通過(guò)修改 IP 地址(NAT 模式，分為源地址修改 SNAT 和目標(biāo)地址修改 DNAT)、修改目標(biāo) mac(DR 模式)來(lái)實(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)過(guò) 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 接收到包以后，仿佛是客戶(hù)端直接發(fā)給它的一樣。RS 處理完，返回響應(yīng)時(shí)，源 IP 是 RS IP，目標(biāo) IP 是客戶(hù)端的 IP。

這時(shí) RS 的包通過(guò)網(wǎng)關(guān)(LVS)中轉(zhuǎn)，LVS 會(huì)做源地址轉(zhuǎn)換(SNAT)，將包的源地址改為 VIP，這樣，這個(gè)包對(duì)客戶(hù)端看起來(lái)就仿佛是 LVS 直接返回給它的。

DR 模式：直接路由

DR 模式下需要 LVS 和 RS 集群綁定同一個(gè) VIP(RS 通過(guò)將 VIP 綁定在 loopback 實(shí)現(xiàn))。

但與 NAT 的不同點(diǎn)在于：請(qǐng)求由 LVS 接受，由真實(shí)提供服務(wù)的服務(wù)器(RealServer，RS)直接返回給用戶(hù)，返回的時(shí)候不經(jīng)過(guò) LVS。

詳細(xì)來(lái)看，一個(gè)請(qǐng)求過(guò)來(lái)時(shí)，LVS 只需要將網(wǎng)絡(luò)幀的 MAC 地址修改為某一臺(tái) RS 的 MAC，該包就會(huì)被轉(zhuǎn)發(fā)到相應(yīng)的 RS 處理，注意此時(shí)的源 IP 和目標(biāo) IP 都沒(méi)變，LVS 只是做了一下移花接木。

RS 收到 LVS 轉(zhuǎn)發(fā)來(lái)的包時(shí)，鏈路層發(fā)現(xiàn) MAC 是自己的，到上面的網(wǎng)絡(luò)層，發(fā)現(xiàn) IP 也是自己的，于是這個(gè)包被合法地接受，RS 感知不到前面有 LVS 的存在。

而當(dāng) RS 返回響應(yīng)時(shí)，只要直接向源 IP(即用戶(hù)的 IP)返回即可，不再經(jīng)過(guò) LVS。

DR 負(fù)載均衡模式數(shù)據(jù)分發(fā)過(guò)程中不修改 IP 地址，只修改 Mac 地址，由于實(shí)際處理請(qǐng)求的真實(shí)物理 IP 地址和數(shù)據(jù)請(qǐng)求目的 IP 地址一致，所以不需要通過(guò)負(fù)載均衡服務(wù)器進(jìn)行地址轉(zhuǎn)換。

可將響應(yīng)數(shù)據(jù)包直接返回給用戶(hù)瀏覽器，避免負(fù)載均衡服務(wù)器網(wǎng)卡帶寬成為瓶頸。

因此，DR 模式具有較好的性能，也是目前大型網(wǎng)站使用廣泛的一種負(fù)載均衡手段。

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

抗負(fù)載能力強(qiáng)、是工作在傳輸層上僅作分發(fā)之用，沒(méi)有流量的產(chǎn)生，這個(gè)特點(diǎn)也決定了它在負(fù)載均衡軟件里的性能最強(qiáng)，對(duì)內(nèi)存和 CPU 資源消耗比較低。
配置性比較低，這是一個(gè)缺點(diǎn)也是一個(gè)優(yōu)點(diǎn)，因?yàn)闆](méi)有可太多配置的東西，所以并不需要太多接觸，大大減少了人為出錯(cuò)的幾率。
工作穩(wěn)定，因?yàn)槠浔旧砜关?fù)載能力很強(qiáng)，自身有完整的雙機(jī)熱備方案，如 LVS + Keepalived。
無(wú)流量，LVS 只分發(fā)請(qǐng)求，而流量并不從它本身出去，這點(diǎn)保證了均衡器 IO 的性能不會(huì)受到大流量的影響。
應(yīng)用范圍比較廣，因?yàn)?LVS 工作在傳輸層，所以它幾乎可以對(duì)所有應(yīng)用做負(fù)載均衡，包括 HTTP、數(shù)據(jù)庫(kù)、在線聊天室等等。

LVS 的缺點(diǎn)如下：

軟件本身不支持正則表達(dá)式處理，不能做動(dòng)靜分離;而現(xiàn)在許多網(wǎng)站在這方面都有較強(qiáng)的需求，這個(gè)是 Nginx、HAProxy+Keepalived 的優(yōu)勢(shì)所在。
如果是網(wǎng)站應(yīng)用比較龐大的話，LVS/DR+Keepalived 實(shí)施起來(lái)就比較復(fù)雜了，相對(duì)而言，Nginx/HAProxy+Keepalived 就簡(jiǎn)單多了。

Nginx

Nginx 是一個(gè)強(qiáng)大的 Web 服務(wù)器軟件，用于處理高并發(fā)的 HTTP 請(qǐng)求和作為反向代理服務(wù)器做負(fù)載均衡。

它具有高性能、輕量級(jí)、內(nèi)存消耗少，強(qiáng)大的負(fù)載均衡能力等優(yōu)勢(shì)。

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 開(kāi)銷(xiāo)。

最終，會(huì)由于過(guò)多的上下文切換而導(dǎo)致服務(wù)器性能變差。反過(guò)來(lái)，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)程用于接收來(lái)自外界的信號(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ú)立且平等的競(jìng)爭(zhēng)來(lái)自客戶(hù)端的請(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ù)器來(lái)接受 Internet 上的連接請(qǐng)求，然后將請(qǐng)求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器，并將從服務(wù)器上得到的結(jié)果返回給 Internet 上請(qǐng)求連接的客戶(hù)端，此時(shí)代理服務(wù)器對(duì)外就表現(xiàn)為一個(gè)服務(wù)器。

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

輪詢(xún)(默認(rèn))：每個(gè)請(qǐng)求按時(shí)間順序逐一分配到不同的后端服務(wù)器，如果后端服務(wù)器 Down 掉，能自動(dòng)剔除。
Weight：指定輪詢(xún)幾率，Weight 和訪問(wèn)比率成正比，用于后端服務(wù)器性能不均的情況。
IP_Hash：每個(gè)請(qǐng)求按訪問(wèn) IP 的 Hash 結(jié)果分配，這樣每個(gè)訪客固定訪問(wèn)一個(gè)后端服務(wù)器，可以解決 Session 的問(wèn)題。
Fair(第三方)：按后端服務(wù)器的響應(yīng)時(shí)間來(lái)分配請(qǐng)求，響應(yīng)時(shí)間短的優(yōu)先分配。
URL_Hash(第三方)：按訪問(wèn) URL 的 Hash 結(jié)果來(lái)分配請(qǐng)求，使每個(gè) URL 定向到同一個(gè)后端服務(wù)器，后端服務(wù)器為緩存時(shí)比較有效。

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

跨平臺(tái)：Nginx 可以在大多數(shù) Unix like OS編譯運(yùn)行，而且也有 windows 的移植版本。
配置異常簡(jiǎn)單：非常容易上手。配置風(fēng)格跟程序開(kāi)發(fā)一樣，神一般的配置。
非阻塞、高并發(fā)連接：官方測(cè)試能夠支撐 5 萬(wàn)并發(fā)連接，在實(shí)際生產(chǎn)環(huán)境中跑到 2～3 萬(wàn)并發(fā)連接數(shù)。
事件驅(qū)動(dòng)：通信機(jī)制采用 Epoll 模型，支持更大的并發(fā)連接。
Master/Worker 結(jié)構(gòu)：一個(gè) Master 進(jìn)程，生成一個(gè)或多個(gè) Worker 進(jìn)程。
內(nèi)存消耗?。禾幚泶蟛l(fā)的請(qǐng)求內(nèi)存消耗非常小。在 3 萬(wàn)并發(fā)連接下，開(kāi)啟的 10 個(gè) Nginx 進(jìn)程才消耗 150M 內(nèi)存(15M*10=150M)。
內(nèi)置的健康檢查功能：如果 Nginx 代理的后端的某臺(tái) Web 服務(wù)器宕機(jī)了，不會(huì)影響前端訪問(wèn)。
節(jié)省帶寬：支持 GZIP 壓縮，可以添加瀏覽器本地緩存的 Header 頭。
穩(wěn)定性高：用于反向代理，宕機(jī)的概率微乎其微。

Nginx 的缺點(diǎn)如下：

Nginx 僅能支持 HTTP、HTTPS 、TCP、 Email 等協(xié)議，這樣就在適用范圍上面小些，這個(gè)是它的缺點(diǎn)。
對(duì)后端服務(wù)器的健康檢查，只支持通過(guò)端口來(lái)檢測(cè)，不支持通過(guò) URL 來(lái)檢測(cè)。不支持 Session 的直接保持，但能通過(guò) IP_Hash 來(lái)解決。

HAProxy

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

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

HAProxy 跟 LVS 類(lèi)似，本身就只是一款負(fù)載均衡軟件;單純從效率上來(lái)講 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)行檢測(cè)和負(fù)載均衡，大家可以用 LVS+Keepalived 對(duì) MySQL 主從做負(fù)載均衡。

HAProxy 負(fù)載均衡策略非常多：