1，什麼是LVS
全稱爲Linux Virtual Server，Linux系統虛擬服務器，主要用於IP層的負載均衡，使用集羣技術爲 Linux 構建高性能、高可用的服務器，提供良好的可擴展性、可靠性和可服務性。
2，分發模式
2.1，什麼是分發模式
用戶發起的請求達到負載均衡服務器後，負載均衡服務器根據已知的後臺服務器列表，按照策略選擇一個後臺機器處理的過程叫負載均衡；將請求轉發給後臺服務器的方式被稱爲分發模式；
LVS支持的分發模式有三種：NAT、DR、TUN。
LVS支持的負載均衡策略有很多，如：無腦輪詢、加權輪詢、最少連接調度、加權最少連接調度、基於IP地址的最少連接調度、目標 IP Hash、源 IP Hash、預期最短延遲等。
接下來咱們先對分發模式展開詳細介紹。
2.2，NAT
首先看下NAT的請求與響應流程。
NAT模式基於NAT技術，該技術主要流程爲：當一個請求到NAT機器後，通過重寫SIP地址、TIP地址，將請求轉發給後臺服務器，後臺服務器處理完畢後將結果給NAT機器，NAT重寫SIP、TIP地址最後將結果響應給用戶。簡單一句話理解爲：NAT作爲一個路由器角色對所有請求、響應重寫SIP、TIP實現IP層負載均衡；
1，假設一個用戶的IP爲：117.117.117.1，LVS的對外的公網IP爲：118.117.117.1；用戶發起請求到LVS上，
2，LVS 通過NAT技術重寫SIP、TIP，將請求轉發給後臺服務器； 3，後臺服務器處理完畢後，將結果響應給LVS，LVS需要再次重寫SIP地址、TIP地址。
4，LVS將結果響應給用戶。
基於NAT技術優點非常明顯，僅需要一個 公網IP 地址就可以完成多臺機器的負載，橫向擴展能力出色（不考慮吞吐量，僅考慮橫向擴展能力的情況下）。
同樣的，缺點也很明顯：可擴展性有限。從上圖中可以很明顯的看出所有請求和響應都會經過LVS，因爲請求包和響應包都需要被負載均衡器重寫，導致LVS很容易成爲系統的瓶頸。假設在一個單核LVS機器上，接收TCP 包的平均長度爲 500Bytes，重寫一個包的平均延遲爲 50us 左右，單臺後臺服務器的平均吞吐量爲 400Kb/s，計算得出LVS機器最大吞吐量爲 9.53 MB/s。單臺LVS最多可以調度 24 臺後臺服務器。
同樣的問題也反映在帶寬上，LVS作用在所有後臺服務器端請求和響應的入口，所需的帶寬是所有後臺服務器響應帶寬的總和。
那如何解決LVS成爲系統瓶頸的問題呢？
不知大家是否留意過，絕大數請求的請求包很小，響應包卻很大；我們根據這個特性繼續往下思考，如果僅處理做流量轉發，即僅處理請求包，響應包交給被轉發的後臺服務器處理，這樣整體負載的性能是否可以成倍提高？於是LVS有了DR(全稱爲Director)、TUN（全稱tunnel）兩種分發模式。
如果還是基於NAT模式，是否還有其他解法呢？
答案是有的，LVS在實際生產環境中系統一般不會存在單機情況，如果LVS可以無限橫向擴容，也可以解決問題(不考慮成本情況下)，那如何實現LVS的橫向擴容呢？答案是多種負載均衡結合，如DNS負載+LVS NAT負載。
NAT模式介紹完畢後，接下來在看看DR模式。
2.3，DR
請求與響應流程：
實現原理：
相對於NAT模式，上圖中多了畫了MAC地址，爲何要畫這個呢？有什麼作用呢？
IP地址： 按照規則爲每臺機分配的唯一邏輯的地址。
MAC地址： 全世界唯一地址，與所在網絡沒關係。
瞭解上面地址的區別後，我們再說爲什麼要畫MAC地址，首先我們看下面這張圖：
畫MAC地址是因爲通過IP地址無法定位到接受請求的網卡，首先通過IP定位到機器，再通過MAC地址找到對應的網卡，可能聰明的你有疑問了，既然MAC地址全球唯一，那爲何還需要IP地址呢？這裏就不做解釋了，有興趣可以閱讀《TCP/IP詳解卷一》。
瞭解上面基礎信息後我們再看來DR的執行流程：
整體流程用戶發起請求到LVS上後，LVS將用戶請求中的SIP和MAC地址作爲轉發請求SIP和MAC，通過負載均衡算法選擇一臺後臺服務器後，將後臺服務器IP和MAC作爲目的地址，給後臺機器營造一個假象：用戶直接發起請求到後臺服務器的，後臺服務器處理完畢後就可以直接將結果響應給用戶了
優點： 可以輕鬆承接海量流量。假設TCP請求包爲500Bytes，響應包爲4KB，轉發一個請求爲10us，那麼負載均衡器每秒最大佔用帶寬47.68MB，但是卻可以支持390.62MB的響應結果，而實際中，經過一些優化後LVS的轉發性能比案例中的高的多，LVS的DR的性能可以輕鬆做到每秒80W的負載。
缺點： 在NAT模式下僅需要一個公網IP，但是在DR模式下，需要爲每一個後臺服務器申請一個公網IP(這裏的後臺服務器一般都是NGINX)。該模式要求被轉發的機器與LVS在同一個物理網段中，因此對被轉發的機器數量受限於IP的最大數量
雖然DR模式解決了NAT模式導致LVS成爲系統瓶頸的問題，但是被轉發機器數量有很大的限制，TUN模式正好結合DR和NAT模式的優點。
2.4，TUN
實現原理：
tun全稱tunnel，翻譯爲隧道。由此可以聯想到IP隧道技術，難道TUN基於IP隧道技術實現的嗎?實時的真相是什麼呢？根據下面描述驗證下猜想吧。
LVS在接受到請求包後，將原始IP包（包含用戶IP和後臺機器IP）作爲數據包在封裝一層，稱爲封裝包，將LVS IP和最終目的IP作爲請求頭和封裝包發送給接收機器，接受機器對請求拆包後得到原始IP包，轉發原始IP包請求，給後臺機器營造一個假象：用戶直接發起請求到本機器的，那麼本機器處理完畢後就可以直接將結果響應給用戶了
看完上面糟糕的介紹後，相信聰明的你已經有了TUN是否基於IP隧道技術的答案，沒錯該模式就是基於IP隧道技術。
請求與響應路程
優點： 結合了NAT和DR的優勢，機器的橫向擴展能力很強。
缺點： 多了一次封包和拆包的過程，性能略低於DR，遠高於NAT；兼容性不高，需要發起方和接受方都支持隧道技術。
至此LVS的三種分發模式已經全部介紹完畢了，下面再看看負載均衡。
3，負載均衡
目前我們常用的負載均衡算法有：
無腦輪詢、加權輪詢、最少連接調度、加權最少連接調度、目標 IP Hash、源 IP Hash。
LVS對常用負載均衡算法支持外，還支持：基於局部機器的最小連接調度、基於局部機器的最小連接複製連接調度算法、最短預期延遲調度、無隊列調度算法。
由於篇幅較多，這裏直接將本人總結好內容通過圖片形式展示出來：
上圖數據來自LVS路由算法直譯。
4，高可用
LVS官網提供了五種高可用的方案，分別是：Keeplived+LVS，Piranha+LVS，UltraMonkey+LVS，heartbeat+mon+coda+LVS，heartbeat+ldirectord；
接下來本文以Keeplived+LVS爲例展開介紹，其他方案感興趣可以自行搜索。
什麼是Keepalived？
作用是檢測服務器的狀態，如果有一臺web服務器宕機，或工作出現故障，Keepalived將檢測到，並將有故障的服務器從系統中剔除，同時使用其他服務器代替該服務器的工作，當服務器工作正常後Keepalived自動將服務器加入到服務器羣中，這些工作全部自動完成，不需要人工干涉，需要人工做的只是修復故障的服務器。
與LVS結合的網絡拓補圖
5，負載均衡補充
5.1，硬件負載均衡和軟件負載均衡
5.1.1，硬件負載均衡
定義： 是通過專門的硬件設備從而來實現負載均衡功能，比如：交換機、路由器就是一個負載均衡專用的網絡設備。
常用硬件負載均衡設備： 目前典型有兩款：F5 和 A10。 優點：
- 功能：支持四層、七層負載均衡及全面負載均衡算法；
- 性能：性能遠超常見的軟件負載均衡器，以F5 BIG-LTM-i10800爲例，四層負載最大吞吐量160GB（數據來自這裏），LVS在以每秒100W負載，響應包3K，最大吞吐量才2.86G；
- 穩定性高：商業設備，質量有相當高的保障，售後服務完善；
- 安全性：除具備負載均衡功能外，還具備防火牆、防 DDoS 攻擊等安全功能；
缺點：
- 價格昂貴：以F5 BIG-LTM-i10800爲例，單臺設備72W+；
- 可擴展性差：如果流量突增，採購設備、負載配置等，那個時候黃花菜都涼了；
5.1.2，軟件負載均衡
常見負載均衡技術： LVS、NGINX、HAproxy、DNS負載。 優點：
- 簡單： 學習成本不高，網上大量的文檔和教程。
- 靈活：可以根據流量大小動態擴容機器。
- 便宜：常見軟件負載都是開源免費，使用普通的機器就可以實現一定量級的負載均衡。 缺點：
- 性能：相對於硬件負載，性能差距好幾個量級。
5.2，分層負載均衡
所謂的分層負載是針對OSI模型的不同層級做負載均衡；我們先來回顧下OSI的分層，具體分層如下圖所示：
雖然OSI嚴格定義了分層結構和功能，但大部分實現卻按照上圖右側四層方式實現，分層負載同樣是這樣。爲了方便理解這裏把實際層級負載對應到OSI分層來介紹。負載分層分別有：二層負載、三層負載、四層負載、七層負載。
| 負載層級 | 實現原理說明 | 常見技術實現 |
|---|---|---|
| 二層負載 | 請求到虛擬MAC（數據鏈路層能夠表示唯一的只有MAC地址），再轉發到真正的MAC主機上。 | 鏈路聚合方法和PPP捆綁 |
| 三層負載 | 相對於二層負載，該層是將MAC地址更換成了IP地址，請求到虛擬IP上，然後再轉發到真正的IP上。 | IP隧道，NAT |
| 四層負載 | IP地址和端口，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。 | LVS |
| 七層負載 | 通過解析7層協議包，根據資源類型、自定義規則等來實現負載。 | NGINX、Apache |
5.3 常見負載均衡對比
| 對比項 | NGINX | LVS | F5 |
|---|---|---|---|
| 負載均衡方式 | TCP/IP協議中的第7層 | TCP/IP協議中的第4層 | 硬件負載 |
| 性能 | 官網宣稱最大負載5w/s | 不同的轉發模式性能差異很大，DR模式一般在50~100w/s左右 | 不同規格差異挺大的，比LVS高出很多倍 |
| 功能 | 除負載均衡外，提供域名解析、靜態資源解析、動態接口轉發、限流、響應壓縮、緩存等功能，可以結合其他語言實現本身不能提供的功能 | 僅包含負載均衡 | 安全防護、負載均衡 |
| 收費情況 | 開源免費 | 開源免費 | 收費，以F5 BIG-LTM-i10800爲例，單機72W+ |
| 安全性 | 限流、黑白IP名單 | - | 具備防火牆，防 DDos 攻擊等安全功能 |
| 支持網絡協議 | http、https和Email | 四層及以上任意協議 | 四層及以上任意協議 |
| 難易程度 | 功能強大，配置較多，有一定的學習成本 | 功能不多，配置較少 | - |
| 負載均衡算法 | 無腦輪詢、加權輪詢、ip_hash、fair、url_hash | 無腦輪詢、加權輪詢、最少連接調度、加權最少連接調度、目標 IP Hash、源 IP Hash、基於局部機器的最小連接調度、基於局部機器的最小連接複製連接調度算法、最短預期延遲調度、無隊列調度算法 | 無腦輪詢、最小的連接數、優先級、自定義規則、流量比例 |
| 擴展性 | 用戶可以根據業務需求動態擴展功能，如：lua-nginx-module | - | - |
| 可用性 | 常用Keeplived+Nignx實現雙機主備 | 官網給出5種高可用方案。Keeplived+LVS實現雙機主備就是一種 | 待研究研究再補充上 |
總結概述：
NGINX：
- 安全性：安全性較高，處於OSI第7層，很容易得到請求IP、URL等信息用於實現安全防護，如限流、黑名單等功能
- 性能相對於四層負載較差：處於OSI第7層，由於需要對協議進行解析+提供功能損耗，官網測試每秒最大負載5W
- 功能強大：提供限流、緩存，域名解析等多重功能，因此有一定學習成本，排查問題依賴經驗
- 高可用：配合Keeplived等技術，輕鬆實現高可用
LVS：
- 性能較高：本身不產生任何流量，對CPU、內存佔用較低。位於OSI第4層，通訊效率高。每秒負載量級爲幾十萬級別
- 簡單易上手：僅提供負載均衡功能，可操作性較少，上手、維護都很容易。
- 安全性：安全性不高，僅做流量轉發，無識別DDOS攻擊等。
- 高可用：配合Keeplived等技術，輕鬆實現高可用
6. FAQ
6.1，LVS 採用 IP 負載均衡技術和基於內容請求分發技術，爲什麼卻說 LVS 是四層負載均衡？
LVS處理的是連接請求，包含IP地址+端口號，端口號的概念在OSI第四層傳輸層纔有。