漫談分布式集群的負載均衡—口水篇
1 什么是分布式集群
為了理解分布式集群這個概念，我們先說說這兩個概念：“集群”和“分布式”。藝術來源于生活，計算機科學亦是如此。我們先通過例子，來了解一下現(xiàn)實生活中的“集群”和“分布式”。
從開餐館說起：你開了一家餐館，自己掌勺后廚(即做菜)。隨著生意越來越好，發(fā)現(xiàn)自己忙不過來。于是你聘請了兩個廚師，你們三位廚師就是一個“集群”。主要的職責是：洗菜、配菜、炒菜。你們關系如下：
隨著生意越來越好，兩種方式增加后廚的生產力：(1)繼續(xù)增加廚師—相當于擴大集群;(2)引入流水線的機制，精細化分工。找人分擔廚師洗菜、配菜等工作。類似下圖。
其實，流水線提現(xiàn)了分而治之的思想。即將一個大任務分解為多個小任務，提高小任務的生產力，從而提高了整體的生產力。而“分布式”解決問題的思路：正是吸取了將大任務分步為多個小任務的思想，才得到通過跨地域的分布解決大問題。
從解決問題的角度，說一下分布式與集群的差異：
- 分布式是以縮短單個任務的執(zhí)行時間來提升效率的;
- 集群則是通過提高單位時間內執(zhí)行的任務數(shù)來提升效率。
從軟件部署的角度，說一下分布式和集群的關系：
- 分布式是指將不同的業(yè)務分布在不同的地方;
- 集群則是將幾臺服務器集中在一起，實現(xiàn)同一業(yè)務;
- 分布式中的每一個節(jié)點，都可以做集群;
- 集群并不一定就是分布式的。
綜上所述，一個較為理想的分布式集群應該是這樣的：一個分布式系統(tǒng)，是通過多個節(jié)點組成的，各節(jié)點都是集群化，并且各集群還是分布式的。
2 什么是負載均衡
一臺服務器的處理能力，主要受限于服務器自身的可擴展硬件能力。所以，在需要處理大量用戶請求的時候，通常都會引入負載均衡器，將多臺普通服務器組成一個系統(tǒng)，來完成高并發(fā)的請求處理任務。
提到的負載均衡，大家都想到了什么?DNS，LVS，nginx，HAProxy，反向代理，還是大名鼎鼎的F5?下面針對這些負載均衡技術做了分類和歸納。
其實上面描述的解決方案，通常都是互聯(lián)網web接入方案的負載均衡。而web的服務方式是：通過簡單易記的域名，屏蔽內部網絡真實服務的IP，從而保證了內部服務器安全和可靠?；谶@種服務方式，服務提供商可以在兩處做負載均衡：
1.DNS解析(查詢式)，域名服務器在進行域名到服務IP反向解析的時候，根據(jù)用戶網絡接入特點等(電信、網通等 )，將就近的服務IP列表返回給用戶。
鵝廠GSLB是這方面的翹楚，大家有興趣可自行km。
2.轉發(fā)式，經過了上面DNS就近接入，當用戶請求到就近服務的IP時。通常的做法是引入轉發(fā)節(jié)點(通常是lvs或者nginx)，通過均衡策略，將數(shù)據(jù)發(fā)送給多臺RS(Real Server)。
在介紹web負載均衡的技術后，小伙伴們有沒有這樣的疑問。分布式系統(tǒng)各節(jié)點間的集群是如何做負載均衡呢?web的負載均衡是否適用于分布式節(jié)點間呢?等等。
其實不同的技術為了解決不同場景的問題，下圖就羅列的常用的負載均衡使用場景。
上圖通過三種顏色(包括圖標和線條)的部分，分別說明了不同場景下的負載均衡。
- 藍色部分：用戶通過DNS查詢式，獲取到了就近接入的業(yè)務服務(GSLB)。
- 綠色部分：將用戶請求集中轉發(fā)的方法，完成了業(yè)務接入層的負載均衡。(LVS)
- 紅色部分：說明了通常分布式系統(tǒng)內部節(jié)點間的負載均衡。
其中，藍色部分和綠色部分就是上面介紹的web負載均衡部分。下面一章我們重點分析一下如何考慮分布式節(jié)點間的負載均衡。
3 分布式集群的負載均衡
分布式各節(jié)點間的集群要做負載均衡的話，完全可以參考web負載均衡的方式來做，即查詢式和轉發(fā)式。但是通常后臺開發(fā)的皮皮蝦們基本不會這么做，根本原因就是不同場景下，考慮的側重點是不同的，導致均衡的方式也有很大的差別。
我們先說一下兩個web服務的基石：簡單和安全。
- 簡單：使用域名的web服務，就是讓用戶通過簡單易記的域名替代IP地址的訪問方式，所以說“簡單”應該說是用戶的訴求。
- 安全：而“安全”是服務提供商的訴求。就是對外服務時***程度上屏蔽內部服務器的IP地址、網絡部署，從而保證內部服務的安全。
針對上述兩點，就需要在提供web服務時部署相應的節(jié)點支撐。如DNS解析，LVS轉發(fā)、ngnix反向代理等。這些節(jié)點在保證服務的簡單和安全時，也對系統(tǒng)服務引入了關鍵路徑，增加了系統(tǒng)服務復雜性。
那么思考一下：分布式的各系統(tǒng)間，需要引入這么多節(jié)點來解決負載均衡的問題嗎?
皮皮蝦們的答案一定是：不需要☺。引入更多的節(jié)點意味越難保證系統(tǒng)的穩(wěn)定性、可靠性。為什么這么說呢?
首先，分布式系統(tǒng)相對于集中式系統(tǒng)，是通過節(jié)點間相互傳遞消息通信協(xié)調工作的。節(jié)點間通信的不可靠性、不穩(wěn)定性是分布式系統(tǒng)常態(tài)。這就導致系統(tǒng)的設計和開發(fā)時，需要針對每一種通信異常都有自身重試、恢復的解決方案。所以，引入更多的節(jié)點就意味著更復雜的重試、容災、恢復等成本。
小伙伴們，有沒有一種出師未捷身先死的感覺呢?oh, my god。還沒有考慮負載均衡，僅僅是分布式系統(tǒng)間穩(wěn)定性和可靠性，就已經很讓人頭疼了呢?所以說分布式的皮皮蝦是苦逼的，落寞的，高貴的。(請珍惜您身旁的每只皮皮蝦☺)
皮皮蝦們不要皮，大司馬出題了。
大司馬：如果敵方打野沒有在小地圖的視野中，那么分布式系統(tǒng)的負載均衡要怎么做呢?
在學習了大司馬的“正方形打野”，“邊緣ob”，“你皮任你皮后”，這個問題我是這么看的。
我：更少的節(jié)點，更簡單可靠的通信模式下，才能較好的完成負載均衡。
大司馬：這位同學你很有靈性嘛。(看不懂段子的，看加粗字字哈☺)
怎么做好負載均衡呢?總結一下上面的段子就是一句話：simple is beautiful.(皮皮蝦耳朵聽出繭子了吧)。
- 更少的節(jié)點：分布式業(yè)務節(jié)點數(shù)，需根據(jù)業(yè)務自身的特點確定。原則是：少且夠用。
- 簡單可靠的通信模式：這里給一個簡單的通信方式，udp請求發(fā)送+ udp服務確認。這種模式下可以減少因tcp鏈接管理造成的服務器資源消耗。
如果自身系統(tǒng)的還是很復雜的話，其實也是有跡可循的。下面我整理一下，考慮負載均衡的要點。大家多多思考，根據(jù)自身業(yè)務特點取舍，最終一定會做出不錯的負載均衡效果。
再強調一個關鍵點，小伙伴們一定要先找到系統(tǒng)中的均衡要點是什么?這里在說一下：請求均衡和數(shù)據(jù)均衡(上圖右下角)。
請求均衡理想效果是：每個RS服務處理的請求是差不多的。
數(shù)據(jù)均衡理想效果是：每個RS服務處理/存儲的數(shù)據(jù)量是差不多的。
公司內部也有很好的均衡算法組件l5/cmlb等(自行km哈)，可以較好支持udp的請求均衡。使用這種組件也有一些限制，大家確認是否適合自己的系統(tǒng)哈。
***，我們回顧負載均衡的本質，小伙伴們千萬不要為了負載均衡而均衡：
- 功能：單臺服務器能力有限。當處理大量用戶請求時，通過需要多臺服務器組成系統(tǒng)，從而完成高并發(fā)的請求處理。
- 描述：N個客戶端訪問M個服務端的問題。(通常：M>1，N>>M)
- 難點：將N的請求/數(shù)據(jù)"均勻"分攤到多個M操作單元上執(zhí)行，關鍵是"均勻"。
同學們，下課啦 !
原文鏈接：https://cloud.tencent.com/community/article/999792
作者：于洋
【本文是51CTO專欄作者“騰訊云技術社區(qū)”的原創(chuàng)稿件，轉載請通過51CTO聯(lián)系原作者獲取授權】
