LVS和Nginx及HAProxy的工作原理你了解嗎

當前大多數的互聯網系統都使用了服務器集群技術，集群是將相同服務部署在多臺服務器上構成一個集群整體對外提供服務，這些集群可以是Web應用服務器集群，也可以是數據庫服務器集群，還可以是分布式緩存服務器集群等等。

在實際應用中，在Web服務器集群之前總會有一臺負載均衡服務器，負載均衡設備的任務就是作為Web服務器流量的入口，挑選最合適的一臺Web服務器，將客戶端的請求轉發(fā)給它處理，實現客戶端到真實服務端的透明轉發(fā)。

最近幾年很火的「云計算」以及分布式架構，本質上也是將后端服務器作為計算資源、存儲資源，由某臺管理服務器封裝成一個服務對外提供，客戶端不需要關心真正提供服務的是哪臺機器，在它看來，就好像它面對的是一臺擁有近乎無限能力的服務器，而本質上，真正提供服務的，是后端的集群。

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

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

目前關于網站架構一般比較合理流行的架構方案：Web前端采用Nginx/HAProxy+Keepalived作負載均衡器；后端采用MySQL數據庫一主多從和讀寫分離，采用LVS+Keepalived的架構。

LVS

LVS是LinuxVirtualServer的簡稱，也就是Linux虛擬服務器?，F在LVS已經是Linux標準內核的一部分，從Linux2.4內核以后，已經完全內置了LVS的各個功能模塊，無需給內核打任何補丁，可以直接使用LVS提供的各種功能。

LVS自從1998年開始，發(fā)展到現在已經是一個比較成熟的技術項目了。

LVS 的體系結構

LVS架設的服務器集群系統有三個部分組成：

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

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

(3) 最底端的數據共享存儲層，用 Shared Storage 表示

LVS 負載均衡機制

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

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

所謂四層負載均衡，也就是主要通過報文中的目標地址和端口。七層負載均衡，也稱為“內容交換”，也就是主要通過報文中的真正有意義的應用層內容。

LVS的轉發(fā)主要通過修改IP地址（NAT模式，分為源地址修改SNAT和目標地址修改DNAT）、修改目標MAC（DR模式）來實現。

NAT模式：網絡地址轉換

NAT（NetworkAddressTranslation）是一種外網和內網地址映射的技術。

NAT模式下，網絡數據報的進出都要經過LVS的處理。LVS需要作為RS（真實服務器）的網關。

當包到達LVS時，LVS做目標地址轉換（DNAT），將目標IP改為RS的IP。RS接收到包以后，仿佛是客戶端直接發(fā)給它的一樣。RS處理完，返回響應時，源IP是RSIP，目標IP是客戶端的IP。這時RS的包通過網關（LVS）中轉，LVS會做源地址轉換（SNAT），將包的源地址改為VIP，這樣，這個包對客戶端看起來就仿佛是LVS直接返回給它的。

DR模式：直接路由

DR模式下需要LVS和RS集群綁定同一個VIP（RS通過將VIP綁定在loopback實現），但與NAT的不同點在于：請求由LVS接受，由真實提供服務的服務器（RealServer，RS）直接返回給用戶，返回的時候不經過LVS。

詳細來看，一個請求過來時，LVS只需要將網絡幀的MAC地址修改為某一臺RS的MAC，該包就會被轉發(fā)到相應的RS處理，注意此時的源IP和目標IP都沒變，LVS只是做了一下移花接木。RS收到LVS轉發(fā)來的包時，鏈路層發(fā)現MAC是自己的，到上面的網絡層，發(fā)現IP也是自己的，于是這個包被合法地接受，RS感知不到前面有LVS的存在。而當RS返回響應時，只要直接向源IP（即用戶的IP）返回即可，不再經過LVS。

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

LVS 的優(yōu)點

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

配置性比較低，這是一個缺點也是一個優(yōu)點，因為沒有可太多配置的東西，所以并不需要太多接觸，大大減少了人為出錯的幾率。

工作穩(wěn)定，因為其本身抗負載能力很強，自身有完整的雙機熱備方案，如LVS+Keepalived。

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

應用范圍比較廣，因為LVS工作在傳輸層，所以它幾乎可以對所有應用做負載均衡，包括http、數據庫、在線聊天室等等。

LVS 的缺點

