• DNS輪詢
• LVS負載均衡
  • DR模式
  • NAT模式
  • Full-NAT模式
  • Tunnel模式
• Nginx負載均衡
• LVS 與 Nginx 的區別
• 參考資料

在互聯網+不斷滲透到生活中的今天，各種各樣的網絡服務存在在我們身邊，他們的訪問流量也是大得驚人。一個大型網站（百萬PV以上）想要正常訪問，單單靠一臺服務器是不可能提供穩定服務的。這時候就需要用負載均衡技術將海量的接口請求平均分發到各個服務器上，以減少每臺服務器的壓力。

上面的流程圖展示了從用戶請求和響應的整個路程。用戶按下一個按鈕，一個請求通過網絡轉發到運營商網絡，運營商對其進行DNS解析。如果請求所對應的域名配置了DNS輪詢，那麽運營商將會隨機返回域名對應的一個服務器IP，之後將請求轉發到該服務器上。當請求到達服務器時，首先會達到LVS虛擬服務器，虛擬服務器再根據具體算法轉發給後邊的Nginx服務器。當Nginx接收到請求時，Nginx服務器會根據其配置將請求再次轉發給其後端配置的應用服務器，應用服務器才是最終處理業務請求的地方。

在整個請求過程中，有三種負載均衡技術：第一次是DNS輪詢，第二次是LVS負載均衡，第三次是Nginx負載均衡。

DNS輪詢

DNS輪詢指的是服務提供者在運營商針對某一域名配置了多個提供服務的服務器IP，當用戶請求改域名的接口時，運營商將隨機挑選出一個服務器響應用戶請求。下圖的例子是：有3臺聯通服務器、3臺電信服務器，要實現“聯通用戶流量分攤到3臺聯通服務器、其他用戶流量分攤到電信服務器”這個效果的設置。

DNS由於成本較低，所以一般在小型的網站用的比較多。但是大型的網站一般也會將用它和其他負載均衡的方式結合起來一起使用，DNS輪詢方式提供的IP地址，在大型網站中往往是一個集群的地址，可能是均衡交換機也可能是均衡服務器。我們可以通過nslookup

C:\Users\Administrator>nslookup www.baidu.com
服務器:  UnKnown
Address:  10.10.121.11

非權威應答:
名稱:    www.a.shifen.com
Addresses:  58.217.200.113
          58.217.200.112
Aliases:  www.baidu.com

DNS輪詢的優點是成本低、操作簡單，但是其缺點也是明顯的：

• 服務不穩定。如果某臺服務器宕機，DNS服務器是無法知曉的，仍舊會將訪問分配到此服務器。修改DNS記錄全部生效一般要1-3小時，甚至更久。這就可能會導致某些用戶在服務器發生故障的時候完全無法訪問。
• DNS負載均衡采用的是簡單的輪詢算法，不能區分服務器的差異，不能反映服務器的當前運行狀態，不能做到為性能較好的服務器多分配請求，甚至會出現客戶請求集中在某一臺服務器上的情況。
• 登陸狀態無法保存。如果是需要身份驗證的網站，DNS解析無法將驗證用戶的訪問持久分配到同一服務器。雖然有一定的本地DNS緩存，但是很難保證在用戶訪問期間，本地DNS不過期，而重新查詢服務器並指向了新的服務器，那麽原服務器保存的用戶信息是無法被帶到新服務器的，而且可能被要求重新認證身份，而且來回切換時間長了各臺服務器都保存有用戶不同的信息，對服務器資源也是一種浪費。

正是因為上述存在的缺點，所以DNS一般不會單獨使用，而是配合其他負載均衡方式一起使用。

LVS負載均衡

LVS服務器接收到網絡請求後，會根據配置的算法將請求轉發給後邊的服務器處理。為了實現高可用，一般情況下都會有至少兩臺LVS服務器，它們之間用KeepAlive定時通信。當備用LVS服務器無法接收到主LVS服務器的信息時，備用LVS服務器就認為主LVS已經宕機了，這時候備用LVS將自動切換為主LVS提供服務。

