每個程序員，都渴望成爲一名分佈式系統架構師

有不少讀者常常問我，程序員的學習、成長之路應該怎麼規劃，才能早日成爲一名架構師。

做爲一個曾經的架構師，在我走上技術管理這條路以後，管理的團隊愈來愈大，如今我管理的技術團隊有一百多人，最大的體會就是操心的事情太多、會議太多，寫代碼的時間愈來愈少了。

趁我如今還有技術的底子，代碼還沒徹底忘光，我以爲應該給你們說說架構師的成長之路了。接下來我準備寫一系列關於架構師、分佈式系統的技術文章。今天這篇文章至關因而一個綜述，至關於咱們學 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. 共享狀態調度

最後

以上，我將分佈式系統是什麼，爲何要作分佈式系統以及分佈式系統咱們到底該怎麼學大致說了一下。

是否是看完以後感受有點空，感受有點懵，彆着急，後續我會寫出更多的關於分佈式的文章，寫的通俗易懂一些，讓你們能儘可能花更少的時間、成本，學到更多的分佈式知識。

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

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

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