漫談分布式集群的負載均衡

為了理解分布式集群這個概念，我們先說說這兩個概念：「集群」和「分布式」。藝術**於生活，電腦科學亦是如此。我們先通過例子，來了解一下現實生活中的「集群」和「分布式」。

從開餐館說起：你開了一家餐館，自己掌勺後廚（即做菜）。隨著生意越來越好，發現自己忙不過來。於是你聘請了兩個廚師，你們三位廚師就是乙個「集群」。主要的職責是：洗菜、配菜、炒菜。你們關係如下：

隨著生意越來越好，兩種方式增加後廚的生產力：（1）繼續增加廚師—相當於擴大集群；（2）引入流水線的機制，精細化分工。找人分擔廚師洗菜、配菜等工作。類似下圖。

其實，流水線提現了分而治之的思想。即將乙個大任務分解為多個小任務，提高小任務的生產力，從而提高了整體的生產力。而「分布式」解決問題的思路：正是吸取了將大任務分步為多個小任務的思想，才得到通過跨地域的分布解決大問題。

從解決問題的角度，說一下分布式與集群的差異：

從軟體部署的角度，說一下分布式和集群的關係：

綜上所述，乙個較為理想的分布式集群應該是這樣的：乙個分布式系統，是通過多個節點組成的，各節點都是集群化，並且各集群還是分布式的。

一台伺服器的處理能力，主要受限於伺服器自身的可擴充套件硬體能力。所以，在需要處理大量使用者請求的時候，通常都會引入負載均衡器，將多台普通伺服器組成乙個系統，來完成高併發的請求處理任務。

提到的負載均衡，大家都想到了什麼？dns，lvs，nginx，haproxy，反向**，還是大名鼎鼎的f5？下面針對這些負載均衡技術做了分類和歸納。

其實上面描述的解決方案，通常都是網際網路web接入方案的負載均衡。而web的服務方式是：通過簡單易記的網域名稱，遮蔽內部網路真實服務的ip，從而保證了內部伺服器安全和可靠。基於這種服務方式，服務提供商可以在兩處做負載均衡：

dns解析（查詢式），網域名稱伺服器在進行網域名稱到服務ip反向解析的時候，根據使用者網路接入特點等（電信、網通等），將就近的服務ip列表返回給使用者。

鵝廠gslb是這方面的翹楚，大家有興趣可自行km。

**式，經過了上面dns就近接入，當使用者請求到就近服務的ip時。通常的做法是引入**節點（通常是lvs或者nginx），通過均衡策略，將資料傳送給多台rs（real server）。

在介紹web負載均衡的技術後，小夥伴們有沒有這樣的疑問。分布式系統各節點間的集群是如何做負載均衡呢？web的負載均衡是否適用於分布式節點間呢？等等。

其實不同的技術為了解決不同場景的問題，下圖就羅列的常用的負載均衡使用場景。

上圖通過三種顏色（包括圖示和線條）的部分，分別說明了不同場景下的負載均衡。

其中，藍色部分和綠色部分就是上面介紹的web負載均衡部分。下面一章我們重點分析一下如何考慮分布式節點間的負載均衡。

分布式各節點間的集群要做負載均衡的話，完全可以參考web負載均衡的方式來做，即查詢式和**式。但是通常後台開發的皮皮蝦們基本不會這麼做，根本原因就是不同場景下，考慮的側重點是不同的，導致均衡的方式也有很大的差別。

我們先說一下兩個web服務的基石：簡單和安全。

針對上述兩點，就需要在提供web服務時部署相應的節點支撐。如dns解析，lvs**、ngnix反向**等。這些節點在保證服務的簡單和安全時，也對系統服務引入了關鍵路徑，增加了系統服務複雜性。

那麼思考一下：分布式的各系統間，需要引入這麼多節點來解決負載均衡的問題嗎？

皮皮蝦們的答案一定是：不需要☺。引入更多的節點意味越難保證系統的穩定性、可靠性。為什麼這麼說呢？

首先，分布式系統相對於集中式系統，是通過節點間相互傳遞訊息通訊協調工作的。節點間通訊的不可靠性、不穩定性是分布式系統常態。這就導致系統的設計和開發時，需要針對每一種通訊異常都有自身重試、恢復的解決方案。所以，引入更多的節點就意味著更複雜的重試、容災、恢復等成本。

小夥伴們，有沒有一種出師未捷身先死的感覺呢？oh, my god。還沒有考慮負載均衡，僅僅是分布式系統間穩定性和可靠性，就已經很讓人頭疼了呢？所以說分布式的皮皮蝦是苦逼的，落寞的，高貴的。（請珍惜您身旁的每只皮皮蝦☺）

皮皮蝦們不要皮，大司馬出題了。

大司馬：如果敵方打野沒有在小地圖的視野中，那麼分布式系統的負載均衡要怎麼做呢？

在學習了大司馬的「正方形打野」，「邊緣ob」，「你皮任你皮後」，這個問題我是這麼看的。

我：更少的節點，更簡單可靠的通訊模式下，才能較好的完成負載均衡。

大司馬：這位同學你很有靈性嘛。（看不懂段子的，看加粗字字哈☺）

怎麼做好負載均衡呢？總結一下上面的段子就是一句話：****** is beautiful.（皮皮蝦耳朵聽出繭子了吧）。

如果自身系統的還是很複雜的話，其實也是有跡可循的。下面我整理一下，考慮負載均衡的要點。大家多多思考，根據自身業務特點取捨，最終一定會做出不錯的負載均衡效果。

再強調乙個關鍵點，小夥伴們一定要先找到系統中的均衡要點是什麼？這裡在說一下：請求均衡和資料均衡(上圖右下角)。

請求均衡理想效果是：每個rs服務處理的請求是差不多的。

資料均衡理想效果是：每個rs服務處理/儲存的資料量是差不多的。

公司內部也有很好的均衡演算法元件l5/cmlb等（自行km哈），可以較好支援udp的請求均衡。使用這種元件也有一些限制，大家確認是否適合自己的系統哈。

最後，我們回顧負載均衡的本質，小夥伴們千萬不要為了負載均衡而均衡：