如何成爲架構師？7 個關鍵的思考、習慣和經驗！

工做了挺久，發現有個挺有意思的現象，從程序員、高級程序員，到如今掛着架構師、專家之類的頭銜，伴隨着技術和能力的提升，想不明白的事情反而愈來愈多了。這些疑問有些來自於跟小夥伴交流，有些是個人自問自答，有些到如今也想不清楚，這篇文章就來寫一寫這些問題。

如何更高效的學習？

不少新人程序員一開始在學習上找不到方向，但我想在渡過了一段時間的新手期以後這類問題大多都會變得再也不那麼明顯，工做的方向也會逐漸變得清晰起來。

可是沒過多久，能瞭解到的資料就開始超過天天學習的能力，像是買了沒看的書、收藏沒讀的貼、mark 了以後再也沒有關注過的文章越積越多，更別提天天面對各類技術分享或者微博裏的新鮮玩意了。

大多數人天天能留給本身學習的時間有限，這個階段如何提高學習效率就成了要解決的重點。

說說本身提高學習效率的心得，其實很是簡單：體系化的學習。

我曾經很喜歡看一些博客或者是一些 「看起來」 比較通俗易懂的文章，天天在微博微信裏刷到什麼技術文章就 mark 下來，基本上幾分鐘就能讀完。可一段時間下來，雖然讀了很多東西，可是仍是有種在原地打轉的狀態，並無感覺到有什麼實際的提升。

最後實在忍不住，抱着厚書硬啃了一遍，忽然有種豁然開朗的感受：讀書時本身學到的是一張完整的知識網絡，每一個知識點和其它內容相互聯繫和區別。這種全方位的理解比起一篇篇獨立的文章，不知要高到哪裏去了。

而讀了一段時間書以後，漸漸本來不在一個體系以內的知識也會慢慢聯繫起來，好比說後端服務的開發，簡單梳理一下，就成了這樣：

在重複了幾回痛苦的學習-梳理過程後，再去看一些獨立的文章或者資料每每會事半功倍，由於能在體系內找到相對應的知識，甚至有時候一本書裏一頁只須要看一句話，點破那層窗戶紙，就能夠掌握新的知識。

你是怎麼知道這些的？

工做中老是會遇到各類各樣的問題，有幾回把問題處理過程總結了一下，發了出來，以後就像滾雪球同樣，有愈來愈多的小夥伴來諮詢問題，好比說：

前一陣幫忙排查一個性能問題，系統壓力稍微一大就會頻繁 Full GC，壓力下降以後又恢復了。

某個小夥伴接入代碼質量檢查系統以後發現每次構建會報一個莫名其妙的錯誤，打不了包。

某次代碼有 bug，小夥伴跑來來問我 git 怎麼才能回滾代碼。

每次查完這種問題的時候，一些剛畢業沒多久小夥伴們就會用一種崇拜的眼神看着我，而後大多會問：「你是怎麼知道這些的？」

實際上，雖然我一直在不斷的學習，可是面對工做中無窮無盡的新問題，大部分問題仍是會命中我沒有掌握的那部分區域。每次有人問到我不瞭解的知識時我都會很是開心：還有什麼比帶着問題學習更有效率的學習方法呢？

並且幸運的是，在創建了本身的知識體系的基礎上，學習新的知識一般都能很快的上手，解決一個問題每每只須要多瞭解一個知識點而已。

舉個例子，頻繁 Full GC 的問題，之前查過不少次 GC 的問題，大多數是 Java 程序或 JVM 內存泄露問題，而此次內存沒有泄露，GC 吞吐量也正常，那麼我只須要查一下如何查看一段時間內建立的最多的對象的方法就能夠了。

回到剛纔的問題，小夥伴們問我：「你是怎麼學到這些的知識的？」

答案是：在你問我問題以後現學的。

架構師應不該該寫代碼？

彷佛隔三差五就能看到一些關於架構師應不該該寫代碼的文章。我是屬於寫代碼派，由於我自己就喜歡寫代碼。可是，當工做職責發生變化以後，如何保持寫代碼和其它工做之間的平衡就成了問題。

從個體效率上來看，我本身親自寫代碼，和不少人相比沒有什麼絕對優點，甚至有些人碼代碼的速度比我還快一些。

但做爲架構師，參與寫代碼仍是會有一些不大不小的收益。

通常來講合格的程序員對於明確分配的任務會完成的很好，可是大部分狀況下「架構」 這個詞意味着架構師並不會涉及太多細節，架構圖和代碼實現之間總仍是有些距離，你沒法保證全部人都會正確的理解你的設計，或者是程序員寫代碼時遇到障礙時會馬上想出足夠優雅的解決方案。

