[[204999]]

1 什么是分布式集群

為了理解分布式集群這個(gè)概念，我們先說(shuō)說(shuō)這兩個(gè)概念：“集群”和“分布式”。藝術(shù)來(lái)源于生活，計(jì)算機(jī)科學(xué)亦是如此。我們先通過(guò)例子，來(lái)了解一下現(xiàn)實(shí)生活中的“集群”和“分布式”。

從開(kāi)餐館說(shuō)起：你開(kāi)了一家餐館，自己掌勺后廚(即做菜)。隨著生意越來(lái)越好，發(fā)現(xiàn)自己忙不過(guò)來(lái)。于是你聘請(qǐng)了兩個(gè)廚師，你們?nèi)粡N師就是一個(gè)“集群”。主要的職責(zé)是：洗菜、配菜、炒菜。你們關(guān)系如下：

隨著生意越來(lái)越好，兩種方式增加后廚的生產(chǎn)力：(1)繼續(xù)增加廚師—相當(dāng)于擴(kuò)大集群;(2)引入流水線的機(jī)制，精細(xì)化分工。找人分擔(dān)廚師洗菜、配菜等工作。類似下圖。

其實(shí)，流水線提現(xiàn)了分而治之的思想。即將一個(gè)大任務(wù)分解為多個(gè)小任務(wù)，提高小任務(wù)的生產(chǎn)力，從而提高了整體的生產(chǎn)力。而“分布式”解決問(wèn)題的思路：正是吸取了將大任務(wù)分步為多個(gè)小任務(wù)的思想，才得到通過(guò)跨地域的分布解決大問(wèn)題。

從解決問(wèn)題的角度，說(shuō)一下分布式與集群的差異：

• 分布式是以縮短單個(gè)任務(wù)的執(zhí)行時(shí)間來(lái)提升效率的;
• 集群則是通過(guò)提高單位時(shí)間內(nèi)執(zhí)行的任務(wù)數(shù)來(lái)提升效率。

從軟件部署的角度，說(shuō)一下分布式和集群的關(guān)系：

• 分布式是指將不同的業(yè)務(wù)分布在不同的地方;
• 集群則是將幾臺(tái)服務(wù)器集中在一起，實(shí)現(xiàn)同一業(yè)務(wù);
• 分布式中的每一個(gè)節(jié)點(diǎn)，都可以做集群;
• 集群并不一定就是分布式的。

綜上所述，一個(gè)較為理想的分布式集群應(yīng)該是這樣的：一個(gè)分布式系統(tǒng)，是通過(guò)多個(gè)節(jié)點(diǎn)組成的，各節(jié)點(diǎn)都是集群化，并且各集群還是分布式的。

2 什么是負(fù)載均衡

一臺(tái)服務(wù)器的處理能力，主要受限于服務(wù)器自身的可擴(kuò)展硬件能力。所以，在需要處理大量用戶請(qǐng)求的時(shí)候，通常都會(huì)引入負(fù)載均衡器，將多臺(tái)普通服務(wù)器組成一個(gè)系統(tǒng)，來(lái)完成高并發(fā)的請(qǐng)求處理任務(wù)。

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

其實(shí)上面描述的解決方案，通常都是互聯(lián)網(wǎng)web接入方案的負(fù)載均衡。而web的服務(wù)方式是：通過(guò)簡(jiǎn)單易記的域名，屏蔽內(nèi)部網(wǎng)絡(luò)真實(shí)服務(wù)的IP，從而保證了內(nèi)部服務(wù)器安全和可靠?；谶@種服務(wù)方式，服務(wù)提供商可以在兩處做負(fù)載均衡：

1.DNS解析(查詢式)，域名服務(wù)器在進(jìn)行域名到服務(wù)IP反向解析的時(shí)候，根據(jù)用戶網(wǎng)絡(luò)接入特點(diǎn)等(電信、網(wǎng)通等 )，將就近的服務(wù)IP列表返回給用戶。

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

2.轉(zhuǎn)發(fā)式，經(jīng)過(guò)了上面DNS就近接入，當(dāng)用戶請(qǐng)求到就近服務(wù)的IP時(shí)。通常的做法是引入轉(zhuǎn)發(fā)節(jié)點(diǎn)(通常是lvs或者nginx)，通過(guò)均衡策略，將數(shù)據(jù)發(fā)送給多臺(tái)RS(Real Server)。

