對我們程式設計師來說，發展的途徑要麼是走管理崗，從開發升級到項目經理甚至是部門經理；要麼走技術升級路線。不過在技術路線方面，無法升級到架構師的程式設計師不在少數。一方面，在不少公司的高級開發崗位上，無法讓程式設計師實踐甚至接觸到架構師的技能，另一方面，有不少程式設計師甚至不清楚架構師所需要掌握的技能和升級途徑。所以從結果上來看，至少有5成的程式設計師止步於「高級開發」的程度，這是非常令人可惜的。
我這幾年一直努力地從高級開發升級到架構師，目前雖然職位上沒達到，但好歹多少也能幹些架構師方面的活了。在本文裡，將結合我自身和其它一些程式設計師的經歷，分析不少程式設計師無法升級到架構師的普遍原因，由此向大家展示從高級開發升級到架構師的難點，並在此基礎上給出相關的升級建議。
1 很多程式設計師在日常工作裡無法接觸到架構師的技能
大多數的程式設計師能在工作中接觸到高級開發的技術，所以從初級開發升級到高級開發，難度並不大，但架構師就不同了。
比如在外包公司裡，程式設計師大多是做重複勞動，業務變了，但用到的技術還是增刪改查。或者在一些規模比較小的公司，項目組出於成本和質量監控的考慮，也未必會讓程式設計師從事架構方面的工作。哪怕在一些技術含量比較高的網際網路公司，出於業務封裝的角度，一些高並發高可用的實現往往被封裝在方法裡，程式設計師僅僅是通過調用方法實現功能，未必能在代碼層面，顯式地看到架構方面的技能。
接觸不到相關技能，單靠看視頻看資料積累起來的技能，在面試過程中往往會不堪一擊，從而無法應聘架構師的崗位，這反過來制約了程式設計師向架構師發展的腳步。
我有時候在面試高級開發的時候，會深入問些架構方面的問題，比如我問，你們系統裡，模塊間的通訊用的是什麼組件 ，不少高級開發甚至是一頭霧水，或者在他們眼裡，更多的是調用方法實現功能。
2 不少程式設計師往往會深挖單機版的技能
很多工作中得過且過的程式設計師，在實現的功能通過測試以後，或許就無所事事了，而且這類程式設計師不在少數，在小公司或外包公司裡，這類程式設計師往往會更多，說實現的，他們的競爭力和從培訓班裡出來的程式設計師沒什麼兩樣，或許就更熟悉業務背景。
或者有些程式設計師雖然上進，但會深挖單機版的技術細節，比如我問String對象的== 和equals方法有什麼差別，或者，JVM虛擬機調優有哪些實踐要點，此類回答他們會回答非常到位。這固然要比純粹會寫代碼的程式設計師要好，但此類技能頂了天只能算高級開發的技能。如果在升級時過度追求這方面的技能，無異於緣木求魚。
3 列舉架構師平時要幹的活，確實和高級開發有差距
上文是從客觀和主觀兩個方面，講述了架構師升級的難處，在講述升級方法前，我們先來看下架構師究竟要幹什麼活，以此來明確努力的方向。
1 需要搭建高可用的框架，比如就拿最簡單的搭建資料庫服務來說，得考慮如果一臺MySQL伺服器宕了，如何保證業務切換到另外一臺機器上。
2 需要考慮高並發的因素，從這個點展開，架構師至少需要會用nginx，mycat，netty，redis之類的工具，以及考慮搭建實現負載均衡的集群。
3 需要把設計好的架構部署上線，或者哪怕上線動作是由運維來做，但架構師至少要知道如何把nginx集群等組件部署上線的活，由此架構師需要了解必須的linux命令和腳本，以及了解jenkins之類的部署工具。
4 上述技能不是簡單會用即可，如果在開發部署和運行過程中由問題，架構師得負責解決。這就要求架構師不能僅僅靠看視頻知道如何搭建系統，更得具備針對netty等組件的debug能力，還得能通過看日誌，知道集群的運作情況，如果集群出了問題，還得知道如何快速解決。
5 不能僅僅關注技術，更得結合業務，把諸如搶紅包之類的需求通過架構實現，這就要求架構師得知道各種組件的優劣，以此能選型並設計方案。
從上述對架構師的需求來看，從高級開發升級到架構師很難，也在情理中了。
4 從運維入手，熟悉架構師的入門技能
升級到架構師很難，但絕非不可能，對於高級開發而言，從運維入手，或許能熟悉架構師的技能。
1 比如先從ant腳本，jenkins腳本和linux shell腳本入手，能知道系統的部署方式，以及熟悉必備的linux調試技能。
2 通過觀察nginx或dubbo或zookeeper配置文件，了解各組件的運作方式，並能通過這些了解高並發高可用系統裡負載均衡和失效轉移等配置方式。
3 可以觀察線上相關的日誌，了解系統部署的情況，以及從架構層面了解諸多組件間的關聯。
在上述步驟裡提到的腳本和日誌，在平時工作中只要上點心，應該可以看到，或者我們可以和運維人員多交流請教，上述組件部署和配置的知識也不難知道。在這個過程中，暫時沒涉及「修改配置」和「搭建組件」等技能，畢竟這屬於熟悉階段。
5 多解決實際問題，了解組件的關鍵配置，並了解組件的底層代碼
程式設計師在熟悉基本的部署和架構方面的技能以後， 就可以參與解決一些實際的問題了。在公司裡，測試和上線階段出現的問題不能算少，其中也會包含很多和架構相關的問題，比如kafka沒配好，導致消息積壓，或者dubbo超時時間配置過長，導致調用鏈路超時失效，或者再如redis超時時間過長，導致OOM異常。類似問題的種類五花八門，只有想不到的，沒有不可能出現的。
剛開始，程式設計師可以跟在資深人員之後查問題，或者找到問題後，再手動復盤一下，學習架構師分析和解決問題的入手點，一來二去，一定能熟悉組件的配置，並了解組件的底層代碼，更能熟悉配置各種框架組件的實施方案。
這個階段依然屬於「見習」，但至少能從實踐角度，掌握架構師所需的技能。對比自己通過看視頻，以閉門造車的方式積累架構師的技能，通過上述步驟得到的相關經驗來源於實際，無疑值錢得多。
6 必要時，得通過跳槽，爭取架構師的實踐機會
其實在小公司甚至是外包公司裡，都有機會了解甚至實踐上文提到的架構師相關技能。程式設計師通過上述步驟掌握架構師的相關技能後，如果再加以實踐機會，就能很快成為名副其實的架構師。
這種實踐機會在大公司裡不難找，但在小公司裡或許就不多了，不過也不要緊，這時如果再出去面試架構師的崗位，基本上就沒什麼難度了。我們來看下架構師的面試問題。
1 如何部署nginx（或其它組件），從而實現高可用？
2 Redis集群裡，容災一般是怎麼做的？
3 Kafka消息隊列裡，如何實現消息重複？如何確保消息不被重複消費？
4 或者是問底層的問題，比如說下netty裡的讀寫索引工作方式。
或者在目前階段，大家未必能回答好上述問題，但一旦在運維層面了解過組件的搭建方式，或者通過排查實際問題了解過組件的運作和交互方式，再專研下相關底層代碼，哪怕沒太多的架構師實踐經驗，此類問題也不難回答。
或許一個沒太多實踐經驗的架構師，在公司裡日子會很難過，可以會讓領導和組員感覺實踐經驗不足，但大多數架構師也都是通過實踐一點點積累相關經驗的，在這個階段裡，如果再肯多聽多看多問題，升級到資深架構，就指日可待了。
7 總結，升級到架構師後，會有更多的機會
其實對於我們做IT的人來說，升級到架構師未必是唯一的發展途徑，但不是每個人都適合搞管理。如果走的是技術加成路線的話，從架構師到技術專家，或許是一條比較合適的發展途徑。
對於高級開發而言，或許真有30歲或35歲現象，畢竟高級開發所需的技能很容易被畢業生或培訓生掌握，年紀一大了就沒競爭優勢了，但正是因為升級到架構師不是那麼容易，到35歲時，或許還有競爭的能力。
而且，一旦升級到架構師，退則可以找個小公司做技術負責人，以求小富即安，從而不會像高齡碼農那樣被淘汰；進則可以再到大廠裡去磨練一番，然後再通過各種途徑拓展影響力，那麼真就可以說成為技術大牛了。反之，如果止步於高級開發，雖然也能通過跳槽提升工資，但格局始終無法像架構師那樣開闊了。