以前寫過一篇關於爛代碼的文章，大部分爛代碼並非架構師的設計問題，若是程序員沒能很好的理解設計或者是經驗不足，每每會作出一些很是匪夷所思的東西。好比我見過剛畢業的程序員爲了防止模塊耦合而將耦合的代碼又拷貝了一份，或者爲了 「優化性能」 而儘可能把全部邏輯寫在一個函數裏。

若是不能及時發現並改正這些問題，那麼這些地方就會變成「正確的錯誤代碼」，或者」 不是我寫的 「代碼，或者」 我靠我也看過那段代碼 「之類足以被掛上恥辱柱的玩意。這種問題算是架構師的責任嗎？做爲一個視名聲如命的架構師，我認爲是的。

在我看來，寫代碼的架構師更像是在作後勤保障的工做：在代碼中第一時間發現可能存在的問題，向其餘人提出警告，或是給予其餘人改進的意見，必要的時候或是給其餘人演示一下正確的姿式。

大部分狀況下我做爲架構師並不須要攬下 「核心模塊」 開發這種工做，畢竟我能調配的時間太零散了，效率難以保證，不少人在專一的狀況下比我作的好不少，我只須要保持大局觀須要適度參與就能夠了。

總的來講，架構師和程序員在某些方面上有點像產品經理和用戶的關係，大部分程序員並不會主動告訴你他們想要什麼、哪裏須要優化，甚至本身也不知道這些。想要作出好的產品，捷徑之一就是跟用戶作一樣的事情。

實踐：開會是個技術活嗎？

我以爲應該沒有人喜歡開會，身爲一個程序員，沒有幾我的的志向是當什麼職場交際花。

可是會議邀請就這麼一個個的跳了出來：開發需求要跟產品開會、項目方案要跟技術開會、新人轉正要去開評審會、別的公司來了幾個大牛正在開分享會、出了故障要開總結會、小組有周會、部門有周會，大項目每週開兩次碰頭會不過度吧？小項目啓動的時候開個會不過度吧？調試的時候發現有個坑你們趕忙討論討論吧？

有時候參加的會議整場下來跟我毛關係都沒有，全程神遊倆鐘頭，最後忽然有人一拍桌子：」 還有問題沒？好，散了！「也有可能有個什麼會沒叫你，過了倆禮拜忽然收到封郵件催開發進度，」 當時那個會你沒參加，你們都說應該是大家作……你沒看會議紀要嗎？「吐槽了這麼多，但我仍是認爲開會是個技術活，對於架構師來講尤爲如此。

大多數技術人員開會並非那種新聞裏的工做彙報或者長者們的會議，他們真的須要經過開會討論一個具體方案，或者解決什麼具體問題。惋惜的是我參加過不少會議，大多數的會議都是在毫無心義的交流中浪費時間：幾方人坐在一個屋裏互相說一些對方理解不了的話，最後得出一個」 咱們會後再捋一捋 「之類的結論。

這並非會議纔有的問題，在程序員平常的溝通中，也有不少人並不懂得如何交流，好比偶爾會收到一些寫的很是認真的郵件，打開以後是密密麻麻的一屏幕文字，可是從第一句開始就不知道他在說什麼，後面的東西連看的動力都沒有了。

大多數時候，溝通的核心不是你說了什麼，而是你想要讓對方瞭解什麼、讓他作什麼。良好的溝通能在工做中顯著提高效率，但不少人忽略了這個事情。

想要恰到好處的進行溝通是一件不那麼輕鬆的事情，可是簡單來講有幾條原則：

1. 確保各方對背景的理解一致，好比開會以前先簡單經過郵件交流一下，對新加入會議的人花個 30 秒鐘作個前情提要，或者在討論過程當中讓對方說一下他的理解。
2. 去掉對方不能 / 不須要理解的內容，好比跟產品說 「這個隊列在高併發下由於鎖的實現有問題致使 CPU 性能瓶頸」 不如改爲 「咱們發現了性能問題，持續 10 分鐘了，10 萬用戶收不到運營發的無節操廣告，大概 5 分鐘後擴容解決」。
3. 確保在對方失去注意力前儘快說出重點，好比排查問題的總結郵件，若是第一段是這樣：「某某框架內部使用的是 xxx 技術，這個技術的架構是這樣：blabla」，那麼對方可能徹底不知道你在講什麼。能夠換成這樣：「我發現了某某框架的 bug，須要儘快升級，不然在 xxx 狀況下有可能會出現 yyy 問題，具體排查過程以下：blabla」。
4. 不要說沒有意義的內容浪費其餘人的時間，好比」 這需求作不了 「或者」 這裏不可能出 bug 「，沒有人想聽到這些廢話。

