分享好文：分享我在阿里8年，是如何一步一步走向架構師的

原文連接：https://blog.csdn.net/sinat_41559116/article/details/79942607

前言

成爲優秀的架構師是大部分初中級工程師的階段性目標。優秀的架構師每每具有七種核心能力：編程能力、調試能力、編譯部署能力、性能優化能力、業務架構能力、在線運維能力、項目管理能力和規劃能力。

這幾種能力之間的關係大概以下圖。編程能力、調試能力和編譯部署能力屬於最基礎的能力。不能精通掌握這三種能力，很難在性能優化能力和業務架構能力方面有所成就。具有了必定的性能優化能力和業務架構能力以後，才能在線運維能力和項目管理能力方面表現優越。團隊管理能力是最高能力，它對項目管理能力的依賴度更大。

基本知識

1.學會分析源碼

程序員天天都和代碼打交道。通過數年的基礎教育和職業培訓，大部分程序員都會「寫」代碼，或者至少會抄代碼和改代碼。可是，會讀代碼的並不在多數，會讀代碼又真正讀懂一些大項目的源碼的，少之又少。這種怪狀，真要追究起來，怪不得程序員這個羣體自己 —— 它是兩個緣由形成的：

• 咱們全部的教育和培訓都在強調怎麼寫代碼，並無教你們如何讀代碼

• 大多數工做場景都是一個蘿蔔一個坑，咱們只須要了解一個系統的局部便能開展工做，讀不相干的代碼，彷佛沒用

讀源碼三問：「爲何要有這樣的架構」，「他是什麼樣子的」，「他是怎麼工做的」。 

那麼阿里程序員是如何去讀代碼的呢？

2.分佈式架構特色及設計理念

首先須要說明的是，分佈式系統是一個複雜且寬泛的研究領域，學習一兩門在線課程，看一兩本書可能都是不能徹底覆蓋其全部內容的。介於這篇文章是引導初學者入門，因此我我的以爲爲初學者介紹一下當前分佈式系統領域的全貌，也許比直接推薦論文和課程更有幫助。當初學者對這個領域創建起一個大的 Picture 以後，能夠根據本身的興趣，有選擇性的深刻不一樣領域進行進一步的學習。

3.爲何微服務會這麼火？

要學習微服務，首先，咱們要了解爲何使用微服務。

• 代碼難以理解？

• 構建和部署耗時長，難以定位問題，開發效率低？

• 單體只能按總體橫向擴展，沒法分模塊垂直擴展？

• 一個bug有可能引發整個應用的崩潰？

• 受技術棧限制，團隊成員使用同一框架和語言？

那麼如何解決單體的不足呢，經過遷移到微服務架構來解決，咱們看一下什麼是微服務。

微服務架構:將單體應用拆分爲多個高內聚低耦合的小型服務，每一個小服務運行在獨立進程，由不一樣的團隊開發和維護，服務間採用輕量級通訊機制，獨立自動部署，能夠採用不一樣的語言及存儲。

單體架構整個團隊維護開發一個大工程及一個單庫，到了微服務架構，用戶請求通過API Gateway被路由到下游服務，服務之間以輕量級通訊協議進行通訊，服務經過註冊中心發現彼此，每一個服務都有專門的開發維護團隊，每一個服務對應獨立的數據庫，服務獨立開發，獨立部署和上線。

接下來咱們總結下微服務的優勢。

• 易於開發與維護

• 微服務相對小，易於理解

• 啓動時間短，開發效率高

• 獨立部署

• 一個微服務的修改不須要協調其它服務

• 伸縮性強

• 每一個服務均可以在橫向和縱向上擴展

• 每一個服務均可按硬件資源的需求進行獨立擴容

• 與組織結構相匹配

• 微服務架構能夠更好將架構和組織相匹配

• 每一個團隊獨立負責某些服務，得到更高的生產力

• 技術異構性

• 使用最適合該服務的技術

• 下降嘗試新技術的成本

下面就送上學習架構圖吧

若是你以爲想提高下本身，學習文章中的知識，在此推薦一個免費公開課的地方，能夠加羣：433540541，找羣主獲取上課資格，這是免費的課程，找羣主要的時候能夠客氣一點。

