分散式系統關注點：如何去實施負載均衡？

負載均衡分散式系統 · 發表 2018-10-19 14:24:29

摘要：本文長度為3032字，預計讀完需1.1MB流量，建議閱讀8分鐘。前面兩篇《分散式系統關注點——初識「高可用」》、《分散式系統關注點——僅需這一篇，吃透「負載均衡」妥妥的》看完後，相信大家對實現高可用的思路和負載均衡的策略有了一些瞭解。這...

本文長度為 3032字 ，預計讀完需 1.1MB 流量，建議閱讀 8 分鐘。

前面兩篇《 ofollow,noindex">分散式系統關注點——初識「高可用」》、《分散式系統關注點——僅需這一篇，吃透「負載均衡」妥妥的》看完後，相信大家對實現高可用的思路和負載均衡的策略有了一些瞭解。這篇主要闡述一下在實施的時候主流的一些解決方案。

一、為什麼沒有DNS？

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

之前也有的小夥伴問到，為什麼沒有列出DNS？我認為，DNS的本質是解決「domain name --> ip」的問題。雖然DNS除了在公網運用的之外，還會運用於做內網的自定義domain name解析，但是在程式裡單靠它來做負載均衡的話，還是太勉強了。

當然，基於DNS“智慧解析”功能可以做到IP的動態返回，也算起到了負載均衡的作用。但是，由於其本身是一個工作在L3（網路層）的解決方案，所以無法對“埠”進行工作。而一般我們程式之間的通訊很多都會涉及到埠，因此我們本篇先不討論DNS~

二、如何實施？

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

古時候軍隊打仗的時候一般都是拿盾的抗在前面，頂住攻擊。而負載均衡解決方案從某種角度來說也是一個類似盾一般的防禦性設施，因為前提就是要能承載上游過來的流量。因此，越往“前”做負載均衡解決方案，效果肯定會越好，因為受保護的應用範圍越廣。

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

硬體負載均衡

硬體這塊名氣最大的還屬F5（根據ZOL的資料，其在市場佔有率51.44%），大大蓋過了其它幾家硬體商的風頭。此類硬體負載均衡器的特點是“壕”，畢竟是純商業化的東西，投入的資源和精力自然是眾多開源軟體負載均衡所無法比擬的，所以功能非常強大。包含訪問加速、壓縮、安全等等負載均衡之外的許多附加功能。

題外話：如果用F5組網的話，有兩種結構，序列結構和並行結構，也稱為直連模式和旁路模式。前者的優勢在對硬體產生壓力較小、且天然安全性高，而後者對原網路架構的改動較小、且擴充套件性較好。大家在實際的使用中結合自身情況來部署。

“壕”物能夠同時支援L2~L7的轉發，所以上圖中的每一個標註點都可以用硬體來做負載均衡。因此，如果在經濟允許的情況下，直接上F5能解決很多原本需要花更多時間去解決的問題。所以當“時間”的重要度大於“金錢”的時候，建議優先採用硬體方案。

軟體負載均衡（L7）

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

一般情況下，只要對資料庫不濫用，往往我們從「單應用 + 單庫」組合最先需要突破的是應用，變成「多應用 + 單庫」。那麼針對Web應用的L7負載均衡，比較主流的產品是2個Nginx、HAProxy。在L7做負載均衡，最大的特點就是靈活，請求的URL、Header都是我們可以去掌控的，所以我們可以利用其中的任何資訊為負載均衡策略所用。

這一類就是前面圖中的「反向代理」。作為「客戶端」和「Web應用」、「前端」和「後端」之間的橋樑。實際操作中主要做2步：

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

軟體負載均衡（L4）

當「Web應用」所依賴的TCP協議的「服務」需要橫向擴充套件，或者需要做「資料庫」、「分散式快取」的多主、主從叢集時，那麼就需要一個支援L4的負載均衡軟體。這裡最知名的就屬LVS了，1998年5月由章文嵩博士建立，2004年底被納入Lunix核心。也正因為它是核心態的程式，所以相比用Nginx、HAProxy來做L4的負載均衡，在效能、資源的消耗上會更優一些。

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

在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等。

▲點選圖片可檢視大圖

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

負載均衡這個領域還是以高可用和效能為2個最重要因素，下面是小Z推薦的一種組合方式，也是在系統量級達到每小時上億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等軟體除了滿足負載均衡之外，還為高可用相關的做了眾多的考量，後續有機會小Z和大家一起來梳理一下。很久之前寫過一篇調研服務治理框架的文章，裡面順帶有提到一下，有興趣的小夥伴們可以跳過去看看：《分散式系統中的必備良藥 —— 服務治理》。