如何掌握分布式系統(tǒng)

這篇文章主要講解了“如何掌握分布式系統(tǒng)”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“如何掌握分布式系統(tǒng)”吧！

1. 什么是分布式系統(tǒng)

分布式系統(tǒng)大家從網(wǎng)絡(luò)上看到的學(xué)術(shù)定義簡單來說就是一套由一組計算機協(xié)同工作，讓用戶感覺像是一個統(tǒng)一的整體的系統(tǒng)。

但是，由于這個定義定的過于簡練，很多初入門的人會毫無感知的潛意識就會混淆了分布式系統(tǒng)的概念。

什么意思？我這里問下，當(dāng)我們用 keepalived 做高可用集群的時候，我們是在搞分布式系統(tǒng)嗎？當(dāng)我們并發(fā)不夠，搞了一堆機器做負(fù)載均衡，我們是在搞分布式系統(tǒng)嗎？

當(dāng)你心里默默回答是，或者不清楚是不是的時候，你本身對分布式系統(tǒng)這個概念就已經(jīng)糊涂了。

這里，就需要為分布式系統(tǒng)畫出一個邊界來，并以此告知大家，并不是多臺機器堆在一起了就是分布式系統(tǒng)了。對于剛才那兩個問題，正確的答案就是 keepalived 做的高可用集群，用 Nginx 或者 lvs 后面跟著一堆應(yīng)用集群配合搞的負(fù)載均衡，他們都不是分布式系統(tǒng)，他們就僅僅是個集群而已。

類似的，數(shù)據(jù)庫比如 MySQL 的主從，雙主什么的當(dāng)然也不是分布式系統(tǒng)。因為這些集群少了分布式系統(tǒng)最核心的東西：

應(yīng)用所在服務(wù)器之間的相互協(xié)作

為了說清集群和分布式，我再給大家舉一個通俗易懂的例子：

假設(shè)有一天我開了個軟件公司，公司就我一個程序員，前端、后端、測試的活兒，都是我干，一個月我能做完一個項目。

后來項目多了，我忙不過來了，為了多賺錢，怎么辦呢，我想了兩條路

1. 再招一個和我一樣強的全棧工程師，我倆每個人獨立做項目，這樣我們一個月能做完兩個項目。我倆就組成了一個集群。

2. 招一個前端、一個測試配合我，前端、后端、測試分頭干。通過協(xié)作，我們半個月能干完一個項目。這時候我們的關(guān)系就是分布式。

從上面例子你就能看出:

• 集群中的多個服務(wù)器都在做相同的事情，并不能縮短處理一件事情的時間。

• 而分布式呢，是把事情拆開，多個服務(wù)器分頭做事，可以縮短時間。

知道了什么是分布式系統(tǒng)之后，一個最簡單的分布式系統(tǒng)應(yīng)該是什么樣的？

假設(shè)我們做了一套系統(tǒng)，這套系統(tǒng)僅有兩個功能：1. 注冊、2. 登錄

如果我們想讓這套系統(tǒng)變成分布式系統(tǒng)該怎么做？最簡單的是，把注冊功能和登錄功能分別做成兩套子服務(wù)，然后部署到兩臺服務(wù)器上，讓他們互相協(xié)作，這就變成了一套最簡單的分布式系統(tǒng)。

你看到這里可能會非常震驚：
這就是一套分布式系統(tǒng)了？
我想學(xué)習(xí)的分布式系統(tǒng)的那么多技術(shù)棧呢？
那些高大上的算法呢？
能瞬間閃回的容錯機制呢？
無縫熱升級的功能呢？
問題到底出現(xiàn)在哪里？
我們搭建的這套簡單的系統(tǒng)真的是我們?nèi)粘Ｕ務(wù)摰姆植际较到y(tǒng)嗎？

2. 為什么我們要搞分布式系統(tǒng)

為什么要搞分布式系統(tǒng)？答案很簡單：形勢所迫！一套分布式系統(tǒng)往往是由于業(yè)務(wù)發(fā)展后采取的終極方案。

假如公司新開展了一項在線業(yè)務(wù)，而我們因此要為這套業(yè)務(wù)搭建開發(fā)一套業(yè)務(wù)系統(tǒng)。往往這時候，由于項目前景未知，又由于要快速上線進入市場做試錯，此時，我們可能會優(yōu)先搞一套單體架構(gòu)，先上線。