4.程序員到底要不要學習JVM

總有人問這個東西好像用不上,因而要不要學這樣的問題。

而後又總有人擔憂一直搬磚整天作些重複沒提高的東西。

若是你這輩子只甘心作一個平庸的Java碼農，那麼你徹底沒有必要去學習JVM相關的知識，學習JVM對於一個Java程序員的好處大概能夠歸納爲下幾點：

• 1.你可以明白爲何Java最先期被稱爲解釋型語言，然後來爲何又被你們叫作解釋與編譯並存的語言（瞭解JVM中解釋器以及即時編譯器就能夠回答這個問題）；

• 2.你可以理解動態編譯與靜態編譯的區別，以及動態編譯相對於靜態編譯到底有什麼好處（JVM JIT）；

• 3.你可以利用一些工具，jmap, jvisualvm, jstat, jconsole等工具能夠輔助你觀察Java應用在運行時堆的佈局狀況，由此你能夠經過調整JVM相關參數提升Java應用的性能；

• 4.能夠清楚知道Java程序是如何執行的；

• 5.能夠明白爲何Java等高級語言具備可移植性強的特性。

其實這個問題至關於「爲何C／C++程序員須要學體系結構與編譯原理？」

話很少說，附上學習體系圖

5.被咱們忽略掉的工程化專題

IT產業行業細分化已經不是一天兩天的事了。集成技術這件事並不可恥好笑，反而是另外一種難得的能力。並非像一些人形容的那樣，好像批發幾個CPU，拿到華強北就能把本身的電腦改裝成超級計算機了。

那麼，爲何咱們經常會忽略掉工程化這件事的價值呢？主要的緣由，或許是由於工程化這件事自己就離咱們太遠。一個產業工程化的廣泛性越高，說明這個產業發展的越成熟：產業鏈細分、分工細化、全球化的研發和生產這些高效的工做方式開始出現。而產業成熟也每每表明着寡頭化狀況顯著。

在IT產業中，寡頭化出現表明着創業公司減小——沒人再去用聲勢浩大的發佈會講故事、沒人再去宣傳本身拿了多少融資。

這一代中國人自小的教育不比歐美的STEAM，而是重學術、輕手藝。咱們每每會爲工科和產能過剩畫上等號。強大的資本和技術門檻爲這些產業蒙上了一層神祕的面紗，讓普通人很難真正瞭解到其中技術和工藝的複雜程度，也就更難明白其中的價值。可正是由於中國的工程化能力，才讓咱們有機會走到AI時代的第一梯隊，而不只僅是靠學術研究能力。

另一個緣由，或許在於咱們天生「叛逆心」。超級計算機、手機芯片等等技術門檻較高的產業，其背後每每是大企業和國資科研機構。當評判的對象是他們時，咱們彷佛更願意相信狗血的商業故事和陰謀論：好比科研經費都被教授們吃吃喝喝啦；搞超級計算機就是放衛星其實美日根本不care啦；XX企業的技術都是從創業公司買來的除了會賺用戶的錢啥技術都沒有……

產生這種「叛逆心」的緣由太深入，咱們能作到的，只有在這種「慣性思惟」出現時先按住本身奔向鍵盤的手，轉表達欲爲好奇心，完成本身瞭解的義務，再去行使本身批判的權利。

附上思惟腦圖

6.沒有高併發經驗，想進大公司該怎麼辦？

假如沒有靠譜的公司,接觸不到高併發的業務場景怎麼辦?你永遠解決的是小問題，工做10年技術也未必提高多少。

不少程序員也常常找我說，沒有經驗就沒有靠譜的公司收，沒有靠譜的公司也就沒有經驗，我看了無數的書，本身作了無數的實驗拼命想找個靠譜公司去深刻，可是感受好難，簡直是個死循環

讀者羣的朋友你們都比較關注高併發，緣由很簡單，想去BAT這樣的大公司，你必需要有高併發的經驗。今天普及下高併發的知識，但願你們對高併發有一個正確的認識。