使用LVS架設的服務器集群系統有三個部分組成：最前端的負載均衡層（Loader Balancer），中間的服務器群組層，用Server Array表示，最底層的數據共享存儲層，用Shared Storage表示。在用戶看來所有的應用都是透明的，用戶只是在使用一個虛擬服務器提供的高性能服務。LVS的體系架構如圖：

LVS的各個層次的詳細介紹：

• Load Balancer層：位於整個集群系統的最前端，有一臺或者多臺負載調度器（Director Server）組成，LVS模塊就安裝在Director Server上，而Director的主要作用類似於一個路由器，它含有完成LVS功能所設定的路由表，通過這些路由表把用戶的請求分發給Server Array層的應用服務器（Real Server）上。同時，在Director Server上還要安裝對Real Server服務的監控模塊Ldirectord，此模塊用於監測各個Real Server服務的健康狀況。在Real Server不可用時把它從LVS路由表中剔除，恢復時重新加入。

• Server Array層：由一組實際運行應用服務的機器組成，Real Server可以是WEB服務器、MAIL服務器、FTP服務器、DNS服務器、視頻服務器中的一個或者多個，每個Real Server之間通過高速的LAN或分布在各地的WAN相連接。在實際的應用中，Director Server也可以同時兼任Real Server的角色。

• Shared Storage層：是為所有Real Server提供共享存儲空間和內容一致性的存儲區域，在物理上，一般有磁盤陣列設備組成，為了提供內容的一致性，一般可以通過NFS網絡文件系統共享數 據，但是NFS在繁忙的業務系統中，性能並不是很好，此時可以采用集群文件系統，例如Red hat的GFS文件系統，oracle提供的OCFS2文件系統等。
  從整個LVS結構可以看出，Director Server是整個LVS的核心，目前，用於Director Server的操作系統只能是Linux和FreeBSD，linux2.6內核不用任何設置就可以支持LVS功能，而FreeBSD作為 Director Server的應用還不是很多，性能也不是很好。對於Real Server，幾乎可以是所有的系統平臺，Linux、windows、Solaris、AIX、BSD系列都能很好的支持。

LVS 的IP負載均衡技術是通過IPVS模塊來實現的，IPVS是LVS集群系統的核心軟件，它的主要作用是：安裝在Director Server上，同時在Director Server上虛擬出一個IP地址，用戶必須通過這個虛擬的IP地址訪問服務。這個虛擬IP一般稱為LVS的VIP，即Virtual IP。訪問的請求首先經過VIP到達負載調度器，然後由負載調度器從Real Server列表中選取一個服務節點響應用戶的請求。

當用戶的請求到達負載調度器後，調度器如何將請求發送到提供服務的Real Server節點，而Real Server節點如何返回數據給用戶，是IPVS實現的重點技術，IPVS實現負載均衡機制有三種：DR模式、NAT模式、Full-NAT模式、Tunnel模式，其中DR模式是使用最廣泛的一種。

DR模式

特點：工作在數據鏈路層，由LVS修改請求報文的Mac地址，由RS服務器直接返回響應給客戶端。

• 用戶按下按鈕，發送接口請求，此時網絡數據包關鍵信息為：【源IP：client_ip，目標IP：lvs_ip，Mac地址：lvs_mac_address】
• 當用戶請求到達LVS服務器的時候，LVS服務器直接將改網絡數據包的Mac地址修改為RS服務器的Mac地址，之後將其轉發到RS服務器。此時網絡數據包關鍵信息為：【源IP：client_ip，目標IP：lvs_ip，Mac地址：rs_mac_address】
• 當RS服務器接收到網絡數據包時，RS服務器發現請求報文的Mac地址是自己的地址，就接收報文並進行處理。處理完成之後，將響應報文通過網卡向外發出。此時發出的響應報文數據包關鍵信息為：【源IP：lvs_ip，目標IP：client_ip，Mac地址：rs_mac_address】
• 響應報文最終到達客戶端