隨著業(yè)務(wù)的開展和運營，我們往往面臨的第一個問題是系統(tǒng)的崩潰和服務(wù)器的宕機。

這時候，大家就搞一套高可用架構(gòu)來解決問題。把相同的項目部署在多臺機器上，一臺機器出問題了，直接換到另外一臺提供服務(wù)即可。

隨后，由于業(yè)務(wù)進一步的發(fā)展和壯大，此時，出現(xiàn)瓶頸的往往就是系統(tǒng)的響應(yīng)時間了。響應(yīng)時間的增加直接影響了用戶體驗，而這本身也反映了吞吐量出現(xiàn)了瓶頸。

對于這種問題，架構(gòu)師們就會祭出集群大法好的思路來搞定。這時候，系統(tǒng)架構(gòu)開始復(fù)雜了起來，因為別忘了，我們在保證負(fù)載均衡的同時，還需要保證服務(wù)的高可用。

到目前為止，貌似沒什么問題了。我們通過高可用保證了系統(tǒng)的可靠性，通過負(fù)載均衡，分散了系統(tǒng)的壓力。

但是，以上這些方案都不是分布式，系統(tǒng)也不是分布式系統(tǒng)，依然是 Monoliths 這種被一些技術(shù)瘋子們嘲笑的笨重架構(gòu)。

我們還需要分布式嗎？

上圖是某大廠的支付平臺一小部分架構(gòu)圖。

從這張圖可以看出，業(yè)務(wù)發(fā)展到后面會有多么復(fù)雜。面對如此復(fù)雜的業(yè)務(wù)，我們發(fā)現(xiàn)我們之前搞的那種集群怎么也說不過去了。

這時候，就需要進行業(yè)務(wù)的拆分。

雖然業(yè)務(wù)拆分了，但是這些業(yè)務(wù)終究是要對外合作提供一個整體的服務(wù)的，這時候，才是真正需要分布式系統(tǒng)的時候了。我們需要一組在不同的服務(wù)器上相互協(xié)作的系統(tǒng)。

所以我們說，分布式系統(tǒng)是由于業(yè)務(wù)發(fā)展后的終極解決方案。最終，業(yè)務(wù)復(fù)雜到拆分的地步，那么分布式系統(tǒng)就是天然的需求了。

在這里，我們也可以解答下上節(jié)我們面臨的問題了。我們需要的不是簡單的直接把模塊分散部署的無意義分布式，不是簡單的模塊分解。我們需要的是系統(tǒng)在被迫搞成分布式的情況下依然能夠：

1. 保持出色的性能

2. 擁有著無比可靠的可用性

3. 以及非常優(yōu)秀的彈性

而為了保證以上這三個指標(biāo)，就出現(xiàn)了分布式系統(tǒng)那繁雜艱深的技術(shù)棧。

3. 分布式系統(tǒng)的技術(shù)棧

上面我們說了，分布式系統(tǒng)的出現(xiàn)完全是形式所迫，完全是業(yè)務(wù)發(fā)展導(dǎo)致的最終結(jié)果。而由于業(yè)務(wù)的拆分，我們又被迫會衍生出更多的分布式需求來，以及應(yīng)對這些需求的技術(shù)：

• 因為業(yè)務(wù)拆分的多，業(yè)務(wù)對應(yīng)的模塊之間就需要通信，為了保證通信的快速可靠，我們需要掌握分布式通信技術(shù)。

• 業(yè)務(wù)拆分的過多，每個模塊可能還需要搞集群，那么多服務(wù)器資源，為了能夠保證資源的精準(zhǔn)分配，我們還需要考慮分布式資源管理和負(fù)載調(diào)度技術(shù)。

• 業(yè)務(wù)拆分之后，模塊與模塊之間又需要對很多共享數(shù)據(jù)做訪問，為了保證安全完整的數(shù)據(jù)狀態(tài)，我們也要用到分布式協(xié)調(diào)與同步技術(shù)。

• 到了業(yè)務(wù)拆分的階段，數(shù)據(jù)必然龐大，為了數(shù)據(jù)存儲的可靠，為了保證優(yōu)秀的數(shù)據(jù)讀寫性能，我們需要分布式存儲技術(shù)。

• 業(yè)務(wù)如此復(fù)雜，為了公司的發(fā)展，業(yè)務(wù)能繼續(xù)擴大，就需要能更加精準(zhǔn)的營銷和運營，我們還需要對數(shù)據(jù)進行實時、離線處理分析，此時，我們又得考慮分布式計算技術(shù)。

