要成為架構師，你需要掌握這些知識體系！

來源：JAVA日知錄

大家好，我是飄渺！

研發工程師的職業成長路線，基本是初級研發工程師，進階為中高階研發工程師，提升至架構師，然後再尋求更高的突破。這直接說明我們認同架構師的價值，想要努力成為架構師。雖然目標很明確，但我調研後發現，大多數研發工程師把“成為架構師”當作目標，但卻沒找到方法。

因為在工作中，不是每一個研發都有機會參與架構設計；很多公司也不會主動去培養你成為架構師。所以，有很多職場人在一家公司工作三年或五年之後並沒有多大的提升。

而很多的架構師都是研發自己在機遇巧合下，遇到大專案、參與其中、趟了坑、解決了問題，最終形成自己的知識體系和解決問題的能力之後才成長起來的。那麼如果沒有這些條件，你還有沒有途徑成為一名架構師呢？

當然有，在我看來，你要先掌握架構師的知識體系，然後再透過實踐進行檢驗，這樣才能逐步成長為一名架構師。

架構師能力模型

很多研發同學經常問我：“成為架構師應該掌握哪些技術？”

在我看來，成為架構師是要掌握一定的知識儲備，再經過專案歷練，但你更應該透過“知識儲備+專案歷練”，看自己達到了什麼能力，你的能力是否能夠匹配架構師這個崗位。

換句話說，你是否具有架構師的能力模式？

我們拿網際網路大廠（比如 BAT）的能力模型來對標，從它們對架構師的能力要求來看：能不能覆蓋一個領域子方向，也就是能不能作為一個系統的技術負責人？比如交易系統的負責人、商品系統的負責人。換句話說，你能不能把握整個系統的規劃、設計、落地，和演進。如果你能獨擋這一面，就具備了成為架構師的條件。

那架構師的能力到底由哪幾部分組成呢？

1. 基礎技術架構：這部分是純技術架構，所有非功能性的技術都是基礎技術的範疇。

2. 業務架構：在業務場景下對業務需求的抽象。

3. 開發技能：這是架構師落地架構的能力。

你要怎麼理解這個模型呢？

舉個例子，我們在開發時會經歷需求分析、架構設計、架構選型、架構落地幾個階段，這幾個階段對架構師的能力要求總結為一句話就是“架構師要把握系統技術”。

• 在需求分析階段：架構師對於業務架構，要給出一個合理的需求分析抽象模型。

• 在架構設計和架構選型階段：架構師要充分考慮技術的合理性，制定合理的設計方案。

• 在架構落地階段：架構師要能指導研發進行落地，並推進專案的執行。

你看，從需求分析、架構設計、到架構選型、再到架構落地，架構師都需要參與，而這些階段體現出來的需求分析能力、架構設計能力、程式碼開發能力，最終都會作用在一個系統上，這就是所謂的“把握系統技術”。也就是說，你如果想成為架構師就要做到、做好系統開發各環節的技術把控！

那麼在架構師能力模型的指引下，你要掌握哪些知識體系呢？

架構師知識體系

我們以網際網路分散式系統架構師的知識體系為例來說明：

分散式系統看起來就像一個計算機。計算機包括五大體系結構（即馮諾依曼結構），它有五大部件：分別是控制器、運算器、儲存器、輸入及輸出。你可以這麼理解：一個分散式系統也包含這五大部件，其中最重要的是計算與儲存。計算與儲存由一系列網路節點組成，每個節點之間的通訊就是輸入與輸出，各節點之間的排程管理就是控制器。

所以，對於從事網際網路分散式設計的架構師來說，你可以從以下四個角度來進行知識體系的拆解。

儲存

儲存指分散式儲存系統，你要理解什麼是分散式儲存系統？為什麼選型分散式儲存系統？以及分散式儲存中關注哪些問題？

首先，為了解決資料的水平擴充套件，要做資料分片，因為分散式系統區別於傳統單機系統就在於能將資料分佈到多個節點，並在多個節點間實現負載均衡。這種資料水平擴容的操作叫資料分片。

資料分片會涉及分片規則，常見的有範圍分片和雜湊分片，不同的分片規則就有不同的分片演算法，如雜湊分片就會涉及雜湊取模演算法、虛擬桶演算法、一致性雜湊演算法。

又因為資料要分佈到多個節點，你還需要資料複製，資料複製就會存在同步複製和非同步複製。為了保證資料的可靠性和可用性，增強系統容錯，資料複製就會產生副本，副本則是分散式儲存系統解決高可用的唯一手段。

而多個副本同步會產生一致性的問題，從而引出一致性問題的分類，如強一致性、弱一致、最終一致，要想解決一致性問題，會涉及一致性問題的協議：如兩階段提交協議（Two-PhraseCommit，2PC）、Paxos協議選舉、向量時鐘（VectorClock）、RWN協議、Raft協議。

