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

于洋

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

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)討論交流。

您可能比較感興趣

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

藍鯨智云招募合作伙伴

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

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

漫談分布式集群的負載均衡敬請關注

注明:馬哥教育合作伙伴

相關新聞

聯系我們

400-080-6560

在線咨詢:點擊這里給我發消息

郵件:[email protected]

工作時間:周一至周日,09:00-18:30

QR code
云南快乐10分开奖直播