上周分享的一篇《僅需這一篇，吃透「負載均衡」妥妥的》相信大家看完后對負載均衡的策略有了一些了解。這篇主要闡述負載均衡在實施的時候一些主流的解決方案。

為什么沒有 DNS?

再翻出第一篇中放出的一張圖來回顧一下。

之前也有小伙伴問到，為什么沒有列出 DNS?我認為，DNS 的本質是解決「domain name --> ip」的問題。

雖然 DNS 除了在公網運用的之外，還會運用于做內網的自定義 domain name 解析，但是在程序里單靠它來做負載均衡的話，還是太勉強了。

當然，基于 DNS 的“智能解析”功能可以做到 IP 的動態返回，也算起到了負載均衡的作用。

但是，由于其本身是一個工作在 L3(網絡層)的解決方案，所以無法對“端口”進行工作。

而一般我們程序之間的通訊很多都會涉及到端口，因此我們本篇先不討論 DNS。

如何實施?

在清楚了我們應該在哪些環節考慮做負載均衡之后，接下去就是思考如何能夠循序漸進的進行。

古時候軍隊打仗的時候一般都是拿盾的扛在前面，頂住攻擊。而負載均衡解決方案從某種角度來說也是一個類似盾一般的防御性設施，因為前提就是要能承載上游過來的流量。

因此，越往“前”做負載均衡解決方案，效果肯定會越好，因為受保護的應用范圍越廣。

如果說，系統之前沒有運用過負載均衡，現在開始第一次做，該如何選擇呢?下面我根據心目當中的優先級來和大家聊一下。

硬件負載均衡

硬件這塊名氣最大的還屬 F5(根據 ZOL 的數據，其在市場占有率 51.44%)，大大蓋過了其他幾家硬件商的風頭。

此類硬件負載均衡器的特點是“壕”，畢竟是純商業化的東西，投入的資源和精力自然是眾多開源軟件負載均衡所無法比擬的，所以功能非常強大。

它們包含訪問加速、壓縮、安全等等負載均衡之外的許多附加功能。

題外話：如果用 F5 組網的話，有兩種結構，串行結構和并行結構，也稱為直連模式和旁路模式。

前者的優勢在對硬件產生壓力較小、且天然安全性高，而后者對原網絡架構的改動較小、且擴展性較好。大家在實際的使用中結合自身情況來部署。

“壕”物能夠同時支持 L2~L7 的轉發，所以上圖中的每一個標注點都可以用硬件來做負載均衡。

因此，如果在經濟允許的情況下，直接上 F5 能解決很多原本需要花更多時間去解決的問題。所以當“時間”的重要度大于“金錢”的時候，建議優先采用硬件方案。

軟件負載均衡(L7)

當“金錢”的重要程度大于“時間”的時候，我們可以通過軟件來達到我們要的效果。相應的，也增加了一些運維成本。

一般情況下，只要對數據庫不濫用，往往我們從「單應用 + 單庫」組合最先需要突破的是應用，變成「多應用 + 單庫」。

那么針對 Web 應用的 L7 負載均衡，比較主流的產品是 2 個 Nginx、HAProxy。

在 L7 做負載均衡，最大的特點就是靈活，請求的 URL、Header 都是我們可以去掌控的，所以我們可以利用其中的任何信息為負載均衡策略所用。

這一類就是前面圖中的「反向代理」。作為「客戶端」和「Web 應用」、「前端」和「后端」之間的橋梁。

實際操作中主要做兩步：

• 在公網的域名解析中，配置解析到「反向代理」。記錄類型是「A」，記錄值是「反向代理」的 IP。
• 配置真實提供服務的 Web 應用 IP 和端口，和負載均衡策略。上圖中的配置是 Nginx 中的示例，負載均衡策略的缺省值是輪詢。

軟件負載均衡(L4)

當「Web 應用」所依賴的 TCP 協議的「服務」需要橫向擴展，或者需要做「數據庫」、「分布式緩存」的多主、主從集群時，那么就需要一個支持 L4 的負載均衡軟件。

這里最知名的就屬 LVS 了，1998 年 5 月由章文嵩博士建立，2004 年底被納入 Linux 內核。

也正因為它是內核態的程序，所以相比用 Nginx、HAProxy 來做 L4 的負載均衡，在性能、資源的消耗上會更優一些。

實際運用中的操作步驟主要也是兩步：

• 在 LVS 中添加一個 IP 虛擬服務(IPVS)，并指定它的 IP、端口和負載均衡策略。
• 將 IP 虛擬服務關聯到真實的服務上，并指定模式和權重的信息。(做 L4 的負載均衡可以使用 NAT 或者 FULLNAT 模式)

題外話：LVS 的模式一共有四種，除了 NAT 和 FULLNAT(NAT 的增強版)模式外，它的 TUN 模式可以在 L3 做負載均衡，DR 模式可以在 L2 做負載均衡，到這個層面其實就和做硬件同處于一個層次了。

并且，隨著層次的深入，雖然對功能性上有所弱化，但是如果不考慮端口的話，單從 IP 層面的負載均衡來說，用 DR 模式做，則對數據包的加工介入度會降到最低，因此也是通過軟件做負載均衡能夠達到的性能極致。

另外，LVS 中運用的虛擬 IP 概念，本質上和 Nginx 中的“Server”概念一樣，定義了一個統一入口，作用上并沒有差別。

將 Nginx中的 upstream 關聯到 Server，就如 LVS 操作步驟第 2 點中的關聯一般。

這些每個具體的解決方案的使用教程網上比較多，就不展開了，大家實際用到的時候自行查閱一下，當然盡量優先看官方的。

優缺點

做了一個苦差事，把所有同類型的產品都整合了一下優缺點和使用場景。不過，其中有不少是我沒用過的，所以僅供大家參考。

順手將一些網上到處充斥的一些過時結論做了更新，如：Nginx 不支持 Session Sticky 等。

我們可以看到，不同的解決方案有不同的側重點。因此在單個解決方案已經無法滿足的情況下，我們可以組合使用，各盡所長。

負載均衡這個領域還是以高可用和性能為兩個最重要因素，下面是我推薦的一種組合方式，也是在系統量級達到每小時上億 PV 之后最被廣泛使用的一種。

理論上，利用第一步 DNS 的域名解析所帶的負載均衡效果，只要復制多套 LVS 主備出來，綁上多個不同的虛 IP，可以做到無限橫向擴展，以支撐不斷增長的流量。

用到的 3 個軟件目前都是開源產品，LVS+Keepalived 負責做 Nginx 的負載均衡，而 Nginx 負責分發實際的請求到 HTTP 和 TCP 協議的應用上。

關于 LVS 的模式選擇，如果在同網段內的話優先使用 DR 模式進行 L2 轉發，性能最好。否則使用 TUN 模式進行 L3 分發。

與此同時，在 L4、L7 的分發上使用 Nginx 來做，可以發揮其靈活易擴展的特點以及其他的一些額外特性如緩存等，也算是物盡其用。

云時代，Service Mesh 風興起。以 Sidecar 模式為核心的后起之秀 Linkerd、Conduit、NginMesh、Istio 等軟件除了滿足負載均衡之外，還為高可用相關的做了眾多的考量。

結語

有些事，并不需要做到一步到位，做技術也是這樣。其實大部分情況下，在以上方案中選擇一個，做一層轉發就夠了。行遠自邇，避免給自己添不必要的麻煩。