如果走技術路線，架構師是個關鍵的結點。如果在大廠，一般有有6年時間足以升級到高階開發。因為在大廠裡，能提供架構師所需的分散式元件開發除錯以及上線的經驗，上進點的程式設計師只要跟著大流，多透過排查問題觀察底層，多透過壓測或部署元件多實踐快取、高併發高可能之類的技術，想不升級到架構師都難。

但不少程式設計師止步於高階開發，在我之前的博文為什麼很多程式設計師沒有升級到架構師？裡講述了這一現象並分析了原因。如果是因為主觀不上進導致自身發展受限，那麼別人也幫不了你，不過我在面試候選人的時候，發現一些態度積極的程式設計師把時間和精力用在了不正確的技術方面，從而無法升級，這是相當可惜的。在本文裡，就先從反面講，哪些技術可以在升級到架構師以後再看，同時講下從高階開發升級到架構師的關鍵技術，以及實踐方法。

1 理論方面的知識，不必整本書地學

像網路，Linux作業系統，編譯原理等理論方面的書籍，一般很厚，不過幸好，此類知識可以邊學邊看，比如要看linux執行緒併發方面的知識時，再看相關資料也不遲。

這裡將綜合多個大廠面試和開發的標準，給出理論方面需要掌握的普遍標準，反之沒提到的就可以用到再學。

1 資料結構方面，瞭解連結串列，佇列，堆疊，線性表，樹和矩陣，圖以及更復雜的無需瞭解，然後結合一種語言，比如Java，瞭解對應的物件，比如ArrayList。同時瞭解下紅黑樹，二叉樹之類的概念，或許面試會問到

2 編譯原理，瞭解狀態機概念，可能會用到。

3 網路方面，理解七層網路協議，外帶了解下tcp，udp和http協議細節即可

4 Linux方面，稍微會寫命令即可。

5 資料庫原理方面，也就瞭解些概念即可，比如索引原理，事務，正規化和鎖即可。

總之，與其花時間看整本理論方面的書，還不如多敲些實際的程式碼。

2 專案管理方面的技能，需結合實際，而無需啃書

這方面有很多經典，但看百本書，比如實踐一個月，這方面的建議是，在架構師之前的階段，看些相關軟體管理的實踐要點即可，比如敏捷開發裡，頭腦風暴以及迭代釋出的實踐要點，而且最好和你當前從事的軟體管理模式相匹配，比如你現在用的是敏捷模式，那麼就關於詳細設計概要設計等文件的編寫方式，大致瞭解下格式即可，也無需深入。

還是這句話，這方面的一些經典書，當你成為專案經理或高層以後，再看不遲，而且到了這個層次看了很有幫助。不過話說回來，目前在大多數的公司裡，不是你在專案管理方面的技能很資深才提拔你成為專案經理，而是你對業務有一定了解，同時技術，尤其是解決問題的能力達到一定水平 ，而且溝通協調方面的能力還不錯，才提升你。

在成為架構師之前，專案管理方面的技能大致要了解到什麼程度呢？比如拿敏捷開發舉例。

1 每天站會該如何組織，如何表面自己已做，未做和當做的事，如何表明自己任務的阻礙點。

2 如何維護每天站會所需的看板，看板上該有哪些模組，相關任務點該怎麼寫。

如果到了專案經理級別，還得會用看板，站會和任務紙條等方式管理專案，以及控制風險，但如果僅僅是架構師之前的開發，瞭解這兩點即可，不用看過多其它的資料。所以為了升級到架構師，更應當把時間用在分散式等技能上。

3 虛擬機器，底層程式碼，一定要對景實際問題，別脫離實際去看

我見過不少虛擬機器方面的書，非常經典，從底層和細節全面講述了虛擬機器的結構和GC流程，同時也看過不少關於位元組碼結構方面的資料，此外，我也見了不少深入細節講執行緒的書。這些書在面試方面對人的幫助優於提升技能方面。

為什麼不建議在升級到架構師之前，過多看虛擬機器等方面理論的資料呢？第一平時開發用到的可能性不大，第二看不用不久就會忘掉，第三對解決調優高併發之類的問題，也沒什麼太大的幫助。