• 在業(yè)務(wù)拆分后，整體架構(gòu)出現(xiàn)了巨變，不可能再用以前集群方式的思維去考慮高可用，那么分布式的可靠性技術(shù)又要納入我們的掌握范疇。

你看分布式系統(tǒng)的技術(shù)棧這么多、這么復(fù)雜對吧，別慌。

我寫這篇文章不是為了勸退你們的，我們要學(xué)習(xí)必須分步驟分主題的學(xué)習(xí)，對整體的分布式技術(shù)棧分而克之，逐步掌握。

4. 如何學(xué)習(xí)分布式系統(tǒng)的技術(shù)棧

在分布式技術(shù)棧中我們可以看到，其實分布式技術(shù)是有分類的，我們可以根據(jù)不同的分類去掌握每種類別的分布式技術(shù)背后的概念和思想。無論分布式技術(shù)有多少實現(xiàn)，這些實現(xiàn)永遠都是以其所在分類的分布式技術(shù)原理作為核心底層來實現(xiàn)的。

同時呢，我們在學(xué)習(xí)當(dāng)中，還必須理論聯(lián)系實際，根據(jù)我們的實際開發(fā)和架構(gòu)需要學(xué)習(xí)。

而且，業(yè)務(wù)是逐步發(fā)展的，項目也不會一下就發(fā)展的特別龐大。這就給與了我們分步學(xué)習(xí)，逐步掌握的時間和機會。

4.1 分布式通信

那具體到底如何做呢？

首先，分布式中的根基是什么？就我自己的經(jīng)歷而言，我認(rèn)為是通信，最重要的其實分布式系統(tǒng)中那些模塊中的通信機制。

而通信機制該怎么學(xué)習(xí)？我認(rèn)為首先要了解我們可用的各通信機制的區(qū)別。其中尤為重要的是了解各通信機制的缺點。對，你沒看錯，就是缺點。

為什么缺點最重要呢？因為架構(gòu)師在架構(gòu)的時候，一項尤為重要的工作就是做技術(shù)選型。而技術(shù)選型的目標(biāo)很多時候的應(yīng)用場景往往非常模糊，如果能了解到各選型的缺點，則對選型的結(jié)果是否準(zhǔn)確就起到了極其重要的作用。

比如，我們現(xiàn)在想搞模塊間通信，那么到底是用 RPC 還是用 MQ ？此時，我們知道 RPC 的缺點和 MQ 的缺點的話，就能很容易做出更準(zhǔn)確的選型。

RPC 的缺點:

1. 不能搞流量削鋒

2. 不能廣播給多個模塊

3. 消息投遞沒有保證

4. 模塊和模塊之間沒法解耦

MQ 的缺點：

1. 不能保證延遲時間

2. 不適合搞強一致性的事務(wù)

3. 增加了系統(tǒng)的復(fù)雜度

4. 降低了系統(tǒng)的可用性

好了，知道了缺點，我們就很容易選型了。如果我們現(xiàn)在有個業(yè)務(wù)是實時扣費，我們肯定要搞 RPC，因為這是延遲敏感并且是需要強一致性。

如果我們現(xiàn)在有個業(yè)務(wù)是同時給會計系統(tǒng)和合作方發(fā)記賬請求的需求，那這時候我們就可能選用 MQ 通信了。

4.2 分布式協(xié)調(diào)和同步

我們理解了分布式通信之后，下一步我認(rèn)為最要學(xué)的是分布式協(xié)調(diào)和同步。

因為在現(xiàn)實里，即使系統(tǒng)搞成分布式了，其實往往沒有特別大，分布式資源管理暫時可以先不考慮。分布式存儲也可能還在使用數(shù)據(jù)庫的主備或者 Sharding 方式在抗。而分布式計算的需求也可能沒有那么緊急。

但是，一旦分布式系統(tǒng)中的全局狀態(tài)出問題了，那就是事故了。所以，理解分布式協(xié)調(diào)和同步，一定是很緊急也很重要的。

那協(xié)調(diào)和同步怎么學(xué)呢？

我們要知道，我們所謂的協(xié)調(diào)數(shù)據(jù)訪問，同步數(shù)據(jù)訪問到底是在做什么。其實協(xié)調(diào)數(shù)據(jù)訪問的本質(zhì)就是去對數(shù)據(jù)訪問的請求做優(yōu)先級排列，這就是協(xié)調(diào)數(shù)據(jù)訪問的本質(zhì)。而如何定義優(yōu)先級？根據(jù)什么定義優(yōu)先級？就是我們需要學(xué)習(xí)的東西。