爲何別人的系統老是那麼爛？

不少程序員解決問題的能力很強，說要解決一個什麼問題，下午就能寫出幾百行代碼把功能實現了。可是作出來的東西有種少考慮了什麼東西的感受，我花了挺久去想一個詞去形容 「這個東西」，最後想出了個勉強能夠表達的詞：程序的生命力。

大部分程序都能實現功能，可是若是把 「時間」 這個也做爲一個考慮的維度的話，就會意識到一個合格的項目須要考慮更多的東西：更通用的使用方式、易於理解的文檔、簡單而易於擴展的設計，等等。而想要毀掉程序的生命力也很簡單：作的更復雜，更定製化，讓更少的人蔘與。

我跟不少程序員提過程序的生命力，好比說要讓本身寫的工具的操做方式跟其它 Linux 命令相似，或者要用一些更容易理解但不是性能最優的設計方式，又或者要他去參考如今業界主流的作法，不少人認爲提這種需求的意義不大，我以爲這裏仍是舉個例子吧。

不少公司應該都會有一些遺留系統，它們龐大、笨重、難用、幾乎沒法維護，全部人都在抱怨這些系統，而且天天都在千方百計換掉那些遺留系統。可是一段時間過去以後，又會發現身邊的新人又開始吐槽當時替代遺留系統的那個系統了。

「大多數系統當初都很好使，功能當時夠用，擴展性看起來也能夠，可是這些系統都是開發的人離職以後變壞的。」

還有更好的辦法嗎？

成爲技術專家以後的工做能夠說是痛並快樂着，會有不少人找你諮詢問題，另外一方面，會有太多人找你諮詢問題。

甚至有一段時間我天天的工做就是解答問題，小到工具使用中到疑難 bug，大到架構設計，從早上到晚上基本都是在給各類各樣的小夥伴提供諮詢服務。

我很快發現有些地方不對頭：有些問題實在是太簡單了，以致於我甚至都不用思考就能夠給出答案，爲何會有這種問題？

後來我在每次回答以前先問一句：

「你還有更好的辦法嗎？」

一小部分人馬上能給出優化後的版本，甚至我連續問幾回以後，他能給出好幾個優化後的版本；另小一部分人會斬釘截鐵的說優化不了了，就這樣了。可是大部分人會猶猶豫豫的說出一些徹底不着調的回答。

後來我改爲在每次回答以前先問兩句：

「你要解決什麼問題?」

「還有更好的辦法嗎？」

效果好了不少，不少小夥伴發現要解決的問題並不複雜，只是作法跑偏了。

再後來我改爲了在每次回答以前先問三句：

「他們要你解決什麼問題？」

「你解決的是什麼問題？」

「還有更好的辦法嗎？」

如今第三句已經不多問到了。

成爲架構師最困難的門檻是什麼？

跟一些程序員交流的過程當中，有很多人問我要怎麼成爲一名牛逼的架構師。

我最近幾年面試的人挺多，發現一個有意思的現象：不少人自稱架構師的人跟你講一個架構時簡直口若懸河，各類技術名詞像是說相聲同樣從他嘴裏說出來，三句話不離高併發大數據，可是稍微追問一下，就會發現不少基本概念的缺失，例如自稱精通高併發的人說不清楚他所謂的高併發系統的瓶頸在哪裏，自稱精通架構設計的人說不明白他的系統怎麼保證高可用，自稱超大數據量的系統實際上只有不到 100 萬條數據，等等。

架構師雖然聽起來很高大上，但本質上仍然是工程師，不是科學家，也不是忽悠人的江湖騙子。學習再多，也須要實踐落地。設計架構方案更多的是在作一些抽象和權衡：把複雜的需求抽象成簡單的模型，從功能、性能、可用性、研發成本等等方面規劃如何構建一個系統，這些內容須要更多的實踐練習。

不少人沒有工做在相似微博平臺這種每天須要接觸架構設計的地方，而不少公司沒有架構方面的工做可供他們練級，因而就想辦法從理論上下功夫，這類人的特徵很是明顯：在信息不足，甚至不瞭解實際場景的狀況下就開始作架構設計，這種所謂的架構每每理解比較膚淺，經不住推敲。

每一年招人以後咱們都會作一些針對新人的架構方面的培訓，課程材料基本上包括了高可用架構相關的主要方面，可是學完這些材料以後就能成爲獨當一面的架構師了嗎？並無。相反，這僅僅是開始，新人真正作了幾個併發量上萬的系統以後纔算是正式入門：面對壓力時纔會懂得權衡，走過彎路以後纔會尋找捷徑。