7.學習千遍，不如項目實戰成功一次

咱們在學習過程當中最容易犯的一個錯誤就是：看的多，動手的少。特別是對一些項目的總體開發，咱們接觸的機會就更少了。

一次完整的開發，是最好的學習。它能讓你對整個開發流程有完整的認識，對知識也會有極大的鞏固。更重要的是，你將學會將理論知識用到實際開發中的方法。

因此不管項目大小，必定要動手去進行開發學習。

項目實戰相信不少程序員都多少會有的，但是咱們這個還要學習什麼呢？

那就要看你想不想成爲一個架構師了，爲何98%的程序員工做10年，一生還只是一個開發者。程序員們都要想想這個問題，我是否是須要提高了。

我認爲，學習項目實戰最重要的仍是學習項目管理，做爲程序員，都應該學點項目管理。

1. 凡事皆爲「項目」

2. 項目的兩類屬性（複雜的邏輯，龐大的信息量）

3. 人腦擅長的是思考，而不是記憶

4. 成爲一個「獨當一面」的人

獨當一面是一個很性感的詞。是否擁有它，對應的職場價值，有着天壤之別的。

全部老闆都喜歡「獨當一面」的員工，由於這是最省心力、最好算帳的模式：給你一塊資源，給你一個 title，給你一個目標，而後你給我打出一片天地來。

當你能獨立對一攤子事情負責，並把它們一一搞定，你會擁有大幅度的職場溢價——相應的，其收入回報，也遠非「技術螺絲」可比了。

若是你很進取，你會逐漸地：主導一個小組，一個部門，一個家庭，甚至仍是城市……而這全部的一切起點，正是獨立完整地作好一個項目：你沒有誰能夠依靠，你要對其中大大小小的事務負責，你要對最後的結果。

換句話說，「項目管理」是「獨當一面」的元能力。在這個過程當中，你的意識愈加清晰，你的方法論愈加成熟，你的信心更加沛，項目越作越大。直到某天，你真的有了掌控一方的封疆大吏。

這就是咱們學習「項目實戰」的終極意義。

或許做爲程序員的你想提高本身，卻找不到突破口，公司沒人帶。又或許你已經工做6年了，卻仍是很迷茫，不少知識都仍是不懂，也沒有達到本身指望的一個職位，薪資。在此推薦一個免費公開課的地方，上面所提到的架構師基本知識點都有資料，能夠加羣：433540541，找羣主獲取上課資格，這是免費的課程，找羣主要的時候能夠客氣一點。

到這裏，你可能認爲文章已經完了，學完這些就能夠去BAT大公司作一個架構師，年薪50W+嗎？

不，你錯了，這些都知識最基本的知識，想要成爲一個架構師必須是一個累積的過程，也是這麼多程序員終其一輩子也只是一個開發，到年齡就會被公司辭退。

這些也是架構師必需要了解到的知識。

編程能力

對工程師而言，編程是最基礎的能力，必備技能。其本質是一個翻譯能力，將業務需求翻譯成機器能懂的語言。

提高編程能力的書籍有不少。精通面向對象和設計模式是高效編程的基礎。初級工程師應該多寫代碼、多看代碼。找高手作Code Review，也是提高編程水平的捷徑。

編譯部署能力

編譯並在線上部署運行程序是系統上線的最後一個環節。隨着SOA架構的普及以及業務複雜度的增長，大部分系統只是一個完整業務的一個環節，所以，本地編譯和運行並不能徹底模擬系統在線運行。爲了快速驗證所編寫程序的正確性，編譯並在線上部署就成了必要環節。因此編譯部署能力是一個必備技能。

讓盤根錯節的衆多子系統運行起來是個不小的挑戰。得益於SOA架構的普及以及大量編譯、部署工具的發展，編譯部署的門檻已經大大下降。基於應用層進行開發的公司，已經不多有「編譯工程師」的角色了。可是對於初級工程師而言，編譯部署仍然不是一個輕鬆的事情。

性能優化能力

衡量一個系統成功的一個重要指標是使用量。隨着使用量的增長和業務複雜度的增長，大部分系統最終都會碰到性能問題。 性能優化能力是一個綜合能力。由於：

