北京時(shí)間 3 月 12 日，F(xiàn)5 與 Nginx 宣布了一項(xiàng)最終協(xié)議，根據(jù)該協(xié)議，F(xiàn)5 將收購(gòu) Nginx 的所有已發(fā)行股票，總價(jià)值約為 6.7 億美元。

[[259358]]

此次收購(gòu)已獲得 F5 和 Nginx 董事會(huì)的批準(zhǔn)，預(yù)計(jì)將于 2019 年第二季度完成。收購(gòu)?fù)瓿珊?，Nginx 管理層將加入 F5，現(xiàn)有的辦事處也將繼續(xù)保持開放。

F5 是應(yīng)用交付網(wǎng)絡(luò)(ADN)領(lǐng)域的全球領(lǐng)先廠商，Nginx 是世界上使用最廣泛的第三大網(wǎng)絡(luò)服務(wù)器軟件，僅次于微軟和 Apache，領(lǐng)先于谷歌，其最知名產(chǎn)品 Nginx 是互聯(lián)網(wǎng)上***的 Web 服務(wù)器之一。

作為 Web 服務(wù)的核心，Nginx 堅(jiān)持著開源的形式，意味著任何人都可以按照自己的意愿下載和使用代碼。

近年來，Nginx 將主要精力放在了 Nginx Plus 這項(xiàng)付費(fèi)高級(jí)服務(wù)上，旨在幫助開發(fā)人員在亞馬遜 AWS 和微軟 Azure 云平臺(tái)上構(gòu)建現(xiàn)代應(yīng)用程序。

顯然，這就是 F5 和 Nginx ***的競(jìng)爭(zhēng)角力點(diǎn)，但也是合并收購(gòu)的意義所在。

比如 F5 可以確保其應(yīng)用程序和軟件的高度安全和高性能，但又有一些產(chǎn)品與 Nginx 和 Nginx Plus 展開了直接的競(jìng)爭(zhēng)。

F5 Networks ***執(zhí)行官兼總裁 FrançoisLocoh-Donou 稱贊 Nginx 為領(lǐng)先的軟件應(yīng)用交付和 API 管理解決方案，擁有***的可信度和品牌認(rèn)知度、以及龐大的開源用戶群。

收購(gòu)后，Nginx 品牌及其位于舊金山的總部將繼續(xù)存在，但雙方計(jì)劃推出與 F5 其他安全與應(yīng)用程序監(jiān)控工具的更深度集成。

收購(gòu)聲明指出，此次戰(zhàn)略收購(gòu)和有機(jī)投資，將確保長(zhǎng)期收入和每股盈利增長(zhǎng)。

F5 和 Nginx 將在所有環(huán)境中實(shí)現(xiàn)多云應(yīng)用服務(wù)，提供開發(fā)人員所需的易用性和靈活性，同時(shí)還提供網(wǎng)絡(luò)運(yùn)營(yíng)團(tuán)隊(duì)所需的規(guī)模、安全性和可靠性等能力。

此外，F(xiàn)5 將致力于持續(xù)創(chuàng)新并增加對(duì) Nginx 開源項(xiàng)目的投資，以增強(qiáng) Nginx 廣泛的用戶群體能力。

F5 將通過 F5 安全解決方案增強(qiáng) Nginx 目前的產(chǎn)品，并將 F5 云原生創(chuàng)新與 Nginx 的軟件負(fù)載均衡技術(shù)相集成，從而加速 F5 為現(xiàn)代容器化應(yīng)用提供應(yīng)用服務(wù)的上市時(shí)間。

F5 還將利用其全球銷售團(tuán)隊(duì)、渠道基礎(chǔ)設(shè)施和合作伙伴生態(tài)系統(tǒng)來擴(kuò)展 Nginx 向企業(yè)銷售的機(jī)會(huì)。

對(duì)于本次收購(gòu)，業(yè)界普遍還是比較看好的，看看網(wǎng)友的評(píng)論：

你們認(rèn)為軟件負(fù)載均衡的 Nginx 遇上硬件負(fù)載均衡的 F5，能夠軟硬結(jié)合、一統(tǒng)天下嗎?

常用的負(fù)載均衡開源軟件有 Nginx、LVS、HAProxy，商業(yè)的硬件負(fù)載均衡設(shè)備 F5、Netscale。接下來給大家普及下 LVS、Nginx 及 HAProxy 工作原理。

一文詳解 Nginx、LVS 及 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ù)庫(kù)服務(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ù)庫(kù)一主多從和讀寫分離，采用 LVS+Keepalived 的架構(gòu)。

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 開銷。最終，會(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ú)立且平等的競(jìng)爭(zhēng)來自客戶端的請(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 的 Up Stream 目前支持以下幾種方式：

• 輪詢(默認(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 的移植版本。
• 配置異常簡(jiǎn)單：非常容易上手。配置風(fēng)格跟程序開發(fā)一樣，神一般的配置。
• 非阻塞、高并發(fā)連接：官方測(cè)試能夠支撐 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)存消耗?。禾幚泶蟛l(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ù)器的健康檢查，只支持通過端口來檢測(cè)，不支持通過 url 來檢測(cè)。不支持 Session 的直接保持，但能通過 ip_hash 來解決。

LVS

LVS 是 Linux Virtual Server 的簡(jiǎn)稱，也就是 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è)部分組成：

• 最前端的負(fù)載均衡層，用 Load Balancer 表示。
• 中間的服務(wù)器集群層，用 Server Array 表示。
• ***端的數(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ù)器(Real Server，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ù)載均衡軟件里的性能是***的，對(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ù)庫(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í)施起來就比較復(fù)雜了，相對(duì)而言，Nginx / HAProxy + Keepalived 就簡(jiǎn)單多了。

HAProxy

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

HAProxy 的優(yōu)點(diǎn)能夠補(bǔ)充 Nginx 的一些缺點(diǎn)，比如支持 Session 的保持，Cookie 的引導(dǎo);同時(shí)支持通過獲取指定的 url 來檢測(cè)后端服務(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)行檢測(cè)和負(fù)載均衡，大家可以用 LVS+Keepalived 對(duì) MySQL 主從做負(fù)載均衡。

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

• Round-robin(輪循)
• Weight-round-robin(帶權(quán)輪循)
• Source(原地址保持)
• RI(請(qǐng)求URL)
• RDP-Cookie(根據(jù) cookie)

來源：《一文詳解Nginx、LVS及HAProxy工作原理》轉(zhuǎn)載自linkedkeeper.com，鏈接：http://www.linkedkeeper.com/135.html