分佈式系統關注點——如何去實施「負載均衡」？

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

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

1、爲何沒有DNS？

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

以前也有的小夥伴問到，爲何沒有列出DNS？我認爲，DNS的本質是解決「domain name --> ip」的問題。雖然DNS除了在公網運用的以外，還會運用於作內網的自定義domain name解析，可是在程序裏單靠它來作負載均衡的話，仍是太勉強了。

固然，基於DNS「智能解析」功能能夠作到IP的動態返回，也算起到了負載均衡的做用。可是，因爲其自己是一個工做在L3（網絡層）的解決方案，因此沒法對「端口」進行工做。而通常咱們程序之間的通信不少都會涉及到端口，所以咱們本篇先不討論DNS~

2、如何實施？

在清楚了咱們應該在哪些環節考慮作負載均衡以後，接下去就是思考如何可以按部就班的進行。

古時候軍隊打仗的時候通常都是拿盾的抗在前面，頂住攻擊。而負載均衡解決方案從某種角度來講也是一個相似盾通常的防護性設施，由於前提就是要能承載上游過來的流量。所以，越往「前」作負載均衡解決方案，效果確定會越好，由於受保護的應用範圍越廣。


若是說，系統以前沒有運用過負載均衡，如今開始第一次作，該如何選擇呢？小Z根據心目當中的優先級來和你們聊一下。

01  硬件負載均衡

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

題外話：若是用F5組網的話，有兩種結構，串行結構和並行結構，也稱爲直連模式和旁路模式。前者的優點在對硬件產生壓力較小、且自然安全性高，然後者對原網絡架構的改動較小、且擴展性較好。你們在實際的使用中結合自身狀況來部署。

「壕」物可以同時支持L2~L7的轉發，因此上圖中的每個標註點均可以用硬件來作負載均衡。所以，若是在經濟容許的狀況下，直接上F5能解決不少本來須要花更多時間去解決的問題。因此當「時間」的重要度大於「金錢」的時候，建議優先採用硬件方案。

02  軟件負載均衡（L7）

當「金錢」的重要程度大於「時間」的時候，咱們能夠經過軟件來達到咱們要的效果。相應的，也增長了一些運維成本。


通常狀況下，只要對數據庫不濫用，每每咱們從「單應用 + 單庫」組合最早須要突破的是應用，變成「多應用 + 單庫」。那麼針對Web應用的L7負載均衡，比較主流的產品是2個Nginx、HAProxy。在L7作負載均衡，最大的特色就是靈活，請求的URL、Header都是咱們能夠去掌控的，因此咱們能夠利用其中的任何信息爲負載均衡策略所用。


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

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

03  軟件負載均衡（L4）

當「Web應用」所依賴的TCP協議的「服務」須要橫向擴展，或者須要作「數據庫」、「分佈式緩存」的多主、主從集羣時，那麼就須要一個支持L4的負載均衡軟件。這裏最知名的就屬LVS了，1998年5月由章文嵩博士創建，2004年末被歸入Lunix內核。也正由於它是內核態的程序，因此相比用Nginx、HAProxy來作L4的負載均衡，在性能、資源的消耗上會更優一些。

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

1. 在LVS中添加一個IP虛擬服務（IPVS），並指定它的IP、端口和負載均衡策略。
2. 將IP虛擬服務關聯到真實的服務上，並指定模式和權重的信息。（作L4的負載均衡可使用NAT或者FULLNAT模式）

題外話：LVS的模式一共有四種，除了NAT和FULLNAT（NAT的加強版）模式外，它的TUN模式能夠在L3作負載均衡，DR模式能夠在L2作負載均衡，到這個層面其實就和作硬件同處於一個層次了。而且，隨着層次的深刻，雖然對功能性上有所弱化，可是若是不考慮端口的話，單從IP層面的負載均衡來講，用DR模式作，則對數據包的加工介入度會降到最低，所以也是經過軟件作負載均衡可以達到的性能極致。

另外，LVS中運用的虛擬IP概念，本質上和Nginx中的「server」概念同樣，定義了一個統一入口，做用上並無差異。將Nginx中的upstream關聯到server，就如LVS操做步驟第2點中的關聯通常。

這些每一個具體的解決方案的使用教程網上比較多，就不展開了，你們實際用到的時候自行查閱一下，固然儘可能優先看官方的。

3、優缺點

作了一個苦差事，把全部同類型的產品都整合了一下優缺點和使用場景。不過，其中有很多是我沒用過的，因此僅供你們參考。順手將一些網上處處充斥的一些過期結論作了更新，如：Nginx不支持session sticky等。

咱們能夠看到，不一樣的解決方案有不一樣的側重點。所以在單個解決方案已經沒法知足的狀況下，咱們能夠組合使用，各盡所長。


負載均衡這個領域仍是以高可用和性能爲2個最重要因素，下面是小Z推薦的一種組合方式，也是在系統量級達到每小時上億PV以後最被普遍使用的一種。理論上，利用第一步DNS的域名解析所帶的負載均衡效果，只要複製多套LVS主備出來，綁上多個不一樣的虛IP，能夠作到無限橫向擴展，以支撐不斷增加的流量。

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

關於LVS的模式選擇，若是在同網段內的話優先使用DR模式進行L2轉發，性能最好。不然使用TUN模式進行L3分發。與此同時，在L四、L7的分發上使用Nginx來作，能夠發揮其靈活易擴展的特色以及其它的一些額外特性如緩存等，也算是物盡其用。


雲時代，service mesh風興起。以sidecar模式爲核心的後起之秀Linkerd、Conduit、NginMesh、Istio等軟件除了知足負載均衡以外，還爲高可用相關的作了衆多的考量，後續有機會小Z和你們一塊兒來梳理一下。好久以前寫過一篇調研服務治理框架的文章，裏面順帶有提到一下，有興趣的小夥伴們能夠跳過去看看：《分佈式系統中的必備良藥 —— 服務治理》。

4、結語

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

---

相關文章：
分佈式系統關注點——初識「高可用」
分佈式系統關注點——僅需這一篇，吃透「負載均衡」妥妥的
分佈式系統中的必備良藥 —— 服務治理

▶ 關於做者：張帆（Zachary）。堅持用心打磨每一篇高質量原創。本文首發於公衆號：「 跨界架構師」（ID：Zachary_ZF）。

微信公衆號（首發）：跨界架構師。<-- 點擊後閱讀熱門文章

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

掃碼加入小圈子 ↓