在介紹web負(fù)載均衡的技術(shù)后，小伙伴們有沒(méi)有這樣的疑問(wèn)。分布式系統(tǒng)各節(jié)點(diǎn)間的集群是如何做負(fù)載均衡呢?web的負(fù)載均衡是否適用于分布式節(jié)點(diǎn)間呢?等等。

其實(shí)不同的技術(shù)為了解決不同場(chǎng)景的問(wèn)題，下圖就羅列的常用的負(fù)載均衡使用場(chǎng)景。

上圖通過(guò)三種顏色(包括圖標(biāo)和線條)的部分，分別說(shuō)明了不同場(chǎng)景下的負(fù)載均衡。

• 藍(lán)色部分：用戶通過(guò)DNS查詢式，獲取到了就近接入的業(yè)務(wù)服務(wù)(GSLB)。
• 綠色部分：將用戶請(qǐng)求集中轉(zhuǎn)發(fā)的方法，完成了業(yè)務(wù)接入層的負(fù)載均衡。(LVS)
• 紅色部分：說(shuō)明了通常分布式系統(tǒng)內(nèi)部節(jié)點(diǎn)間的負(fù)載均衡。

其中，藍(lán)色部分和綠色部分就是上面介紹的web負(fù)載均衡部分。下面一章我們重點(diǎn)分析一下如何考慮分布式節(jié)點(diǎn)間的負(fù)載均衡。

3 分布式集群的負(fù)載均衡

分布式各節(jié)點(diǎn)間的集群要做負(fù)載均衡的話，完全可以參考web負(fù)載均衡的方式來(lái)做，即查詢式和轉(zhuǎn)發(fā)式。但是通常后臺(tái)開(kāi)發(fā)的皮皮蝦們基本不會(huì)這么做，根本原因就是不同場(chǎng)景下，考慮的側(cè)重點(diǎn)是不同的，導(dǎo)致均衡的方式也有很大的差別。

我們先說(shuō)一下兩個(gè)web服務(wù)的基石：簡(jiǎn)單和安全。

• 簡(jiǎn)單：使用域名的web服務(wù)，就是讓用戶通過(guò)簡(jiǎn)單易記的域名替代IP地址的訪問(wèn)方式，所以說(shuō)“簡(jiǎn)單”應(yīng)該說(shuō)是用戶的訴求。
• 安全：而“安全”是服務(wù)提供商的訴求。就是對(duì)外服務(wù)時(shí)***程度上屏蔽內(nèi)部服務(wù)器的IP地址、網(wǎng)絡(luò)部署，從而保證內(nèi)部服務(wù)的安全。

針對(duì)上述兩點(diǎn)，就需要在提供web服務(wù)時(shí)部署相應(yīng)的節(jié)點(diǎn)支撐。如DNS解析，LVS轉(zhuǎn)發(fā)、ngnix反向代理等。這些節(jié)點(diǎn)在保證服務(wù)的簡(jiǎn)單和安全時(shí)，也對(duì)系統(tǒng)服務(wù)引入了關(guān)鍵路徑，增加了系統(tǒng)服務(wù)復(fù)雜性。

那么思考一下：分布式的各系統(tǒng)間，需要引入這么多節(jié)點(diǎn)來(lái)解決負(fù)載均衡的問(wèn)題嗎?

皮皮蝦們的答案一定是：不需要☺。引入更多的節(jié)點(diǎn)意味越難保證系統(tǒng)的穩(wěn)定性、可靠性。為什么這么說(shuō)呢?

首先，分布式系統(tǒng)相對(duì)于集中式系統(tǒng)，是通過(guò)節(jié)點(diǎn)間相互傳遞消息通信協(xié)調(diào)工作的。節(jié)點(diǎn)間通信的不可靠性、不穩(wěn)定性是分布式系統(tǒng)常態(tài)。這就導(dǎo)致系統(tǒng)的設(shè)計(jì)和開(kāi)發(fā)時(shí)，需要針對(duì)每一種通信異常都有自身重試、恢復(fù)的解決方案。所以，引入更多的節(jié)點(diǎn)就意味著更復(fù)雜的重試、容災(zāi)、恢復(fù)等成本。

