前言
成為優秀的架構師是大部分初中級工程師的階段性目標。優秀的架構師往往具備七種核心能力：程式設計能力、除錯能力、編譯部署能力、效能優化能力、業務架構能力、線上運維能力、專案管理能力和規劃能力。
這幾種能力之間的關係大概如下圖。程式設計能力、除錯能力和編譯部署能力屬於最基礎的能力。不能精通掌握這三種能力，很難在效能優化能力和業務架構能力方面有所成就。具備了一定的效能優化能力和業務架構能力之後，才能線上運維能力和專案管理能力方面表現優越。團隊管理能力是最高能力，它對專案管理能力的依賴度更大。
基本知識
1.學會分析原始碼
程式設計師每天都和程式碼打交道。經過數年的基礎教育和職業培訓，大部分程式設計師都會「寫」程式碼，或者至少會抄程式碼和改程式碼。但是，會讀程式碼的並不在多數，會讀程式碼又真正讀懂一些大專案的原始碼的，少之又少。這種怪狀，真要追究起來，怪不得程式設計師這個群體本身 —— 它是兩個原因造成的：
- 我們所有的教育和培訓都在強調怎麼寫程式碼，並沒有教大家如何讀程式碼
- 大多數工作場景都是一個蘿蔔一個坑，我們只需要瞭解一個系統的區域性便能開展工作，讀不相干的程式碼，似乎沒用
讀原始碼三問：“為什麼要有這樣的架構”，“他是什麼樣子的”，“他是怎麼工作的”。
那麼阿里程式設計師是如何去讀程式碼的呢？
2.分散式架構特點及設計理念
首先需要說明的是，分散式系統是一個複雜且寬泛的研究領域，學習一兩門線上課程，看一兩本書可能都是不能完全覆蓋其所有內容的。介於這篇文章是引導初學者入門，所以我個人覺得為初學者介紹一下當前分散式系統領域的全貌，也許比直接推薦論文和課程更有幫助。當初學者對這個領域建立起一個大的 Picture 之後，可以根據自己的興趣，有選擇性的深入不同領域進行進一步的學習。
3.為什麼微服務會這麼火？
要學習微服務，首先，我們要了解為什麼使用微服務。
- 程式碼難以理解？
- 構建和部署耗時長，難以定位問題，開發效率低？
- 單體只能按整體橫向擴充套件，無法分模組垂直擴充套件？
- 一個bug有可能引起整個應用的崩潰？
- 受技術棧限制，團隊成員使用同一框架和語言？
那麼如何解決單體的不足呢，通過遷移到微服務架構來解決，我們看一下什麼是微服務。
微服務架構:將單體應用拆分為多個高內聚低耦合的小型服務，每個小服務執行在獨立程式，由不同的團隊開發和維護，服務間採用輕量級通訊機制，獨立自動部署，可以採用不同的語言及儲存。
單體架構整個團隊維護開發一個大工程及一個單庫，到了微服務架構，使用者請求經過API Gateway被路由到下游服務，服務之間以輕量級通訊協議進行通訊，服務通過註冊中心發現彼此，每個服務都有專門的開發維護團隊，每個服務對應獨立的資料庫，服務獨立開發，獨立部署和上線。
接下來我們總結下微服務的優點。
- 易於開發與維護
- 微服務相對小，易於理解
- 啟動時間短，開發效率高
- 獨立部署
- 一個微服務的修改不需要協調其它服務
- 伸縮性強
- 每個服務都可以在橫向和縱向上擴充套件
- 每個服務都可按硬體資源的需求進行獨立擴容
- 與組織結構相匹配
- 微服務架構可以更好將架構和組織相匹配
- 每個團隊獨立負責某些服務，獲得更高的生產力
- 技術異構性
- 使用最適合該服務的技術
- 降低嘗試新技術的成本
下面就送上學習架構圖吧
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年，一輩子還只是一個開發者。程式設計師們都要想一想這個問題，我是不是需要提升了。
我認為，學習專案實戰最重要的還是學習專案管理，作為程式設計師，都應該學點專案管理。
- 凡事皆為“專案”
- 專案的兩類屬性（複雜的邏輯，龐大的資訊量）
- 人腦擅長的是思考，而不是記憶
- 成為一個“獨當一面”的人
獨當一面是一個很性感的詞。是否擁有它，對應的職場價值，有著天壤之別的。
所有老闆都喜歡“獨當一面”的員工，因為這是最省心力、最好算賬的模式：給你一塊資源，給你一個 title，給你一個目標，然後你給我打出一片天地來。
當你能獨立對一攤子事情負責，並把它們一一搞定，你會擁有大幅度的職場溢價——相應的，其收入回報，也遠非“技術螺絲”可比了。
如果你很進取，你會逐漸地：主導一個小組，一個部門，一個家庭，甚至還是城市……而這所有的一切起點，正是獨立完整地做好一個專案：你沒有誰可以依靠，你要對其中大大小小的事務負責，你要對最後的結果。
換句話說，“專案管理”是“獨當一面”的元能力。在這個過程中，你的意識越發清晰，你的方法論越發成熟，你的信心更加沛，專案越做越大。直到某天，你真的有了掌控一方的封疆大吏。
這就是我們學習“專案實戰”的終極意義。
或許作為程式設計師的你想提升自己，卻找不到突破口，公司沒人帶。又或許你已經工作6年了，卻還是很迷茫，很多知識都還是不懂，也沒有達到自己期望的一個職位，薪資。在此推薦一個免費公開課的地方，上面所提到的架構師基本知識點都有資料，可以加群：744642380 ，找群主獲取上課資格，這是免費的課程，找群主要的時候可以客氣一點。
到這裡，你可能認為文章已經完了，學完這些就可以去BAT大公司做一個架構師，年薪50W+嗎？
不，你錯了，這些都知識最基本的知識，想要成為一個架構師必須是一個累積的過程，也是這麼多程式設計師終其一生也只是一個開發，到年齡就會被公司辭退。
這些也是架構師必須要了解到的知識。
程式設計能力
對工程師而言，程式設計是最基礎的能力，必備技能。其本質是一個翻譯能力，將業務需求翻譯成機器能懂的語言。
提升程式設計能力的書籍有很多。精通物件導向和設計模式是高效程式設計的基礎。初級工程師應該多寫程式碼、多看程式碼。找高手做Code Review，也是提升程式設計水平的捷徑。
編譯部署能力
編譯並線上上部署執行程式是系統上線的最後一個環節。隨著SOA架構的普及以及業務複雜度的增加，大部分系統只是一個完整業務的一個環節，因此，本地編譯和執行並不能完全模擬系統線上執行。為了快速驗證所編寫程式的正確性，編譯並線上上部署就成了必要環節。所以編譯部署能力是一個必備技能。
讓盤根錯節的眾多子系統執行起來是個不小的挑戰。得益於SOA架構的普及以及大量編譯、部署工具的發展，編譯部署的門檻已經大大降低。基於應用層進行開發的公司，已經很少有“編譯工程師”的角色了。但是對於初級工程師而言，編譯部署仍然不是一個輕鬆的事情。
效能優化能力
衡量一個系統成功的一個重要指標是使用量。隨著使用量的增加和業務複雜度的增加，大部分系統最終都會碰到效能問題。 效能優化能力是一個綜合能力。因為：
- 影響系統效能的因素眾多，包括：資料結構、作業系統、虛擬機器、CPU、儲存、網路等。為了對系統效能進行調優，架構師需要掌握所有相關的技術。
- 精通效能優化意味著深刻理解可用性、可靠性、一致性、可維護性、可擴充套件性等的本質。
- 效能優化與業務強耦合，最終所採取的手段是往往折衷的結果。所以，效能優化要深諳妥協的藝術。
可以說，效能優化能力是工程師們成長過程中各種技能開始融會貫通的一個標誌。這方面可以參考之前的部落格文章“常見效能優化策略的總結”。市場上還有很多與效能優化相關的書籍，大家可以參考。多多閱讀開源框架中關於效能優化方面的文件和程式碼也不失為好的提升手段。動手解決線上效能問題也是提升效能優化能力的關鍵。如果有機會，跟著高手學習，分析效能優化解決方案案例（我們技術部落格之前也發表了很多這方面的文章），也是快速提升效能優化能力的手段。
除錯能力
程式程式碼是系統的靜態形式，除錯的目的是通過檢視程式的執行時狀態來驗證和優化系統。本質上講，工程師們通過不斷除錯可以持續強化其通過靜態程式碼去預測執行狀態的能力。所以除錯能力也是工程師程式設計能力提升的關鍵手段。很早之前有個傳說：“除錯能力有多強，程式設計能力就有多強。”不過現在很多編輯器的功能很強大，除錯能力的門檻已經大大降低。
除錯能力是專案能否按時、高質量提交的關鍵。即使一個稍具複雜度的專案，大部分工程師也無法一次性準確無誤的完成。大專案都是通過不斷地除錯進行優化和糾錯的。所以除錯能力是不可或缺的能力。
多寫程式，解決Bug，多請教高手是提升除錯能力的重要手段。
線上運維能力
如果說效能優化能力體現的是架構師的靜態思考能力，線上運維能力考驗的就是動態反應能力。殘酷的現實是，無論程式多麼完美，Bug永遠存在。與此同時，職位越高、責任越大，很多架構師需要負責非常重要的線上系統。對於線上故障，如果不能提前預防以及快速解決，損失可能不堪設想，所以線上運維能力是優秀架構師的必備技能。
為了對線上故障進行快速處理，標準化的監控、上報、升級，以及基本應對機制當然很重要。通過所觀察到的現象，快速定位、緩解以及解決相關症狀也相當關鍵。這要求架構師對故障系統的業務、技術具備通盤解讀能力。解決線上故障的架構師就好比一個在參加比賽F1的車手。賽車手必須要了解自身、賽車、對手、同伴、天氣、場地等所有因素，快速決策，不斷調整。架構師必須要了解所有技術細節、業務細節、處理規範、同伴等眾多因素，快速決斷，迅速調整。
線上運維本質上是一個強化學習的過程。很多能力都可以通過看書、查資料來完成，但線上運維能力往往需要大量的實踐來提升。
業務架構能力
工程師抱怨產品經理的故事屢見不鮮，抱怨最多的主要原因來自於需求的頻繁變更。需求變更主要有兩個來源：第一個原因是市場改變或戰略調整，第二個原因是偽需求。對於第一個原因，無論是工程師還是產品經理，都只能無奈的接受。優秀的架構師應該具備減少第二種原因所導致的需求變更的概率。
偽需求的產生有兩個原因：
第一個原因是需求傳遞變形。從資訊理論的角度來講，任何溝通都是一個編碼和解碼的過程。典型的需求從需求方到產品經理，最終到開發工程師，最少需要經歷三次編碼和解碼過程。而資訊的每一次傳遞都存在一些損失並帶來一些噪音，這導致有些時候開發出來的產品完全對不上需求。此外，需求方和產品經理在需求可行性、系統可靠性，開發成本控制方面的把控比較弱，也會導致需求變形。
第二個原因就是需求方完全沒有想好自己的需求。
優秀的架構師應該具備辨別真偽需求的能力。應該花時間去了解客戶的真實業務場景，具備較強的業務抽象能力，洞悉客戶的真實需求。系統的真正實施方是工程師，在明確客戶真實需求後，高明的架構師應該具備準確判斷專案對可行性、可靠性、可用性等方面的要求，並能具備成本意識。最後，由於需求與線上系統的緊耦合關係，掌握線上系統的各種細節也是成功的業務架構的關鍵。隨著級別的提升，工程師所面對的需求會越來越抽象。承接抽象需求，提供抽象架構是架構師走向卓越的必經之途。
市場上有一些關於如何成為架構師的書，大家可以參考。但是架構能力的提升，實踐可能是更重要的方式。業務架構師應該關注客戶的痛點而不是PRD文件，應該深入關注真實業務。掌握現存系統的大量技術和業務細節也是業務架構師的必備知識。
專案管理能力
作為工業時代的產物，分工合作融入在網際網路專案基因裡面。架構師也需要負責幾個重大專案才能給自己正名。以架構師角色去管理專案，業務架構能力當然是必備技能。此外，人員管理和成本控制意識也非常重要。
專案管理還意味著要有一個大心臟。重大專案涉及技術攻關、人員變動、需求更改等眾多可變因素。面臨各種變化，還要在確保目標順利達成，需要較強的抗壓能力。
人員管理需要注意的方面包括：知人善用，優化關係，簡化溝通，堅持真理。
- 知人善用意味著架構師需要了解每個參與者的硬技能和軟素質。同時，關注團隊成員在專案過程中的表現，按能分配。
- 優化關係意味著管理團隊的情緒，畢竟專案的核心是團隊，有士氣的團隊才能高效達成目標。
- 簡化溝通意味著快速決策，該妥協的時候妥協，權責分明。
- 堅持真理意味著頂住壓力，在原則性問題上絕不退步。
成本控制意味著對專案進行精細化管理，需要遵循如下幾個原則：
- 以終為始、確定里程碑。為了達成目標，所有的計劃必須以終為始來制定。將大專案分解成幾個小階段，控制每個階段的里程碑可以大大降低專案失敗的風險。
- 把控關鍵路徑和關鍵專案。按照關鍵路徑管理理論（CPM）的要求，架構師需要確定每個子專案的關鍵路徑，確定其最早和最晚啟動時間。同時，架構師需要關注那些可能會導致專案整體延期的關鍵節點，並集中力量攻破。
- 掌控團隊成員的張弛度。大專案持續時間會比較長，也包含不同工種。專案實施是一個不斷變化的動態過程，在這個過程中不是整個週期都很緊張，不是所有的工種都一樣忙。優秀的架構師必須要具備精細閱讀整體專案以及快速反應和實時調整的能力。這不僅僅可以大大降低專案成本，還可以提高產出質量和團隊滿意度。總體來說，“前緊後鬆”是專案管理的一個重要原則。
專案管理方面的書籍很多。但是，提高業務架構能力同樣重要。積極參與大專案並觀察別人管理專案的方式也是非常重要的提升手段。
團隊管理能力
不想做CTO的工程師不是一個好的架構師。走向技術管理應該是工程師的一個主流職業規劃。團隊管理的一個核心能力就是規劃能力，這包括專案規劃和人員規劃。良好的規劃需要遵循如下原則：
- 規劃是利益的博弈。良好的規劃上面對得起老闆，中間對得起自己，下面對得起團隊。在三者利益者尋找平衡點，實現多方共贏考驗著管理者的智慧和精細拿捏的能力。
- 任何規劃都比沒有規劃好。沒有規劃的團隊就是沒頭的蒼蠅，不符合所有人的利益。
- 規劃不是本本主義。市場在變，團隊在變，規劃也不應該一成不變。
- 客戶至上的是專案規劃的出發點。
- 就人員規劃而言，規劃需要考量團隊成員的能力、績效、成長等多方面的因素。
文章講到這裡已經是終點了，希望可以幫到還在迷茫的朋友，最後祝大家早日年薪50W，成為架構師，歡迎留言和小編討論。