至于同步，其實就是對數(shù)據(jù)訪問的保護。如何限制對數(shù)據(jù)的訪問？限制數(shù)據(jù)訪問的策略是什么？就是同步的本質(zhì)。

然后，如果我們理解了多線程的數(shù)據(jù)協(xié)調(diào)和同步，我們通過分布式和多線程的相同和區(qū)別，能更容易更快速的去把握好分布式協(xié)調(diào)的技術(shù)本質(zhì)。

4.3 分布式存儲

當(dāng)理解了分布式協(xié)調(diào)和同步之后，我們就應(yīng)該關(guān)注分布式存儲。因為業(yè)務(wù)的核心是數(shù)據(jù)，海量的數(shù)據(jù)最終還需要分布式存儲來解決安全可靠的持久化問題。

而分布式存儲最最重要的是理解什么？不是存儲的各種實現(xiàn)，是分布式存儲的立身之本：CAP 理論。

我們通過對 CAP 理論的理解，去理解分布式存儲實現(xiàn)是如何實現(xiàn)對應(yīng)的 CP 或者 AP 的，就會非常容易了。并且理解了 CAP，我們就能根據(jù)真實的業(yè)務(wù)需求，理解業(yè)務(wù)是需要 CP 還是 AP，然后就能根據(jù)這些，對分布式存儲做合適的選型了。

4.4 分布式計算

當(dāng)學(xué)習(xí)了分布式存儲，此時，我們就應(yīng)該去學(xué)習(xí)分布式計算。因為分布式計算很可能會成為一個重要的運營需求。而分布式計算，就整體而言，一共就四種模式。任你千變?nèi)f化，都逃不掉這四種模式。

從計算方式上看，一共就兩種方法：

1. MR 方式（MapReduce）

2. Stream 方式

從處理過程來看，也只有兩種模式：

1. Actor 模式

2. 流水線模式

4.5 分布式可靠性

到此，在知道了這些知識之后，對于一般公司的架構(gòu)任務(wù)，架構(gòu)師們做起來就游刃有余了。一個完整的正向分布式學(xué)習(xí)流程的知識，其實就差不多了。

此時，我們還需要知道一般的分布式可靠性的處理方案。其實大體也不會超過三種：

1. 對量大的模塊搞負(fù)載均衡的集群；

2. 對某些有資源限制條件的模塊可以搞流量控制；

3. 當(dāng)任何模塊對應(yīng)的服務(wù)器出現(xiàn)問題時，想辦法不讓它影響正常的系統(tǒng)運轉(zhuǎn)，而這個就叫做故障隔離。

而對于以上三種方案，其中兩種其實都是很通用的技術(shù)，即使大家不搞分布式，也照樣需要學(xué)習(xí)和了解。

唯獨對于第三種，故障隔離，是需要深入了解下的。但是故障隔離并不是什么高大上的黑科技，當(dāng)我們搞分布式的時候，由于天然是不同的模塊有不同的機器，并且機器還做了集群，所以，這個故障隔離就是天然就有的。

只是，有的時候，我們想更細(xì)粒度的對故障隔離進行阻隔，比如，想在線程級別或者進程級別就把故障隔離開了。此時，我就就可以考慮用下線程或者容器等去執(zhí)行任務(wù)，然后才去一些調(diào)度策略，把故障就天然的隔離為線程或者進程級別了。

4.6 分布式資源管理

最后，我們想深造能應(yīng)對更龐大的分布式系統(tǒng)，畢竟人都是追求進步的。這時候，我們就需要去理解分布式的體系結(jié)構(gòu)相關(guān)的知識，需要去理解分布式的資源管理。

但慶幸的是，分布式的資源管理本身技術(shù)棧很小。對于分布式體系結(jié)構(gòu)，一共就兩種結(jié)構(gòu)：

1. 集中式結(jié)構(gòu)

2. 非集中式結(jié)構(gòu)

對于分布式資源的分配或者說調(diào)度，一共就三種方法：

1. 單體調(diào)度

2. 兩層調(diào)度

3. 共享狀態(tài)調(diào)度

感謝各位的閱讀，以上就是“如何掌握分布式系統(tǒng)”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對如何掌握分布式系統(tǒng)這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！