軟件本身不支持正則表達式處理，不能做動靜分離；而現在許多網站在這方面都有較強的需求，這個是Nginx、HAProxy+Keepalived的優(yōu)勢所在。

如果是網站應用比較龐大的話，LVS/DR+Keepalived實施起來就比較復雜了，相對而言，Nginx/HAProxy+Keepalived就簡單多了。

Nginx

Nginx是一個強大的Web服務器軟件，用于處理高并發(fā)的HTTP請求和作為反向代理服務器做負載均衡。具有高性能、輕量級、內存消耗少，強大的負載均衡能力等優(yōu)勢。

Nignx 的架構設計

相對于傳統基于進程或線程的模型（Apache就采用這種模型）在處理并發(fā)連接時會為每一個連接建立一個單獨的進程或線程，且在網絡或者輸入/輸出操作時阻塞。這將導致內存和CPU的大量消耗，因為新起一個單獨的進程或線程需要準備新的運行時環(huán)境，包括堆和棧內存的分配，以及新的執(zhí)行上下文，當然，這些也會導致多余的CPU開銷。最終，會由于過多的上下文切換而導致服務器性能變差。

反過來，Nginx的架構設計是采用模塊化的、基于事件驅動、異步、單線程且非阻塞。

Nginx大量使用多路復用和事件通知，Nginx啟動以后，會在系統中以daemon的方式在后臺運行，其中包括一個master進程，n(n>=1)個worker進程。所有的進程都是單線程（即只有一個主線程）的，且進程間通信主要使用共享內存的方式。

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

Nginx 負載均衡

Nginx負載均衡主要是對七層網絡通信模型中的第七層應用層上的http、https進行支持。

Nginx是以反向代理的方式進行負載均衡的。反向代理（ReverseProxy）方式是指以代理服務器來接受Internet上的連接請求，然后將請求轉發(fā)給內部網絡上的服務器，并將從服務器上得到的結果返回給Internet上請求連接的客戶端，此時代理服務器對外就表現為一個服務器。

Nginx實現負載均衡的分配策略有很多，Nginx的upstream目前支持以下幾種方式：

輪詢（默認）：每個請求按時間順序逐一分配到不同的后端服務器，如果后端服務器down掉，能自動剔除。

weight：指定輪詢幾率，weight和訪問比率成正比，用于后端服務器性能不均的情況。

ip_hash：每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個后端服務器，可以解決session的問題。

fair（第三方）：按后端服務器的響應時間來分配請求，響應時間短的優(yōu)先分配。

url_hash（第三方）：按訪問url的hash結果來分配請求，使每個url定向到同一個后端服務器，后端服務器為緩存時比較有效。

Nginx 的優(yōu)點

跨平臺：Nginx可以在大多數UnixlikeOS編譯運行，而且也有Windows的移植版本

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

非阻塞、高并發(fā)連接：官方測試能夠支撐5萬并發(fā)連接，在實際生產環(huán)境中跑到2～3萬并發(fā)連接數

事件驅動：通信機制采用epoll模型，支持更大的并發(fā)連接

Master/Worker結構：一個master進程，生成一個或多個worker進程

內存消耗小：處理大并發(fā)的請求內存消耗非常小。在3萬并發(fā)連接下，開啟的10個Nginx進程才消耗150M內存（15M*10=150M）

內置的健康檢查功能：如果Nginx代理的后端的某臺Web服務器宕機了，不會影響前端訪問

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

穩(wěn)定性高：用于反向代理，宕機的概率微乎其微

Nginx 的缺點

Nginx 僅能支 持http、https 和 Email 協議，這樣就在適用范圍上面小些，這個是它的缺點

對后端服務器的健康檢查，只支持通過端口來檢測，不支持通過url來檢測。不支持Session的直接保持，但能通過ip_hash來解決

HAProxy

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

HAProxy的優(yōu)點能夠補充Nginx的一些缺點，比如支持Session的保持，Cookie的引導；同時支持通過獲取指定的url來檢測后端服務器的狀態(tài)。

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

HAProxy支持TCP協議的負載均衡轉發(fā)，可以對MySQL讀進行負載均衡，對后端的MySQL節(jié)點進行檢測和負載均衡，大家可以用LVS+Keepalived對MySQL主從做負載均衡。

HAProxy負載均衡策略非常多：Round-robin（輪循）、Weight-round-robin（帶權輪循）、source（原地址保持）、RI（請求URL）、rdp-cookie（根據cookie）。