而且，對於底層程式碼，也要解決問題去看，不建議大面積地看諸如集合，Spring IOC底層的原始碼。比如某天遇到因Kafka而導致的OOM異常，那麼可以透過Debug到底層看訊息相關流程，再排查問題，除錯MyCAT的問題也可以這樣。總之如果帶有排查問題的目的，針對性很強，非常有幫助，就像圍繞語境學習常用英語單詞和片語，但如果大面試去看底層程式碼，就好比背字典，效果大家可以想象。

4 設計模式，軟體重構之類的技能應放在專案大環境，別抽象學，更全面鋪開學

這方面也有不少經典，可謂字字珠璣。這裡我提兩個問題。

第一，面試時如何考察這方面的技能？估計是問“你用過哪些設計模式？”，大家結合專案敘述下即可。

第二，在工作中你接收了一段程式碼，在此技術上新增功能，你敢按設計模式和軟體重構方面的知識，重構現有程式碼嗎？估計不敢，因為風險太大。

那麼這方面的技能對程式設計師有什麼幫助呢？

第一固然是面試時幫助加分，第二能讓你在解決問題時有更多的方案，比如實現通知回撥類需求可以用觀察者模式，第三能幫助你的程式碼看上去不難看。

比如一些文學名著，對我們的幫助更多的是陶冶情操多漲知識，設計模式和軟體重構類的著作能幫我們提升在軟體開發方面的素養，在升級到架構師之前，這方面該掌握到什麼程度呢？

1 瞭解必要的設計模式，而不是23種都面面俱到，需要結合專案問題了解，同時面試時，能結合你解決過的問題說明某些設計模式的細節。

2 瞭解軟體重構方面的結論，比如哪類程式碼不好，該如何重構？

要達到這個程度，所需花費的精力並不多，但如果用大量時間看這方面純理論的書，而不結合專案實際有選擇性地調個別點來看，那麼到了架構師以後，你會發現當初學的很多點對你的幫助並不大。

5 面試時如何考察架構師？架構師平時幹哪些活？

在前文裡，給出了一些無需著重看的技能點，無需著重看，並不是慫恿大家不學習，而是把看這些技能的時間用在能立竿見影出效果的技能上。

在講架構師哪些技能不可缺之前，我們先來看下面試架構師的問題。

第一層問理論和實踐細節，比如Netty的序列化方式，以及Dubbo針對不同級別設定超時時間的方式。

第二層問分散式調優和解決實際問題的技巧，比如如何配置MySQL主從模式，如何配置MyCAT讀寫分離外帶高可用，如何壓測，如何根據壓測結果調優程式碼。

第三層問底層細節，比如dubbo協議，Netty讀寫索引的細節，kafka持久化，Redis超時失效機制等方面。

第四層是針對資深架構，問如何根據業務設計高併發框架，比如秒殺系統如何實現。

為什麼要問這些呢？因為招進來的架構師需要在平時工作中幹這些活，哪方面的活呢？

第一固然是高階開發所需的，分析和解決程式碼層面的問題。

第二是出了分散式元件方面的問題，首先知道該看哪些底層程式碼，即瞭解元件的重要元件和工作流程。而且這方面要有經驗，比如出了Netty OOM問題，得知道該從堆外記憶體等方面排查，而且得優先檢查通訊結束時release部分的程式碼，如果沒問題再debug。這才是架構師比高階開發值錢的點。

第三得給出面向高併發高可用的方案，比如搭建負載均衡和限流元件等，而且不光是理論層面的，還得負責部署上線。

其實在我之前相關博文裡，已經給出了類似內容， 上文只是總結。在下文裡，將面向這個目標，給出升級到架構師不可或缺的技能，以及如何高效掌握這些技能。

6 要熟悉解決異常問題方面的元件技能

理論方面的技能應該很多，網上有很多xx大廠的面試題，而且大家只要稍微上心點，應該也能看到理論方面的相關技能，比如Netty重要元件，Netty協議等，但如果光知道這些用處不大，還得繼續看解決異常方面的技能。

比如為了Dubbo超時會有什麼危害，如何防治？或者Netty執行緒池滿了以後該如何優雅降級。如何掌握這方面的技能呢？

第一到網上搜，比如用 Netty OOM異常，Netty 線上問題排查 等關鍵字查，這樣好歹能知道該看哪些方面。我在部落格園上就看到不少結合問題分析分散式元件的文章。