小伙伴們，有沒(méi)有一種出師未捷身先死的感覺(jué)呢?oh, my god。還沒(méi)有考慮負(fù)載均衡，僅僅是分布式系統(tǒng)間穩(wěn)定性和可靠性，就已經(jīng)很讓人頭疼了呢?所以說(shuō)分布式的皮皮蝦是苦逼的，落寞的，高貴的。(請(qǐng)珍惜您身旁的每只皮皮蝦☺)

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

大司馬：如果敵方打野沒(méi)有在小地圖的視野中，那么分布式系統(tǒng)的負(fù)載均衡要怎么做呢?

在學(xué)習(xí)了大司馬的“正方形打野”，“邊緣ob”，“你皮任你皮后”，這個(gè)問(wèn)題我是這么看的。

我：更少的節(jié)點(diǎn)，更簡(jiǎn)單可靠的通信模式下，才能較好的完成負(fù)載均衡。

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

怎么做好負(fù)載均衡呢?總結(jié)一下上面的段子就是一句話：simple is beautiful.(皮皮蝦耳朵聽(tīng)出繭子了吧)。

• 更少的節(jié)點(diǎn)：分布式業(yè)務(wù)節(jié)點(diǎn)數(shù)，需根據(jù)業(yè)務(wù)自身的特點(diǎn)確定。原則是：少且夠用。
• 簡(jiǎn)單可靠的通信模式：這里給一個(gè)簡(jiǎn)單的通信方式，udp請(qǐng)求發(fā)送+ udp服務(wù)確認(rèn)。這種模式下可以減少因tcp鏈接管理造成的服務(wù)器資源消耗。

如果自身系統(tǒng)的還是很復(fù)雜的話，其實(shí)也是有跡可循的。下面我整理一下，考慮負(fù)載均衡的要點(diǎn)。大家多多思考，根據(jù)自身業(yè)務(wù)特點(diǎn)取舍，最終一定會(huì)做出不錯(cuò)的負(fù)載均衡效果。

再?gòu)?qiáng)調(diào)一個(gè)關(guān)鍵點(diǎn)，小伙伴們一定要先找到系統(tǒng)中的均衡要點(diǎn)是什么?這里在說(shuō)一下：請(qǐng)求均衡和數(shù)據(jù)均衡(上圖右下角)。

請(qǐng)求均衡理想效果是：每個(gè)RS服務(wù)處理的請(qǐng)求是差不多的。

數(shù)據(jù)均衡理想效果是：每個(gè)RS服務(wù)處理/存儲(chǔ)的數(shù)據(jù)量是差不多的。

公司內(nèi)部也有很好的均衡算法組件l5/cmlb等(自行km哈)，可以較好支持udp的請(qǐng)求均衡。使用這種組件也有一些限制，大家確認(rèn)是否適合自己的系統(tǒng)哈。

***，我們回顧負(fù)載均衡的本質(zhì)，小伙伴們千萬(wàn)不要為了負(fù)載均衡而均衡：

• 功能：?jiǎn)闻_(tái)服務(wù)器能力有限。當(dāng)處理大量用戶請(qǐng)求時(shí)，通過(guò)需要多臺(tái)服務(wù)器組成系統(tǒng)，從而完成高并發(fā)的請(qǐng)求處理。
• 描述：N個(gè)客戶端訪問(wèn)M個(gè)服務(wù)端的問(wèn)題。(通常：M>1，N>>M)
• 難點(diǎn)：將N的請(qǐng)求/數(shù)據(jù)"均勻"分?jǐn)偟蕉鄠€(gè)M操作單元上執(zhí)行，關(guān)鍵是"均勻"。

同學(xué)們，下課啦 !

原文鏈接：https://cloud.tencent.com/community/article/999792

作者：于洋

【本文是51CTO專欄作者“騰訊云技術(shù)社區(qū)”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過(guò)51CTO聯(lián)系原作者獲取授權(quán)】

戳這里，看該作者更多好文