• 影響系統性能的因素衆多，包括：數據結構、操做系統、虛擬機、CPU、存儲、網絡等。爲了對系統性能進行調優，架構師須要掌握全部相關的技術。

• 精通性能優化意味着深入理解可用性、可靠性、一致性、可維護性、可擴展性等的本質。

• 性能優化與業務強耦合，最終所採起的手段是每每折衷的結果。因此，性能優化要深諳妥協的藝術。

能夠說，性能優化能力是工程師們成長過程當中各類技能開始融會貫通的一個標誌。這方面能夠參考以前的博客文章「常見性能優化策略的總結」。市場上還有不少與性能優化相關的書籍，你們能夠參考。多多閱讀開源框架中關於性能優化方面的文檔和代碼也不失爲好的提高手段。動手解決線上性能問題也是提高性能優化能力的關鍵。若是有機會，跟着高手學習，分析性能優化解決方案案例（咱們技術博客以前也發表了不少這方面的文章），也是快速提高性能優化能力的手段。

調試能力

程序代碼是系統的靜態形式，調試的目的是經過查看程序的運行時狀態來驗證和優化系統。本質上講，工程師們經過不斷調試能夠持續強化其經過靜態代碼去預測運行狀態的能力。因此調試能力也是工程師編程能力提高的關鍵手段。很早以前有個傳說：「調試能力有多強，編程能力就有多強。」不過如今不少編輯器的功能很強大，調試能力的門檻已經大大下降。

調試能力是項目可否按時、高質量提交的關鍵。即便一個稍具複雜度的項目，大部分工程師也沒法一次性準確無誤的完成。大項目都是經過不斷地調試進行優化和糾錯的。因此調試能力是不可或缺的能力。

多寫程序，解決Bug，多請教高手是提高調試能力的重要手段。

在線運維能力

若是說性能優化能力體現的是架構師的靜態思考能力，在線運維能力考驗的就是動態反應能力。殘酷的現實是，不管程序多麼完美，Bug永遠存在。與此同時，職位越高、責任越大，不少架構師須要負責很是重要的在線系統。對於線上故障，若是不能提早預防以及快速解決，損失可能不堪設想，因此在線運維能力是優秀架構師的必備技能。

爲了對線上故障進行快速處理，標準化的監控、上報、升級，以及基本應對機制固然很重要。經過所觀察到的現象，快速定位、緩解以及解決相關症狀也至關關鍵。這要求架構師對故障系統的業務、技術具有通盤解讀能力。解決線上故障的架構師就比如一個在參加比賽F1的車手。賽車手必需要了解自身、賽車、對手、同伴、天氣、場地等全部因素，快速決策，不斷調整。架構師必需要了解全部技術細節、業務細節、處理規範、同伴等衆多因素，快速決斷，迅速調整。

在線運維本質上是一個強化學習的過程。不少能力均可以經過看書、查資料來完成，但在線運維能力每每須要大量的實踐來提高。

業務架構能力

工程師抱怨產品經理的故事家常便飯，抱怨最多的主要緣由來自於需求的頻繁變動。需求變動主要有兩個來源：第一個緣由是市場改變或戰略調整，第二個緣由是僞需求。對於第一個緣由，不管是工程師仍是產品經理，都只能無奈的接受。優秀的架構師應該具有減小第二種緣由所致使的需求變動的機率。

僞需求的產生有兩個緣由：

第一個緣由是需求傳遞變形。從信息論的角度來說，任何溝通都是一個編碼和解碼的過程。典型的需求從需求方到產品經理，最終到開發工程師，最少須要經歷三次編碼和解碼過程。而信息的每一次傳遞都存在一些損失並帶來一些噪音，這致使有些時候開發出來的產品徹底對不上需求。此外，需求方和產品經理在需求可行性、系統可靠性，開發成本控制方面的把控比較弱，也會致使需求變形。

第二個緣由就是需求方徹底沒有想好本身的需求。