這種方式是三種負載調度機制中性能最高最好的，但是必須要求Director Server與Real Server都有一塊網卡連在同一物理網段上。

NAT模式

特點：工作在網絡層，由LVS修改請求報文的目標IP地址以及響應報文的源IP地址，必須經LVS返回給客戶端。

• 用戶按下按鈕，發送接口請求，此時網絡數據包關鍵信息為：【源IP：client_ip，目標IP：lvs_ip，Mac地址：lvs_mac_address】
• 當用戶請求到達LVS服務器的時候，LVS服務器直接將改網絡數據包的目標IP地址修改為RS服務器的IP地址（DNAT技術），之後將其轉發到RS服務器。此時網絡數據包關鍵信息為：【源IP：client_ip，目標IP：rs_ip，Mac地址：lvs_mac_address】（這裏有一個問題，為什麽Mac地址是lvs_mac_address，但數據包就能夠到RS服務器呢？）
• 當RS服務器接收到數據包後對比發現目標IP是自己的IP，於是構建響應報文發送給LVS服務器。此時網絡數據包關鍵信息為：【源IP：rs_ip，目標IP：client_ip，Mac地址：client_mac_address】
• LVS服務器接收到響應報文，修改響應報文的源IP地址為LVS的IP地址，然後響應給客戶端。此時發出的響應報文數據包關鍵信息為：【源IP：lvs_ip，目標IP：client_ip，Mac地址：client_mac_address】
• 響應報文最終到達客戶端

NAT模式要求LVS和RS服務器必須在同一網段內，因此會導致運維上的困難。另外因為每次請求都需要經過LVS服務器，所以LVS服務器的壓力會比較大。

Full-NAT模式

特點：工作在網絡層，在LVS修改請求報文以及響應報文的源IP地址、目標IP地址，必須經LVS返回給客戶端。

• 用戶按下按鈕，發送接口請求。此時網絡數據包關鍵信息為：【源IP：client_ip，目標IP：lvs_ip，Mac地址：lvs_mac_address】
• 當用戶請求到達LVS服務器的時候，LVS服務器直接將改網絡數據包的源目標IP地址修改為LVS服務器的IP地址、目標IP地址修改為RS服務器的IP地址（SNAT技術、DNAT技術），之後將其轉發到RS服務器。此時網絡數據包關鍵信息為：【源IP：lvs_ip，目標IP：rs_ip，Mac地址：lvs_mac_address】
• RS服務器接收到數據包，於是構建響應返回給LVS服務器。此時網絡數據包關鍵信息為：【源IP：rs_ip，目標IP：lvs_ip】
• 當LVS收到RS服務器的響應數據包後，LVS服務器直接將改網絡數據包的源目標IP地址修改為LVS服務器的IP地址、目標IP地址修改為客戶端的IP地址（SNAT技術、DNAT技術）。此時網絡數據包關鍵信息為：【源IP：lvs_ip，目標IP：client_ip】
• 響應報文最終到達客戶端

Full-NAT模式是在NAT基礎上為了解決跨子網問題而誕生的，其通過在網絡層修改源IP地址和目標IP地址來達到不同子網的通信。

Tunnel模式

特點：工作在網絡層，在原有IP報文外多封裝一層IP報文，由RS服務器直接返回響應給客戶端。

• 用戶按下按鈕，發送接口請求。此時網絡數據包關鍵信息為：【源IP：client_ip，目標IP：lvs_ip】
• 當用戶請求到達LVS服務器的時候，LVS服務器直接在原有報文外再次封裝一層IP報文，封裝的源IP地址為lvs_ip，目標IP地址為rs_ip，然後將其轉發到RS服務器。此時網絡數據包關鍵信息為：外部報文-->【源IP：lvs_ip，目標IP：rs_ip】，內部報文-->【源IP：client_ip，目標IP：lvs_ip】。
• RS服務器接收到報文後發現時自己的IP地址，就將報文接收下來。拆除掉最外層的IP報文後，會發現裏面還有一層IP報文，而且目標是lvs_ip，那麽此時RS開始處理此請求，處理完成之後，直接將響應報文發送給客戶端。此時網絡數據包關鍵信息為：【源IP：lvs_ip，目標IP：client_ip】
• 響應報文最終到達客戶端。

