每一個程式設計師，都希望能成為分散式系統架構師

有很多讀者經常問我，程式設計師的學習、成長之路應該怎麼規劃，才能早日成為一名架構師。

作為一個曾經的架構師，在我走上技術管理這條路之後，管理的團隊越來越大，現在我管理的技術團隊有一百多人，最大的體會就是操心的事情太多、會議太多，寫程式碼的時間越來越少了。

趁我現在還有技術的底子，程式碼還沒完全忘光，我覺得應該給大家說說架構師的成長之路了。接下來我準備寫一系列關於架構師、分散式系統的技術文章。今天這篇文章相當於是一個綜述，相當於我們學 Java 語言的開篇：Hello World

好，正文開始。

作為一個資深架構師，一路走來，發現自己的技術水平很多時候其實是隨著專案的發展被迫成長的。其實，很多時候，自身水平達不到能順利完成架構專案的水平，但是，為了挑戰，為了技術成長，更是為了高薪資，只能咬牙堅持，熬夜學習，最終讓自己能順利設計和把控專案的架構。

其中，最為艱難的，就是去設計、架構、規劃一整套，規模大的分散式系統。但是，正是經歷了這些異常艱難的磨鍊，我們才能毫不恐懼所謂的技術人員 35 歲大限。

但是，要做到這些，首要做的是能明白分散式系統到底是個什麼東西。

1. 什麼是分散式系統

分散式系統大家從網路上看到的學術定義簡單來說就是一套由一組計算機協同工作，讓使用者感覺像是一個統一的整體的系統。

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

什麼意思？我這裡問下，當我們用 keepalived 做高可用叢集的時候，我們是在搞分散式系統嗎？當我們併發不夠，搞了一堆機器做負載均衡，我們是在搞分散式系統嗎？

當你心裡默默回答是，或者不清楚是不是的時候，你本身對分散式系統這個概念就已經糊塗了。

這裡，就需要為分散式系統畫出一個邊界來，並以此告知大家，並不是多臺機器堆在一起了就是分散式系統了。對於剛才那兩個問題，正確的答案就是 keepalived 做的高可用叢集，用 Nginx 或者 lvs 後面跟著一堆應用叢集配合搞的負載均衡，他們都不是分散式系統，他們就僅僅是個叢集而已。

類似的，資料庫比如 MySQL 的主從，雙主什麼的當然也不是分散式系統。因為這些叢集少了分散式系統最核心的東西：

應用所在伺服器之間的相互協作

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

假設有一天我開了個軟體公司，公司就我一個程式設計師，前端、後端、測試的活兒，都是我幹，一個月我能做完一個專案。

後來專案多了，我忙不過來了，為了多賺錢，怎麼辦呢，我想了兩條路

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

2. 招一個前端、一個測試配合我，前端、後端、測試分頭幹。通過協作，我們半個月能幹完一個專案。這時候我們的關係就是分散式。

從上面例子你就能看出:

• 叢集中的多個伺服器都在做相同的事情，並不能縮短處理一件事情的時間。

• 而分散式呢，是把事情拆開，多個伺服器分頭做事，可以縮短時間。

知道了什麼是分散式系統之後，一個最簡單的分散式系統應該是什麼樣的？

假設我們做了一套系統，這套系統僅有兩個功能：1. 註冊、2. 登入

如果我們想讓這套系統變成分散式系統該怎麼做？最簡單的是，把註冊功能和登入功能分別做成兩套子服務，然後部署到兩臺伺服器上，讓他們互相協作，這就變成了一套最簡單的分散式系統。

你看到這裡可能會非常震驚：
這就是一套分散式系統了？
我想學習的分散式系統的那麼多技術棧呢？
那些高大上的演算法呢？
能瞬間閃回的容錯機制呢？
無縫熱升級的功能呢？
問題到底出現在哪裡？
我們搭建的這套簡單的系統真的是我們日常談論的分散式系統嗎？

2. 為什麼我們要搞分散式系統

為什麼要搞分散式系統？答案很簡單：形勢所迫！一套分散式系統往往是由於業務發展後採取的終極方案。

假如公司新開展了一項線上業務，而我們因此要為這套業務搭建開發一套業務系統。往往這時候，由於專案前景未知，又由於要快速上線進入市場做試錯，此時，我們可能會優先搞一套單體架構，先上線。

隨著業務的開展和運營，我們往往面臨的第一個問題是系統的崩潰和伺服器的當機。

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

隨後，由於業務進一步的發展和壯大，此時，出現瓶頸的往往就是系統的響應時間了。響應時間的增加直接影響了使用者體驗，而這本身也反映了吞吐量出現了瓶頸。