優秀的架構師應該具有辨別真僞需求的能力。應該花時間去了解客戶的真實業務場景，具有較強的業務抽象能力，洞悉客戶的真實需求。系統的真正實施方是工程師，在明確客戶真實需求後，高明的架構師應該具有準確判斷項目對可行性、可靠性、可用性等方面的要求，並能具有成本意識。最後，因爲需求與在線系統的緊耦合關係，掌握在線系統的各類細節也是成功的業務架構的關鍵。隨着級別的提高，工程師所面對的需求會愈來愈抽象。承接抽象需求，提供抽象架構是架構師走向卓越的必經之途。

市場上有一些關於如何成爲架構師的書，你們能夠參考。可是架構能力的提高，實踐多是更重要的方式。業務架構師應該關注客戶的痛點而不是PRD文檔，應該深刻關注真實業務。掌握現存系統的大量技術和業務細節也是業務架構師的必備知識。

項目管理能力

做爲工業時代的產物，分工合做融入在互聯網項目基因裏面。架構師也須要負責幾個重大項目才能給本身正名。以架構師角色去管理項目，業務架構能力固然是必備技能。此外，人員管理和成本控制意識也很是重要。

項目管理還意味着要有一個大心臟。重大項目涉及技術攻關、人員變更、需求更改等衆多可變因素。面臨各類變化，還要在確保目標順利達成，須要較強的抗壓能力。

人員管理須要注意的方面包括：知人善用，優化關係，簡化溝通，堅持真理。

• 知人善用意味着架構師須要瞭解每一個參與者的硬技能和軟素質。同時，關注團隊成員在項目過程當中的表現，按能分配。

• 優化關係意味着管理團隊的情緒，畢竟項目的核心是團隊，有士氣的團隊才能高效達成目標。

• 簡化溝通意味着快速決策，該妥協的時候妥協，權責分明。

• 堅持真理意味着頂住壓力，在原則性問題上毫不退步。

成本控制意味着對項目進行精細化管理，須要遵循以下幾個原則：

• 以終爲始、肯定里程碑。爲了達成目標，全部的計劃必須以終爲始來制定。將大項目分解成幾個小階段，控制每一個階段的里程碑能夠大大下降項目失敗的風險。

• 把控關鍵路徑和關鍵項目。按照關鍵路徑管理理論（CPM）的要求，架構師須要肯定每一個子項目的關鍵路徑，肯定其最先和最晚啓動時間。同時，架構師須要關注那些可能會致使項目總體延期的關鍵節點，並集中力量攻破。

• 掌控團隊成員的張弛度。大項目持續時間會比較長，也包含不一樣工種。項目實施是一個不斷變化的動態過程，在這個過程當中不是整個週期都很緊張，不是全部的工種都同樣忙。優秀的架構師必需要具有精細閱讀總體項目以及快速反應和實時調整的能力。這不只僅能夠大大下降項目成本，還能夠提升產出質量和團隊滿意度。整體來講，「前緊後鬆」是項目管理的一個重要原則。

項目管理方面的書籍不少。可是，提升業務架構能力一樣重要。積極參與大項目並觀察別人管理項目的方式也是很是重要的提高手段。

團隊管理能力

不想作CTO的工程師不是一個好的架構師。走向技術管理應該是工程師的一個主流職業規劃。團隊管理的一個核心能力就是規劃能力，這包括項目規劃和人員規劃。良好的規劃須要遵循以下原則：

• 規劃是利益的博弈。良好的規劃上面對得起老闆，中間對得起本身，下面對得起團隊。在三者利益者尋找平衡點，實現多方雙贏考驗着管理者的智慧和精細拿捏的能力。

• 任何規劃都比沒有規劃好。沒有規劃的團隊就是沒頭的蒼蠅，不符合全部人的利益。

• 規劃不是本本主義。市場在變，團隊在變，規劃也不該該一成不變。

• 客戶至上的是項目規劃的出發點。

• 就人員規劃而言，規劃須要考量團隊成員的能力、績效、成長等多方面的因素。

文章講到這裏已是終點了，但願能夠幫到還在迷茫的朋友，最後祝你們早日年薪50W，成爲架構師，歡迎留言和小編討論。