因此我認爲在架構師（和其它不少）的工做中最重要的部分是實踐，誇誇其談很容易，與其拽一些技術名詞，不如把你正在作的系統真正的作好。

我和大牛之間有多少距離？

跟不少人同樣，剛畢業時我以爲做爲程序員，只要努力，加上少量天賦即可以得到一些成績。

工做一段時間後，對本身和其餘人的認識也愈來愈清晰，逐漸的發現程序員之間的差距或許比人和猴子之間的差距還大，接受這個事實這讓我鬱悶了好久。

再過一段時間，發現本身已經可以客觀的評價本身的能力，也意識到了距離並非那麼重要，只要想辦法跑的更快，就足夠了。

成爲架構師必不可缺的技能

你們都知道，性能一直是讓程序員比較頭疼的問題。當系統架構變得複雜而龐大以後，性能方面就會降低，若是想成爲一名優秀的架構師，性能優化就是你必須思考的問題。
因此性能優化專題從JVM底層原理到內存優化再到各個中間件的性能調優，好比Tomcat調優，MySQL調優等，讓你洞悉性能本質，全面認識性能優化，再也不只是旁觀者。有了大牛的代碼功底以後，接下來能夠更好地學習分佈式架構技術。
透徹理解分佈式架構的好處和優勢必然性，適應市場需求，可以去找一些更大的平臺發展，提高本身的綜合技術能力和薪資。
瞭解從傳統架構到分佈式架構演變過程所帶來的技術變革，將理論和實戰相結合，透徹理解分佈式架構及其解決方案。
從分佈式架構原理，到分佈式架構策略，再到分佈式架構中間件，最後在加上分佈式架構實戰，讓程序員能夠在技術深度和技術廣度上獲得飛躍的提高，成爲互聯網行業所須要的T型人才。這張圖詳細介紹了源碼中所用到的經典設計思想及經常使用設計模式，先打好內功基礎，瞭解大牛是如何寫代碼的，從而吸取大牛的代碼功力。

結合Spring5和MyBatis源碼，帶你理解做者框架思惟，幫助你們尋找分析源碼的切入點，在思想上來一次巨大的昇華。隨着業務的發展，代碼量的膨脹和團隊成員的增長，傳統單體式架構的弊端愈來愈凸顯，嚴重製約了業務的快速創新和敏捷交付。爲了解決傳統單體架構面臨的挑戰，前後演進出了SOA服務化架構、RPC框架、分佈式服務框架，最後就是當今很是流行的微服務架構。微服務化架構並不是銀彈，它的實施自己就會面臨不少陷阱和挑戰，涉及到設計、開發、測試、部署、運行和運維等各個方面，一旦使用不當，則會致使整個微服務架構改造的效果大打折扣，甚至失敗。
一名優秀的架構師必須有適合本身的兵器，也就是工欲善其事必先利其器，無論是小白，仍是資深開發，都須要先選擇好的工具。工程化專題的學習能幫助你和團隊提高開發效率，讓本身有更多時間來思考。
Git：能夠更好地管理你和你團隊的代碼。
Maven：能夠更好地管理jar包和項目的構建等。
Jenkins：能夠更好地持續編譯，集成，發佈你的項目。
Sonar：一個開源的代碼質量分析平臺，便於管理代碼的質量，可檢查出項目代碼的漏洞和潛在的邏輯問題(提高代碼的質量，更加高效地提高開發效率)。電商項目目的是把所學的分佈式，微服務，性能調優等知識運用起來，只有在項目中你才能鞏固知識，提高本身。實踐電商項目會利用雲服務器搭建真實的開發和部署環境，讓你從零到項目實戰，體驗真實的企業級項目開發過程，讓你具有獨立開發和搭建分佈架構系統的能力。

---

總結

其實要輕鬆掌握很簡單，要點就兩個：

• 1. 找到一套好的視頻資料，緊跟大牛梳理好的知識框架進行學習。
• 1. 多練。 （視頻優點是互動感強，容易集中注意力）

**你不須要是天才，也不須要具有強悍的天賦，只要作到這兩點，短時間內成功的機率是很是高的。
對於不少初級Java工程師而言，想要提高技能，每每是本身摸索成長，不成體系的學習效果低效漫長且無助。下面資料部分截圖，誠意滿滿：特別適合有1-5年開發經驗的Java程序員們學習。**

資料獲取方式： QQ羣搜索「708-701-457」便可免費領取