本文公眾號(hào)來源：四猿外

作者：四猿外

本文已收錄至我的GitHub

前文回顧（通俗易懂講解了什么是CAP、分布式、集群以及SpringCloud入門，絕對(duì)不能錯(cuò)過）：

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

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

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

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

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

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

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

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

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

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

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

再招一個(gè)和我一樣強(qiáng)的全棧工程師，我倆每個(gè)人獨(dú)立做項(xiàng)目，這樣我們一個(gè)月能做完兩個(gè)項(xiàng)目。我倆就組成了一個(gè)集群。
招一個(gè)前端、一個(gè)測(cè)試配合我，前端、后端、測(cè)試分頭干。通過協(xié)作，我們半個(gè)月能干完一個(gè)項(xiàng)目。這時(shí)候我們的關(guān)系就是分布式。

從上面例子你就能看出:

集群中的多個(gè)服務(wù)器都在做相同的事情，并不能縮短處理一件事情的時(shí)間。
而分布式呢，是把事情拆開，多個(gè)服務(wù)器分頭做事，可以縮短時(shí)間。

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

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

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

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

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

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

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

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

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

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

對(duì)于這種問題，架構(gòu)師們就會(huì)祭出集群大法好的思路來搞定。這時(shí)候，系統(tǒng)架構(gòu)開始復(fù)雜了起來，因?yàn)閯e忘了，我們?cè)诒ＷC負(fù)載均衡的同時(shí)，還需要保證服務(wù)的高可用。

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

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

我們還需要分布式嗎？

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

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

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

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

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

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

保持出色的性能
擁有著無比可靠的可用性
以及非常優(yōu)秀的彈性

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

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

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

因?yàn)闃I(yè)務(wù)拆分的多，業(yè)務(wù)對(duì)應(yīng)的模塊之間就需要通信，為了保證通信的快速可靠，我們需要掌握分布式通信技術(shù)。
業(yè)務(wù)拆分的過多，每個(gè)模塊可能還需要搞集群，那么多服務(wù)器資源，為了能夠保證資源的精準(zhǔn)分配，我們還需要考慮分布式資源管理和負(fù)載調(diào)度技術(shù)。
業(yè)務(wù)拆分之后，模塊與模塊之間又需要對(duì)很多共享數(shù)據(jù)做訪問，為了保證安全完整的數(shù)據(jù)狀態(tài)，我們也要用到分布式協(xié)調(diào)與同步技術(shù)。
到了業(yè)務(wù)拆分的階段，數(shù)據(jù)必然龐大，為了數(shù)據(jù)存儲(chǔ)的可靠，為了保證優(yōu)秀的數(shù)據(jù)讀寫性能，我們需要分布式存儲(chǔ)技術(shù)。
業(yè)務(wù)如此復(fù)雜，為了公司的發(fā)展，業(yè)務(wù)能繼續(xù)擴(kuò)大，就需要能更加精準(zhǔn)的營銷和運(yùn)營，我們還需要對(duì)數(shù)據(jù)進(jìn)行實(shí)時(shí)、離線處理分析，此時(shí)，我們又得考慮分布式計(jì)算技術(shù)。
在業(yè)務(wù)拆分后，整體架構(gòu)出現(xiàn)了巨變，不可能再用以前集群方式的思維去考慮高可用，那么分布式的可靠性技術(shù)又要納入我們的掌握范疇。

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

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

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

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

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

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

4.1 分布式通信

那具體到底如何做呢？

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

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

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

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

RPC 的缺點(diǎn):

不能搞流量削鋒
不能廣播給多個(gè)模塊
消息投遞沒有保證
模塊和模塊之間沒法解耦

MQ 的缺點(diǎn)：

不能保證延遲時(shí)間
不適合搞強(qiáng)一致性的事務(wù)
增加了系統(tǒng)的復(fù)雜度
降低了系統(tǒng)的可用性

好了，知道了缺點(diǎn)，我們就很容易選型了。如果我們現(xiàn)在有個(gè)業(yè)務(wù)是實(shí)時(shí)扣費(fèi)，我們肯定要搞 RPC，因?yàn)檫@是延遲敏感并且是需要強(qiáng)一致性。

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

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

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

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

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

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

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

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

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

4.3 分布式存儲(chǔ)

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

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

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

4.4 分布式計(jì)算

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

從計(jì)算方式上看，一共就兩種方法：

MR 方式（MapReduce）
Stream 方式

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

Actor 模式
流水線模式

4.5 分布式可靠性

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

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

對(duì)量大的模塊搞負(fù)載均衡的集群；
對(duì)某些有資源限制條件的模塊可以搞流量控制；
當(dāng)任何模塊對(duì)應(yīng)的服務(wù)器出現(xiàn)問題時(shí)，想辦法不讓它影響正常的系統(tǒng)運(yùn)轉(zhuǎn)，而這個(gè)就叫做故障隔離。

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

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

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

4.6 分布式資源管理

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

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

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

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

單體調(diào)度
兩層調(diào)度
共享狀態(tài)調(diào)度

最后

以上，我將分布式系統(tǒng)是什么，為什么要做分布式系統(tǒng)以及分布式系統(tǒng)我們到底該怎么學(xué)大體說了一下。

學(xué)習(xí)這些原理和知識(shí)的目的本質(zhì)就是希望我們能在技術(shù)上、在職場(chǎng)上更進(jìn)一步，能獲取更高的薪資，讓大家生活更好。望共勉。

原創(chuàng)電子書
原創(chuàng)思維導(dǎo)圖

已經(jīng)有8756個(gè)初學(xué)者都下載了！
?三歪把【大廠面試知識(shí)點(diǎn)】、【簡歷模板】、【原創(chuàng)文章】
全部整理成電子書，共有1263頁！掃碼或微信搜 Java3y
回復(fù)「888」領(lǐng)取