對於這種問題，架構師們就會祭出叢集大法好的思路來搞定。這時候，系統架構開始複雜了起來，因為別忘了，我們在保證負載均衡的同時，還需要保證服務的高可用。

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

但是，以上這些方案都不是分散式，系統也不是分散式系統，依然是 Monoliths 這種被一些技術瘋子們嘲笑的笨重架構。

我們還需要分散式嗎？

上圖是某大廠的支付平臺一小部分架構圖。

從這張圖可以看出，業務發展到後面會有多麼複雜。面對如此複雜的業務，我們發現我們之前搞的那種叢集怎麼也說不過去了。

這時候，就需要進行業務的拆分。

雖然業務拆分了，但是這些業務終究是要對外合作提供一個整體的服務的，這時候，才是真正需要分散式系統的時候了。我們需要一組在不同的伺服器上相互協作的系統。

所以我們說，分散式系統是由於業務發展後的終極解決方案。最終，業務複雜到拆分的地步，那麼分散式系統就是天然的需求了。

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

1. 保持出色的效能
2. 擁有著無比可靠的可用性
3. 以及非常優秀的彈性

而為了保證以上這三個指標，就出現了分散式系統那繁雜艱深的技術棧。

3. 分散式系統的技術棧

上面我們說了，分散式系統的出現完全是形式所迫，完全是業務發展導致的最終結果。而由於業務的拆分，我們又被迫會衍生出更多的分散式需求來，以及應對這些需求的技術：

• 因為業務拆分的多，業務對應的模組之間就需要通訊，為了保證通訊的快速可靠，我們需要掌握分散式通訊技術。

• 業務拆分的過多，每個模組可能還需要搞叢集，那麼多伺服器資源，為了能夠保證資源的精準分配，我們還需要考慮分散式資源管理和負載排程技術。

• 業務拆分之後，模組與模組之間又需要對很多共享資料做訪問，為了保證安全完整的資料狀態，我們也要用到分散式協調與同步技術。

• 到了業務拆分的階段，資料必然龐大，為了資料儲存的可靠，為了保證優秀的資料讀寫效能，我們需要分散式儲存技術。

• 業務如此複雜，為了公司的發展，業務能繼續擴大，就需要能更加精準的營銷和運營，我們還需要對資料進行實時、離線處理分析，此時，我們又得考慮分散式計算技術。

• 在業務拆分後，整體架構出現了鉅變，不可能再用以前叢集方式的思維去考慮高可用，那麼分散式的可靠性技術又要納入我們的掌握範疇。

你看分散式系統的技術棧這麼多、這麼複雜對吧，別慌。

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

4. 如何學習分散式系統的技術棧

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

同時呢，我們在學習當中，還必須理論聯絡實際，根據我們的實際開發和架構需要學習。

而且，業務是逐步發展的，專案也不會一下就發展的特別龐大。這就給與了我們分步學習，逐步掌握的時間和機會。

4.1 分散式通訊

那具體到底如何做呢？

首先，分散式中的根基是什麼？就我自己的經歷而言，我認為是通訊，最重要的其實分散式系統中那些模組中的通訊機制。

而通訊機制該怎麼學習？我認為首先要了解我們可用的各通訊機制的區別。其中尤為重要的是瞭解各通訊機制的缺點。對，你沒看錯，就是缺點。

為什麼缺點最重要呢？因為架構師在架構的時候，一項尤為重要的工作就是做技術選型。而技術選型的目標很多時候的應用場景往往非常模糊，如果能瞭解到各選型的缺點，則對選型的結果是否準確就起到了極其重要的作用。

比如，我們現在想搞模組間通訊，那麼到底是用 RPC 還是用 MQ ？此時，我們知道 RPC 的缺點和 MQ 的缺點的話，就能很容易做出更準確的選型。

RPC 的缺點:

1. 不能搞流量削鋒
2. 不能廣播給多個模組
3. 訊息投遞沒有保證
4. 模組和模組之間沒法解耦

MQ 的缺點：

1. 不能保證延遲時間
2. 不適合搞強一致性的事務
3. 增加了系統的複雜度
4. 降低了系統的可用性

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

如果我們現在有個業務是同時給會計系統和合作方發記賬請求的需求，那這時候我們就可能選用 MQ 通訊了。

4.2 分散式協調和同步

我們理解了分散式通訊之後，下一步我認為最要學的是分散式協調和同步。

因為在現實裡，即使系統搞成分散式了，其實往往沒有特別大，分散式資源管理暫時可以先不考慮。分散式儲存也可能還在使用資料庫的主備或者 Sharding 方式在抗。而分散式計算的需求也可能沒有那麼緊急。