其實與LVS相似的流量轉發方案還有HAProxy。LVS與HAProxy都適合用來放在負載均衡的最前端，用於海量流量轉發。在高可用支持上，他們都有對應的高可用方案，LVS與KeepAlive結合實現高可用，而HAProxy與heartbeat實現高可用。在配置難度上，LVS配置比較復雜，而HAProxy相對簡單。在系統支持上，Linux系統對LVS有內核級別的支持，而HAProxy則沒有。在性能上，LVS因為有系統內核級別的支持，所以其可以實現響應數據包不經過LVS，而HAProxy的響應數據包則必須經過HAProxy，這就導致了HAProxy的壓力會比較大，也就是HAProxy性能沒有LVS好。

Nginx負載均衡

當請求經過LVS服務器轉發到達Nginx服務器後，Nginx會根據其負載配置文件將請求轉發到具體的應用服務器進行處理。

與Nginx相似的軟件還有apche、squid、lighttpd等負載均衡軟件，但apache和squid屬於同步模式的反向代理，在大文件的傳輸上會出現阻塞，導致後端服務器連接數過多，最終導致服務器壓力過大。而Nginx和lighttpd則是使用異步模式的反向代理，代理在接受完數據之前不會與後端服務器建立連接，這樣就避免了對後端服務器造成過大壓力。

舉個例子：當用戶上傳一個100M大的文件時，如果用戶網速慢，需要半個小時才能上傳完。如果采用apache、squid這種同步模式的反向代理，那麽在接收過程中代理不僅會與客戶端建立連接，還會有後臺服務器建立連接。如果上傳大文件的用戶一多，那麽後端服務器的壓力就很大。而且因為廣域網（WAN）和局域網（LAN）的傳輸速度差別很大，因此同步方式的反向代理會造成連接資源的浪費。而nginx和lighttpd異步模式的反向代理則是等代理完全接收完數據之後，才與後端服務器建立連接，這樣就大大減少了後端的服務器的壓力。

而nginx和lighttpd的異步模式也略有不同，lighttpd是先收完再轉向客戶瀏覽器，而nginx是邊收數據邊轉向用戶瀏覽器。因此nginx的異步代理模型可以更好地提供高性能的負載均衡，所以現在nginx也是許多企業級網站的首選。

LVS 與 Nginx 的區別

既然LVS和Nginx都能實現負載均衡，那為什麽要將Nginx作為LVS後端機器，而不是LVS作為Nginx的後端機器，他們之間到底有什麽區別呢？

LVS設計就是用來進行流量轉發的，功能比較單一，所以其在流量轉發上性能更高、更穩定。LVS在流量轉發的性能基本達到了F5硬件設備的60%性能，其他幾個10%都有點困難。但也正是因為其效率高、穩定，所以導致了其功能單一，在應用場景方面比較單一。而Nginx功能強大，支持對域名、目錄的解析，這使得其應用場景廣泛。

簡單地說：lvs只做簡單轉發，能做的事情也就很少，nginx功能全面，能滿足很多的業務場景。

所以我們才說LVS更加適合做最前端的流量轉發，擋住海量流量。而Nginx則適合放在應用服務器的上層，用來針對不同的請求進行目錄識別或域名識別，從而達到功能模塊的垂直分割。

參考資料

• Web基礎架構：負載均衡和LVS - 李克華 - 博客園
• squid,nginx,lighttpd反向代理的區別 - TroyHector - 博客園
• lvs與haproxy

億級PV請求的三種負載均衡技術（轉）