第二結合平時遇到的線上問題看底層程式碼，分析為什麼會出錯，也就是說結合實踐看。如果沒機會實踐怎麼辦？大廠裡一般可以找其它組， 小公司一般比較全棧，估計在部門裡多觀察即可。

比如遇到一個MyCAT問題，大家可以先按照大神分析問題的步驟，再除錯一遍程式碼，覆盤下大神排查問題的思路，然後再擴大看下這個流程的細節，以及MyCAT的元件，這樣哪怕一週遇到一次問題，一個月也有四次實踐學習的機會，積累個半年，你的能力就大漲了。比起單純看資料，這樣的升級效率就高多了。

7 更要掌握全棧流程的分散式元件部署技能

這方面，要多向運維學習，小到linux命令和shell指令碼，中到系統上線，大到擴容，你未必動手敲程式碼，但可以參與值班。架構師所需的高可能高併發技能是虛的，下面給出這方面的具體技能。

1 能透過jenkins或shell指令碼部署元件的能力，系統上線時，需要了解灰度釋出切流量的實踐技巧。

2 未必需要了解底層，但需要配置高可用的叢集，比如redis叢集，一臺機器出故障，第一會報警，第二能自動切換。

3 需要掌握優雅停機和遷移擴容的實踐技巧，比如遷移服務時，如何設定優雅停機，擴容時，第一如何起新服務，第二如何把流量切到新服務上，第三如何設定回退預案。

4 如何組織壓測，如何在壓測時監控關鍵指標，如何根據壓測結果最佳化效能。

還是這句話，如果當前沒機會參與，就先在邊上看，等給出結論後，再自己覆盤看下相關技能的實踐要點。這些技能就比較難得了，網上類似資料有，但很少，而且需要自己組織，所以更需要在平時工作中主動積累。我見過很多高階開發，平時也就注重在windows上開發業務，由於工作中用不到，他們為圖省事，不去參與部署壓測和擴容方面的工作，結果會在高階開發的階段停滯不前，最後年齡上來了，導致無法升級。

8 隨後才是看些面試題應對面試

我也知道，如果當前處於初級和高階開發階段，平時被分配的工作任務很少涉及到上述架構師所需要的技能，但並不意味著你身邊就沒有架構師，工作中就看不到這方面的技能，當你透過觀察覆盤，結合案例掌握了架構師相關技能後，如果在大廠，那麼自然有機會升級到架構師，但如果在小公司，那麼你就需要多刷相關面試題了。

這方面的題太多了，比如redis面試50題，xx大廠 dubbo面試xx題。如果光看這些題，面試官一旦結合案例問dubbo細節，一定能問出你沒相關經驗。如果被問出沒相關實踐經驗，那麼甚至你面不上大廠的高階開發崗，更別提架構師了。

但現在你已經積累了案例經驗，那透過刷題積累更廣泛的技能，那麼面試架構師，甚至面試大廠架構師，都不是問題了。或者退而求其次，你或者可以先進大廠做高階開發，這個職位也能積累架構師的經驗，這總比在小公司前途要光明。

9 總結：不為炫耀學，學的時候更得注意優先順序和方法

我們看書，不是為了向朋友炫耀自己瞭解多少，而是要提升自己解決實際問題的能力，看底層程式碼同樣也如此。

在明確目標的前提下，我們也要明確學習的優先順序和方法，比如一些對現階段幫助不大的技能，可以延後學，而對升級到架構師有幫助的技能得結合實際問題學。

總之目標得明確，所謂在正確的階段做正確的事。如果要走技術發展路線，要升級到架構師，所有的學習都得是為這個目標。如果當前的技能無法滿足大廠的面試需求，應方向正確，優先結合專案實踐看分散式元件技能，而不是繼續挖掘單機版這類對架構師幫助不大的技能，而且總是先深入技能，再看能幫助提升知識面的各種著作。

本人在之前也寫過不少關於升級到架構師技巧的文章，比如以網際網路公司的經驗告訴大家，架構師究竟比高階開發厲害在哪？而在這篇文章裡，是針對了一些升級方法上的誤區，先講述哪些技能無需過度學，再講述哪些技能得優先結合專案學，自認為能在前文的基礎上，進一步幫助大家在升級到架構師的路上少走彎路，希望大家能喜歡。

最後感謝大家能讀完本文，祝大家新春愉快，身體健康，萬事如意。

版權說明：

如果要轉載本文，請先徵得本人同意。