但是，一旦分散式系統中的全域性狀態出問題了，那就是事故了。所以，理解分散式協調和同步，一定是很緊急也很重要的。

那協調和同步怎麼學呢？

我們要知道，我們所謂的協調資料訪問，同步資料訪問到底是在做什麼。其實協調資料訪問的本質就是去對資料訪問的請求做優先順序排列，這就是協調資料訪問的本質。而如何定義優先順序？根據什麼定義優先順序？就是我們需要學習的東西。

至於同步，其實就是對資料訪問的保護。如何限制對資料的訪問？限制資料訪問的策略是什麼？就是同步的本質。

然後，如果我們理解了多執行緒的資料協調和同步，我們通過分散式和多執行緒的相同和區別，能更容易更快速的去把握好分散式協調的技術本質。

4.3 分散式儲存

當理解了分散式協調和同步之後，我們就應該關注分散式儲存。因為業務的核心是資料，海量的資料最終還需要分散式儲存來解決安全可靠的持久化問題。

而分散式儲存最最重要的是理解什麼？不是儲存的各種實現，是分散式儲存的立身之本：CAP 理論。

我們通過對 CAP 理論的理解，去理解分散式儲存實現是如何實現對應的 CP 或者 AP 的，就會非常容易了。並且理解了 CAP，我們就能根據真實的業務需求，理解業務是需要 CP 還是 AP，然後就能根據這些，對分散式儲存做合適的選型了。

4.4 分散式計算

當學習了分散式儲存，此時，我們就應該去學習分散式計算。因為分散式計算很可能會成為一個重要的運營需求。而分散式計算，就整體而言，一共就四種模式。任你千變萬化，都逃不掉這四種模式。

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

1. MR 方式（MapReduce）
2. Stream 方式

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

1. Actor 模式
2. 流水線模式

4.5 分散式可靠性

到此，在知道了這些知識之後，對於一般公司的架構任務，架構師們做起來就遊刃有餘了。一個完整的正向分散式學習流程的知識，其實就差不多了。

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

1. 對量大的模組搞負載均衡的叢集；

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

3. 當任何模組對應的伺服器出現問題時，想辦法不讓它影響正常的系統運轉，而這個就叫做故障隔離。

而對於以上三種方案，其中兩種其實都是很通用的技術，即使大家不搞分散式，也照樣需要學習和了解。

唯獨對於第三種，故障隔離，是需要深入瞭解下的。但是故障隔離並不是什麼高大上的黑科技，當我們搞分散式的時候，由於天然是不同的模組有不同的機器，並且機器還做了叢集，所以，這個故障隔離就是天然就有的。

只是，有的時候，我們想更細粒度的對故障隔離進行阻隔，比如，想線上程級別或者程式級別就把故障隔離開了。此時，我就就可以考慮用下執行緒或者容器等去執行任務，然後才去一些排程策略，把故障就天然的隔離為執行緒或者程式級別了。

4.6 分散式資源管理

最後，我們想深造能應對更龐大的分散式系統，畢竟人都是追求進步的。這時候，我們就需要去理解分散式的體系結構相關的知識，需要去理解分散式的資源管理。

但慶幸的是，分散式的資源管理本身技術棧很小。對於分散式體系結構，一共就兩種結構：

1. 集中式結構
2. 非集中式結構

對於分散式資源的分配或者說排程，一共就三種方法：

1. 單體排程
2. 兩層排程
3. 共享狀態排程

最後

以上，我將分散式系統是什麼，為什麼要做分散式系統以及分散式系統我們到底該怎麼學大體說了一下。

是不是看完之後感覺有點空，感覺有點懵，彆著急，後續我會寫出更多的關於分散式的文章，寫的通俗易懂一些，讓大家能儘量花更少的時間、成本，學到更多的分散式知識。

一口吃不成個胖子，好戲剛剛開始。

上面寫的，我只是整體出來了一條線，但是很多東西其實也可以並行學習。另外，關於如何學習，這方面是仁者見仁，智者見智，不喜勿噴！

學習這些原理和知識的目的本質就是希望我們能在技術上、在職場上更進一步，能獲取更高的薪資，讓大家生活更好。望共勉。

最最後

我準備了一些純手打的高質量PDF：

深入淺出Java多執行緒、HTTP超全彙總、Java基礎核心總結、程式設計師必知的硬核知識大全、簡歷面試談薪的超全乾貨。

別看數量不多，但篇篇都是乾貨，看完的都說很肝。

領取方式：掃碼關注後，在公眾號後臺回覆：666