架構師的成長之路，第一步該怎么邁？我給大家準備好了
有很多讀者經常問我，程序員的學習、成長之路應該怎么規劃，才能早日成為一名架構師。
作為一個曾經的架構師，在我走上技術管理這條路之后，管理的團隊越來越大，現在我管理的技術團隊有一百多人，最大的體會就是操心的事情太多、會議太多，寫代碼的時間越來越少了。
趁我現在還有技術的底子，代碼還沒完全忘光，我覺得應該給大家說說架構師的成長之路了。接下來我準備寫一系列關于架構師、分布式系統的技術文章。今天這篇文章相當于是一個綜述，相當于我們學 Java 語言的開篇：Hello World
好，正文開始。
作為一個資深架構師，一路走來，發現自己的技術水平很多時候其實是隨著項目的發展被迫成長的。其實，很多時候，自身水平達不到能順利完成架構項目的水平，但是，為了挑戰，為了技術成長，更是為了高薪資，只能咬牙堅持，熬夜學習，最終讓自己能順利設計和把控項目的架構。
其中，最為艱難的，就是去設計、架構、規劃一整套，規模大的分布式系統。但是，正是經歷了這些異常艱難的磨煉，我們才能毫不恐懼所謂的技術人員 35 歲大限。
但是，要做到這些，首要做的是能明白分布式系統到底是個什么東西。
1. 什么是分布式系統
分布式系統大家從網絡上看到的學術定義簡單來說就是一套由一組計算機協同工作，讓用戶感覺像是一個統一的整體的系統。
但是，由于這個定義定的過于簡練，很多初入門的人會毫無感知的潛意識就會混淆了分布式系統的概念。
什么意思?我這里問下，當我們用 keepalived 做高可用集群的時候，我們是在搞分布式系統嗎?當我們并發不夠，搞了一堆機器做負載均衡，我們是在搞分布式系統嗎?
當你心里默默回答是，或者不清楚是不是的時候，你本身對分布式系統這個概念就已經糊涂了。
這里，就需要為分布式系統畫出一個邊界來，并以此告知大家，并不是多臺機器堆在一起了就是分布式系統了。對于剛才那兩個問題，正確的答案就是 keepalived 做的高可用集群，用 Nginx 或者 lvs 后面跟著一堆應用集群配合搞的負載均衡，他們都不是分布式系統，他們就僅僅是個集群而已。
類似的，數據庫比如 MySQL 的主從，雙主什么的當然也不是分布式系統。因為這些集群少了分布式系統最核心的東西：
應用所在服務器之間的相互協作
為了說清集群和分布式，我再給大家舉一個通俗易懂的例子：
假設有一天我開了個軟件公司，公司就我一個程序員，前端、后端、測試的活兒，都是我干，一個月我能做完一個項目。
后來項目多了，我忙不過來了，為了多賺錢，怎么辦呢，我想了兩條路
再招一個和我一樣強的全棧工程師，我倆每個人獨立做項目，這樣我們一個月能做完兩個項目。我倆就組成了一個集群。
招一個前端、一個測試配合我，前端、后端、測試分頭干。通過協作，我們半個月能干完一個項目。這時候我們的關系就是分布式。
從上面例子你就能看出:
- 集群中的多個服務器都在做相同的事情，并不能縮短處理一件事情的時間。
- 而分布式呢，是把事情拆開，多個服務器分頭做事，可以縮短時間。
知道了什么是分布式系統之后，一個最簡單的分布式系統應該是什么樣的?
假設我們做了一套系統，這套系統僅有兩個功能：1. 注冊、2. 登錄
如果我們想讓這套系統變成分布式系統該怎么做?最簡單的是，把注冊功能和登錄功能分別做成兩套子服務，然后部署到兩臺服務器上，讓他們互相協作，這就變成了一套最簡單的分布式系統。
你看到這里可能會非常震驚：
這就是一套分布式系統了?
我想學習的分布式系統的那么多技術棧呢?
那些高大上的算法呢?
能瞬間閃回的容錯機制呢?
無縫熱升級的功能呢?
問題到底出現在哪里?
我們搭建的這套簡單的系統真的是我們日常談論的分布式系統嗎?
2. 為什么我們要搞分布式系統
為什么要搞分布式系統?答案很簡單：形勢所迫!一套分布式系統往往是由于業務發展后采取的終極方案。
假如公司新開展了一項在線業務，而我們因此要為這套業務搭建開發一套業務系統。往往這時候，由于項目前景未知，又由于要快速上線進入市場做試錯，此時，我們可能會優先搞一套單體架構，先上線。
隨著業務的開展和運營，我們往往面臨的第一個問題是系統的崩潰和服務器的宕機。
這時候，大家就搞一套高可用架構來解決問題。把相同的項目部署在多臺機器上，一臺機器出問題了，直接換到另外一臺提供服務即可。
隨后，由于業務進一步的發展和壯大，此時，出現瓶頸的往往就是系統的響應時間了。響應時間的增加直接影響了用戶體驗，而這本身也反映了吞吐量出現了瓶頸。
對于這種問題，架構師們就會祭出集群大法好的思路來搞定。這時候，系統架構開始復雜了起來，因為別忘了，我們在保證負載均衡的同時，還需要保證服務的高可用。
到目前為止，貌似沒什么問題了。我們通過高可用保證了系統的可靠性，通過負載均衡，分散了系統的壓力。
但是，以上這些方案都不是分布式，系統也不是分布式系統，依然是 Monoliths 這種被一些技術瘋子們嘲笑的笨重架構。
我們還需要分布式嗎?
上圖是某大廠的支付平臺一小部分架構圖。
從這張圖可以看出，業務發展到后面會有多么復雜。面對如此復雜的業務，我們發現我們之前搞的那種集群怎么也說不過去了。
這時候，就需要進行業務的拆分。
雖然業務拆分了，但是這些業務終究是要對外合作提供一個整體的服務的，這時候，才是真正需要分布式系統的時候了。我們需要一組在不同的服務器上相互協作的系統。
所以我們說，分布式系統是由于業務發展后的終極解決方案。最終，業務復雜到拆分的地步，那么分布式系統就是天然的需求了。
在這里，我們也可以解答下上節我們面臨的問題了。我們需要的不是簡單的直接把模塊分散部署的無意義分布式，不是簡單的模塊分解。我們需要的是系統在被迫搞成分布式的情況下依然能夠：
保持出色的性能
擁有著無比可靠的可用性
以及非常優秀的彈性
而為了保證以上這三個指標，就出現了分布式系統那繁雜艱深的技術棧。
3. 分布式系統的技術棧
上面我們說了，分布式系統的出現完全是形式所迫，完全是業務發展導致的最終結果。而由于業務的拆分，我們又被迫會衍生出更多的分布式需求來，以及應對這些需求的技術：
- 因為業務拆分的多，業務對應的模塊之間就需要通信，為了保證通信的快速可靠，我們需要掌握分布式通信技術。
- 業務拆分的過多，每個模塊可能還需要搞集群，那么多服務器資源，為了能夠保證資源的精準分配，我們還需要考慮分布式資源管理和負載調度技術。
- 業務拆分之后，模塊與模塊之間又需要對很多共享數據做訪問，為了保證安全完整的數據狀態，我們也要用到分布式協調與同步技術。
- 到了業務拆分的階段，數據必然龐大，為了數據存儲的可靠，為了保證優秀的數據讀寫性能，我們需要分布式存儲技術。
- 業務如此復雜，為了公司的發展，業務能繼續擴大，就需要能更加精準的營銷和運營，我們還需要對數據進行實時、離線處理分析，此時，我們又得考慮分布式計算技術。
- 在業務拆分后，整體架構出現了巨變，不可能再用以前集群方式的思維去考慮高可用，那么分布式的可靠性技術又要納入我們的掌握范疇。
你看分布式系統的技術棧這么多、這么復雜對吧，別慌。
我寫這篇文章不是為了勸退你們的，我們要學習必須分步驟分主題的學習，對整體的分布式技術棧分而克之，逐步掌握。
4. 如何學習分布式系統的技術棧
在分布式技術棧中我們可以看到，其實分布式技術是有分類的，我們可以根據不同的分類去掌握每種類別的分布式技術背后的概念和思想。無論分布式技術有多少實現，這些實現永遠都是以其所在分類的分布式技術原理作為核心底層來實現的。
同時呢，我們在學習當中，還必須理論聯系實際，根據我們的實際開發和架構需要學習。
而且，業務是逐步發展的，項目也不會一下就發展的特別龐大。這就給與了我們分步學習，逐步掌握的時間和機會。
4.1 分布式通信
那具體到底如何做呢?
首先，分布式中的根基是什么?就我自己的經歷而言，我認為是通信，最重要的其實分布式系統中那些模塊中的通信機制。
而通信機制該怎么學習?我認為首先要了解我們可用的各通信機制的區別。其中尤為重要的是了解各通信機制的缺點。對，你沒看錯，就是缺點。
為什么缺點最重要呢?因為架構師在架構的時候，一項尤為重要的工作就是做技術選型。而技術選型的目標很多時候的應用場景往往非常模糊，如果能了解到各選型的缺點，則對選型的結果是否準確就起到了極其重要的作用。
比如，我們現在想搞模塊間通信，那么到底是用 RPC 還是用 MQ ?此時，我們知道 RPC 的缺點和 MQ 的缺點的話，就能很容易做出更準確的選型。
RPC 的缺點:
- 不能搞流量削鋒
- 不能廣播給多個模塊
- 消息投遞沒有保證
- 模塊和模塊之間沒法解耦
MQ 的缺點：
- 不能保證延遲時間
- 不適合搞強一致性的事務
- 增加了系統的復雜度
- 降低了系統的可用性
好了，知道了缺點，我們就很容易選型了。如果我們現在有個業務是實時扣費，我們肯定要搞 RPC，因為這是延遲敏感并且是需要強一致性。
如果我們現在有個業務是同時給會計系統和合作方發記賬請求的需求，那這時候我們就可能選用 MQ 通信了。
4.2 分布式協調和同步
我們理解了分布式通信之后，下一步我認為最要學的是分布式協調和同步。
因為在現實里，即使系統搞成分布式了，其實往往沒有特別大，分布式資源管理暫時可以先不考慮。分布式存儲也可能還在使用數據庫的主備或者 Sharding 方式在抗。而分布式計算的需求也可能沒有那么緊急。
但是，一旦分布式系統中的全局狀態出問題了，那就是事故了。所以，理解分布式協調和同步，一定是很緊急也很重要的。
那協調和同步怎么學呢?
我們要知道，我們所謂的協調數據訪問，同步數據訪問到底是在做什么。其實協調數據訪問的本質就是去對數據訪問的請求做優先級排列，這就是協調數據訪問的本質。而如何定義優先級?根據什么定義優先級?就是我們需要學習的東西。
至于同步，其實就是對數據訪問的保護。如何限制對數據的訪問?限制數據訪問的策略是什么?就是同步的本質。
然后，如果我們理解了多線程的數據協調和同步，我們通過分布式和多線程的相同和區別，能更容易更快速的去把握好分布式協調的技術本質。
4.3 分布式存儲
當理解了分布式協調和同步之后，我們就應該關注分布式存儲。因為業務的核心是數據，海量的數據最終還需要分布式存儲來解決安全可靠的持久化問題。
而分布式存儲最最重要的是理解什么?不是存儲的各種實現，是分布式存儲的立身之本：CAP 理論。
我們通過對 CAP 理論的理解，去理解分布式存儲實現是如何實現對應的 CP 或者 AP 的，就會非常容易了。并且理解了 CAP，我們就能根據真實的業務需求，理解業務是需要 CP 還是 AP，然后就能根據這些，對分布式存儲做合適的選型了。
4.4 分布式計算
當學習了分布式存儲，此時，我們就應該去學習分布式計算。因為分布式計算很可能會成為一個重要的運營需求。而分布式計算，就整體而言，一共就四種模式。任你千變萬化，都逃不掉這四種模式。
從計算方式上看，一共就兩種方法：
- MR 方式(MapReduce)
- Stream 方式
從處理過程來看，也只有兩種模式：
- Actor 模式
- 流水線模式
4.5 分布式可靠性
到此，在知道了這些知識之后，對于一般公司的架構任務，架構師們做起來就游刃有余了。一個完整的正向分布式學習流程的知識，其實就差不多了。
此時，我們還需要知道一般的分布式可靠性的處理方案。其實大體也不會超過三種：
- 對量大的模塊搞負載均衡的集群;
- 對某些有資源限制條件的模塊可以搞流量控制;
- 當任何模塊對應的服務器出現問題時，想辦法不讓它影響正常的系統運轉，而這個就叫做故障隔離。
而對于以上三種方案，其中兩種其實都是很通用的技術，即使大家不搞分布式，也照樣需要學習和了解。
唯獨對于第三種，故障隔離，是需要深入了解下的。但是故障隔離并不是什么高大上的黑科技，當我們搞分布式的時候，由于天然是不同的模塊有不同的機器，并且機器還做了集群，所以，這個故障隔離就是天然就有的。
只是，有的時候，我們想更細粒度的對故障隔離進行阻隔，比如，想在線程級別或者進程級別就把故障隔離開了。此時，我就就可以考慮用下線程或者容器等去執行任務，然后才去一些調度策略，把故障就天然的隔離為線程或者進程級別了。
4.6 分布式資源管理
最后，我們想深造能應對更龐大的分布式系統，畢竟人都是追求進步的。這時候，我們就需要去理解分布式的體系結構相關的知識，需要去理解分布式的資源管理。
但慶幸的是，分布式的資源管理本身技術棧很小。對于分布式體系結構，一共就兩種結構：
- 集中式結構
- 非集中式結構
對于分布式資源的分配或者說調度，一共就三種方法：
- 單體調度
- 兩層調度
- 共享狀態調度
最后
以上，我將分布式系統是什么，為什么要做分布式系統以及分布式系統我們到底該怎么學大體說了一下。
是不是看完之后感覺有點空，感覺有點懵，別著急，后續我會寫出更多的關于分布式的文章，寫的通俗易懂一些，讓大家能盡量花更少的時間、成本，學到更多的分布式知識。
一口吃不成個胖子，好戲剛剛開始。
上面寫的，我只是整體出來了一條線，但是很多東西其實也可以并行學習。另外，關于如何學習，這方面是仁者見仁，智者見智，不喜勿噴!
本文轉載自微信公眾號「四猿外」，可以通過以下二維碼關注。轉載本文請聯系四猿外公眾號。
