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

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

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

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

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

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

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

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

01  硬體負載均衡

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

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

02  軟體負載均衡（l7）

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

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

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

在公網的網域名稱解析中，配置解析到「反向**」。記錄型別是「a」，記錄值是「反向**」的ip。

配置真實提供服務的web應用ip和埠，和負載均衡均衡策略。上圖中的配置是nginx中的示例，負載均衡策略的預設值是輪詢。

03  軟體負載均衡（l4）

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

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

在lvs中新增乙個ip虛擬服務（ipvs），並指定它的ip、埠和負載均衡策略。

將ip虛擬服務關聯到真實的服務上，並指定模式和權重的資訊。（做l4的負載均衡可以使用nat或者fullnat模式）

題外話：lvs的模式一共有四種，除了nat和fullnat（nat的增強版）模式外，它的tun模式可以在l3做負載均衡，dr模式可以在l2做負載均衡，到這個層面其實就和做硬體同處於乙個層次了。並且，隨著層次的深入，雖然對功能性上有所弱化，但是如果不考慮埠的話，單從ip層面的負載均衡來說，用dr模式做，則對資料報的加工介入度會降到最低，因此也是通過軟體做負載均衡能夠達到的效能極致。

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

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

負載均衡這個領域還是以高可用和效能為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和大家一起來梳理一下。很久之前寫過一篇調研服務治理框架的文章，裡面順帶有提到一下，有興趣的小夥伴們可以跳過去看看：《分布式系統中的必備良藥 —— 服務治理》。

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

分布式系統關注點——僅需這一篇，吃透「負載均衡」妥妥的

分布式系統中的必備良藥 —— 服務治理

跨界架構師」（id：zachary_zf）。

定期發表原創內容：架構設計丨分布式系統丨產品丨運營丨一些深度思考。

掃碼加入小圈子 ↓

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

本文長度為3032字，預計讀完需1.1mb流量，建議閱讀8分鐘。前面兩篇 分布式系統關注點 初識 高可用 分布式系統關注點 僅需這一篇，吃透 負載均衡 妥妥的 看完後，相信大家對實現高可用的思路和負載均衡的策略有了一些了解。這篇主要闡述一下在實施的時候主流的一些解決方案。再翻出第一篇中放出的一張圖來...

分布式系統關注點 初識 高可用

本文長度為2042字，建議閱讀6分鐘。所有 包裹的文字，只對第一次出現進行高亮顯示。閱讀目錄咳咳，從這篇開始，正式拉開分布式系統關注點中，我認為第二重要的內容 高可用 本篇的要點主要是明確 高可用 的定義，以及了解在分布式系統下哪些環節要做 高可用 為後續要講的策略 方式方案打下基礎。如有1年以上的...

分布式系統關注點 通過「共識」達成資料一致性

這次準備開啟乙個新的系列來寫了，聊聊分布式系統中的關注點。節奏不會排的太緊湊，計畫兩周一更吧。本文是本系列的第二篇。是前一篇 不知道是不是最通俗易懂的 資料一致性 剖析了 的後續內容。已經對資料一致性問題做了一次剖析，那麼怎麼解決由於故障導致的不一致問題呢？本文會圍繞 共識 這個點展開。一致性問題其...