多個副本還會帶來主選舉，這會涉及分散式鎖的問題：多個機器競爭一個鎖，當某個機器釋放鎖或者掛掉，其他機器可以競爭到鎖，繼續執行任務。為了解決鎖的容錯性，比如解決雙主（腦裂）問題，就會涉及租約機制，租約機制可以解決網路分割槽問題造成的“雙主”問題。

最後，為了衡量副本可用性和一致性，就會引出分散式系統的基礎理論 CAP 、BASE，以及 PACELC。

這樣一來，我們就梳理清楚了分散式儲存的知識體系。可以說，分散式儲存是分散式系統知識體系中最基礎的理論，也是最複雜的問題。

計算

分散式計算就會涉及三個概念：平行計算、分散式計算、雲端計算。

• 平行計算：同時使用多種計算資源解決計算問題的過程，比如多執行緒就是一種平行計算；服務叢集也是一種平行計算。

• 分散式計算：是從叢集技術發展而來，區別在於叢集雖然連線了多臺機器，但某項具體的任務執行時還是會被轉發到某臺伺服器上，分散式計算則將任務分割到多臺伺服器上平行計算，然後得到結果。

• 雲端計算：分散式計算 + 虛擬化技術的綜合技術的統稱，不同商業公司有著各自不同的定義，通俗來講就是開發者利用雲 API 開發應用，然後上傳到雲上託管，並提供給使用者使用，而不關心雲背後的運維和管理，以及機器資源分配等問題。

作為架構師，你要了解分散式領域中的計算模式，如分散式平行計算框架 Hadoop 中的 MapReduce 的設計思想，以及基於流式計算框架 Storm、Spark、Flink 的架構設計方案。

當然對於計算領域，很多公司會設立大資料架構師的崗位，如果你面試的是系統架構師，瞭解這部分知識體系即可，不用過度聚焦於分散式計算上，不過很多計算框架的設計理念還是很有參考價值的，值得你去學習瞭解。

輸入輸出

系統架構中的輸入輸出，是指系統間通訊的技術。

其中會涉及一些基礎知識，比如網路通訊最基礎的協議（諸如 TCP/UDP 協議等）；網路 I/O 模型（Blocking-IO，NonBlocking-IO、Asyn-IO），最後是偏應用的知識，需要了解例如連線複用、序列化/反序列化、RPC、MQ 訊息佇列等。

作為架構師，你要理解高效能的原理，掌握流量的流轉過程以及應對方案，比如當請求到達網路裝置時，你要依次考慮以下問題：

• 網路裝置如何處理流量？這會涉及中斷和快取。

• 作業系統如何處理流量？這會涉及 I/O 模型，select、poll、epoll，以及 I/O 多路複用。

• 應用系統如何處理流量？這會涉及 NIO 的開發，如 Reactor 模式、Netty 框架原理等。

• 系統執行緒如何處理流量？還會涉及多執行緒的設計模式。

最後，你還要掌握分散式系統通訊的核心技術：RPC 和 MQ。

控制器

你可以把分散式系統知識體系中的控制器，理解為系統架構中的排程系統，包括流量排程和資源排程。

流量排程（我們常說的流量控制）：作為架構師就要掌握流量控制的常用方案策略，比如負載均衡、服務路由、熔斷、降級、限流等，其實常用的高可用、高效能的解決方案很多都是基於流量上的排程。

資源排程：如果我們將流量排程遷移到伺服器的計算資源、儲存資源或基礎資源上面的話，就會引出另一種基於資源的排程，如 Mesos、Yarn 基於計算資源的排程；HDFS、GlusterFS、Ceph 基於儲存資源的排程；Kubernetes、Mesos 基於容器資源的排程（包括計算、儲存、網路等綜合性的資源排程）。

總的來說，你至少要掌握常用系統排程設計，排程演算法與負載策略。舉個例子，如果讓你對單個伺服器的計算資源做排程，你至少要具備設計思路：讓叢集選舉一個主節點，每個從節點會向主節點彙報自己的空閒資源，當請求到來時，主節點透過資源排程演算法選擇一個合適的從節點來處理該請求。

總結

無論你從事哪個領域的架構設計工作，都要明白作為架構師，一定是技術出身，但是要突破技術思維的限制，向上立足於部門和公司、向下管控系統和研發，站在全域性的角度去規劃、組織、系統技術的發展。

為了方便你理解，我把學習架構設計知識的思路總結為以下幾點：

• 想要學習架構設計知識，可以從自己熟知的領域出發，這樣你才有不斷的正反饋，從而更有信心，容易理解新的知識。

• 形成知識網路圖譜，如今技術錯綜複雜，各種技術又相互耦合，確實無法簡單劃分層次，所以我建議你把自己的核心知識梳理出一個脈絡清晰的結構圖，然後結合已有知識，再逐步將零散的知識點補充到這張網路圖譜之上，這樣你就擁有了核心知識和擴充套件知識。

• 養成對技術判斷力，針對同一問題有不同方法，不同維度、不同角度的分析和對比。這是為了提升你今後在工作中對技術的領悟力。

不知道在看完今天的內容之後，你有什麼樣的收穫呢？歡迎在留言區分享你的想法，我們互相交流進步。