于洋

05年參加工作，曾在在華為從事電信軟件后臺開發，14年入職騰訊數據平臺部參與消息中間件的開發和設計。對分布式后臺的開發和設計有濃厚興趣。

?

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

1???? 什么是分布式集群

為了理解分布式集群這個概念，我們先說說這兩個概念：“集群”和“分布式”。藝術來源于生活，計算機科學亦是如此。我們先通過例子，來了解一下現實生活中的“集群”和“分布式”。

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

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

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

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

分布式是以縮短單個任務的執行時間來提升效率的；

集群則是通過提高單位時間內執行的任務數來提升效率。

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

分布式是指將不同的業務分布在不同的地方；

集群則是將幾臺服務器集中在一起，實現同一業務；

分布式中的每一個節點，都可以做集群；

集群并不一定就是分布式的。

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

2???? 什么是負載均衡

一臺服務器的處理能力，主要受限于服務器自身的可擴展硬件能力。所以，在需要處理大量用戶請求的時候，通常都會引入負載均衡器，將多臺普通服務器組成一個系統，來完成高并發的請求處理任務。

提到的負載均衡，大家都想到了什么？DNS，LVS，nginx，HAProxy，反向代理，還是大名鼎鼎的F5？下面針對這些負載均衡技術做了分類和歸納。

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

1.???? DNS解析（查詢式），域名服務器在進行域名到服務IP反向解析的時候，根據用戶網絡接入特點等（電信、網通等 ），將就近的服務IP列表返回給用戶。

2.???? 轉發式，經過了上面DNS就近接入，當用戶請求到就近服務的IP時。通常的做法是引入轉發節點（通常是lvs或者nginx），通過均衡策略，將數據發送給多臺RS（Real Server）。

 

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

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

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

藍色部分：用戶通過DNS查詢式，獲取到了就近接入的業務服務（GSLB）。

綠色部分：將用戶請求集中轉發的方法，完成了業務接入層的負載均衡。（LVS）

紅色部分：說明了通常分布式系統內部節點間的負載均衡。

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

3?? 分布式集群的負載均衡

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

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

簡單：使用域名的web服務，就是讓用戶通過簡單易記的域名替代IP地址的訪問方????? 式，所以說“簡單”應該說是用戶的訴求。

 

安全：而“安全”是服務提供商的訴求。就是對外服務時最大程度上屏蔽內部服務器的IP地址、網絡部署，從而保證內部服務的安全。

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

 

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

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

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

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

 

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

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

在學習了大司馬的“正方形打野”，“邊緣ob”，“你皮任你皮后”，這個問題我是這么看的。

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

大司馬：這位同學你很有靈性嘛。（看不懂段子的，看黑體字哦）

 

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

更少的節點：分布式業務節點數，需根據業務自身的特點確定。原則是：少且夠用。

簡單可靠的通信模式：這里給一個簡單的通信方式，udp請求發送 + udp服務確認。這種模式下可以減少因tcp鏈接管理造成的服務器資源消耗。

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

再強調一個關鍵點，小伙伴們一定要先找到系統中的均衡要點是什么？這里在說一下：請求均衡和數據均衡(上圖右下角)。

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

數據均衡理想效果是：每個RS服務處理/存儲的數據量是差不多的。

 

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

功能：單臺服務器能力有限。當處理大量用戶請求時，通過需要多臺服務器組成系統，從而完成高并發的請求處理。

描述：N個客戶端訪問M個服務端的問題。（通常：M>1，N>>M）

難點：將N的請求/數據"均勻"分攤到多個M操作單元上執行，關鍵是"均勻"。

同學們，下課啦~~~

 

PS：由于分布式和負載均衡是兩個比較大的課題，本篇文章講解的內容只是針對具體的場景下闡述。如果沒有講解到小伙伴們想了解的方面，同學們可以自行google，baidu。

藍鯨版本介紹

藍鯨根據不同用戶的需求對外提供了三套版本：

1.社區版：獨立搭建的版本（當前穩定版本為V2.0.1），點擊下載。

2.企業版：針對企業訂制開發的版本，如有需要可聯系藍鯨客服QQ:800802001

3.公有云版：搭建在公有云上的版本，接入入口。

有關藍鯨搭建布署以及使用方面的疑問，可加入QQ群(495299374)討論交流。

您可能比較感興趣

藍鯨智云招募合作伙伴

合作共贏，是騰訊文化中重要的一部分。藍鯨智云團隊計劃在全國范圍內，大力發展生態體系，尋找優質的合作伙伴，共創運維領域的新局面。我們希望為解決方案供應商、集成商、服務商、應用軟件開發商、咨詢機構等提供更多的增值服務。

招募詳情，請點擊“訪問藍鯨官網”。

敬請關注

注明:馬哥教育合作伙伴