[[326164]]

目前我在互聯網公司里干了1年多，接觸了多位技術和業務的架構師，由于我正在升級到架構師，所以能直觀地感受到高級開發和架構的差距，而且，對于高級開發如何升級到架構師，本人目前更有切身體會。

本文將結合我在互聯網公司的工作體驗，和大家分享下架構師和高級開發在工作中的側重點，由此能給大家帶來升級到架構師的啟示。 

差距首先體現在工作態度上

架構師或立志升級到架構師的高級開發，平時工作中一定有如下的特質。

1. 出了問題第一時間去調查分析問題，哪怕這個問題看上去和自己無關，而不是想辦法推脫問題。 

2. 上班的時候，基本沒時間看無關網頁或手機，哪怕手頭沒活，也會看項目框架或看技術，或者思考如何優化。

3. 出了問題，一般會深挖，哪怕當前無法從根源解決問題，但一般會找到根源原因，而不是想辦法繞過去。

這點我深有體會，別說互聯網公司的架構師都這樣，連表現不錯的高級開發也會這樣，因為要在互聯網公司生存下來，這些可能是必備條件。

當然，我也見到過得過且過的，但一般上升空間都比較小，或者無法進一步提升，或者沒能力競爭外面更高工資的崗位。 

技術方面，架構師的基本功與高級開發的技術存貨

一般的開發大多關注“單機版” 的代碼，只要在本機上開發完成任務就行，然后外帶些debug技能，能跟蹤到代碼，能使用數據庫就行。

而高級開發的“高級”體現在兩個地方，第一，對業務更熟悉，但話說回來，換了公司，業務值多少錢呢？第二就是對代碼底層有進一步的了解，比如理解Spring Boot的啟動步驟等。

而架構師的基本功要比高級開發要高些，下面來對比下我見到的架構師和高級開發的各種表現，大家從中能看出兩者的差別。

1. 由于高級開發大多是調試單機版程序，所以看日志的時候，一般是在本地看，或者是用工具把日志下載到Windows本地，然后用文本工具查找關鍵字。

但對架構師而言，這種查日志的效率太低，大多都是用less和grep之類的命令來看，也就是說，架構師必須對linux的操作和很熟悉。

2. 高級開發一般無需考慮打包部署等問題，而架構師在優化分布式組件前，必須要打包項目。

所以架構師需要對項目打包（比如maven命令），項目部署（比如jenkins或uDeploy）還有項目質量管理（比如繼承sonar）有了解，如果項目還需要部署在云平臺上，可能還得了解Docker或k8s之類的工具。

也就是說，除了寫代碼之外，架構師還至少得了解項目的集成部署這塊內容。

3. 架構師更得了解組件集群等內容，比如分布式組件，云平臺集群，反正不是單機版。

可能高級開發也會多少了解些Dubbo，緩存之類的組件知識，但架構師更得掌握這些組件的分布式部署相關內容，即一臺機器失效了，其它熱備的機器該如何頂上。

除了開發代碼，架構師更得關注壓測，方案評估和系統上線等實施要點

架構師多少得具備些產品的相關意識，這些意識必須始終貫穿于工作中，這塊就是和高級開發相比，架構師值錢的技術了。    

1. 對于架構師而言，產品（或相關組件模塊）不是做出來就好了，更得進行壓力測試，壓測結束后，架構師還得雞蛋里挑骨頭，錙銖必較地想優化點。

2. 架構師還得借鑒些當前的同類產品（或者是競爭產品），對性能而言，只有更好沒最好，比如一個模塊當前運行時間是2秒，還得想盡一切辦法壓縮到1秒，這就要求架構師精通各種技術。 

3. 架構師更得評估各種風險，尤其是當新版本上線時，發布時候就好比一個關口，首先得保證新老代碼兼容，不能導致停服，其次得控制風險，預先設計好各種基于代碼或數據庫的回退或處理預案， 一有風吹草動，就得立即回退。

也就是說，架構師首先得保證系統能平穩上線，其次在開發過程中，應當預先考慮到線上的各種風險，并且更得時刻考慮優化的方向，而高級開發并沒有這類要求。

架構師是某一領域的主心骨，高級開發還是處于“干分配的活”階段

架構師不僅只是技術控，更得結合業務，和相關團隊合作，制定出當前可行，且實施風險較小的各類方案。

也就是說，架構師雖然不會像項目經理那樣側重于項目管理，但也需要有帶人的經驗，一方面把自己的設計理念讓組員落實，另一方面，一旦自己分管的系統出了問題，高級開發尚可以退縮，而架構師應當責無旁貸地負責解決。 

這里我列些我見過的架構師平時的一些工作場景。 

1. 架構師手機上有各種群，包括業務和技術相關的，要求是@你的一定得第一時間解決。

如果客戶不是@你，雖然沒@，但報的問題和你有關， 也得第一時間解決，所以大多數架構師養成了手機不關，而且半夜醒來看手機的習慣。

而高級開發還可以等著架構師來分配活。

2. 出任何問題，比如業務上功能有問題，或者系統運行時出了OOM等性能問題，或者通過監控發現關鍵性指標下降，架構師都需要在第一時間介入。

3. 自己組內，或者別的組對自己分管領域內有任何問題，包括業務上的和技術上的，都應當是協調解決。

4. 更多的時候，架構師更得和相關人員（產品，其它組或系統運行維護人員等）開會，評估各種方案的實施方式。

在定方案的時候，每個組都會有私心，想自己組少改些，這時架構師就得協商或妥協出各類方案。

架構師在這方面的工作量甚至超過了寫代碼的工作量，我就經常見到諸多架構師上班時開會，下班或者周末才有自己的時間來寫代碼。

系統發布階段，最能體現出架構師和高級開發的水平

在高級開發的眼里，系統發布僅僅是把最新代碼和腳本部署到生產服務器上，之前我也是這樣認為的。但在這個階段，架構師需要考慮如下方面的問題。

1. 在發布的時間段里，會新老代碼并存，比如灰度發布時，會切一部分流量到新代碼上，這時如何保證兼容性。

2. 發布時的回滾步驟，如果涉及到數據庫回滾，還得準備好各種SQL。

3. 數據清洗和數據遷移的步驟，往往上新功能后，數據清洗的范圍是全局的，架構師還得考慮性能問題。

4. 系統上線后，該對那些關鍵步驟進行監控打點，以及打點后，提示異常的閥值該如何設置？

從中我們能看到，架構師更得掌握系統運維+性能綜合調優+系統監控等能力，這塊對高級開發而言，其實要求是很低的。

我見到的牛人架構師，以及他們的進階方式

在進互聯網公司前，由于我寫了兩本書，也接觸過一些牛人，但進互聯網公司后，發現第一牛人的數量比預期多很多，而且都很年輕，第二牛人在一些領域的精通程度超過我的想象。

就說我的師傅，除了工作態度好責任心強肯幫助人之類的軟實力外，看日志調試代碼到jar包里去debug的硬實力也厲害，更重要的，對一些分布式組件，達到了出暢銷書（至少1萬本）的地步。

而我師傅的師傅，更是業內大牛，不僅在Spring方面出了很多書，而且最近在極客世界里錄制的視頻課，目前銷量就2萬+了，后期估計至少5萬+。

跟著牛人學，我在互聯網公司里能力提升不慢，且架構方面有了一定的進步，以我的切身體會，怎么快速提升呢？

1. 當然得熟悉業務，否則沒法干活，但熟悉以后不能沾沾自喜，更得看技術（尤其是值錢的技術）如何同業務整合。

如何熟悉業務？沒捷徑，第一看文檔，第二看代碼，第三問人，第四還得看自己領域外的但本系統會調用的上下文系統。

2. 出了問題別推，通過看日志等方式排查，再不行，還得深入debug一些組件包去看。

當排查問題的數量和種類積累到一定程度后，自己可能就無師自通了，我見過的一些大牛，基本上有問題就調查，從不推諉。

3. 畢竟個人的眼界有限，接觸到的面也未必多，所以一定多跟牛人打交道。

請牛人幫忙排查問題時，自己一定得在旁邊多看，平時更得和牛人交流，牛人們往往會給出學習的方式和學習的點，而且牛人會幫忙指導各種技術里的坑。

4. 多參與些自己領域外的工作，比如壓測和系統部署，干活的時候不能僅僅停留在技術領域，更得關注項目啟動，組件部署乃至項目部署等方面。

其實不少牛人不僅干過開發，更干過系統集成和系統運行維護的活，這樣對分布式組件等之前的知識，就不僅僅停留在“會開發”的地步。有時候哪怕自己未必被分配到這類活，但也一定要多參與。 

通過什么渠道我們能獲得架構師相關的幫助文檔和實踐機會

1. 目前網上有大量的架構師進階資料，包括分布式組件的，包括云計算等的，甚至有架構師相關的面試技巧的。對此，大家一定得多看帶框圖的，和業務實踐相關的文檔。

2. 一定得理論結合實際，架構師相關的文檔如果光看，比較枯燥，很容易就半途而廢，這點我自己有體會。

怎么結合呢？最好能去互聯網公司鍛煉一段時間，哪怕在其中就干高級開發的活，平時也絕對有機會接觸到架構師的技能。

3. 一定得多和人打交道，小到和自己組員多溝通，中到和自己公司里相關的牛人多溝通請教，再大點范圍，可以和網上的一些大牛多交流。

我體會下來，這些交流絕不會白費，除了能得到技術交流的機會外，還能掌握到一些掙錢的渠道和方法。

總結，升級到架構師，不僅僅得提升技術

確實，提升到架構師離不開技術的提升，但架構師最終是要讓技術解決實際業務問題，所以在提升過程中，我更多關注的是“技術+案例”的資料，比如我會搜索“dubbo案例”之類的，以此深挖技術的落地方式。

而且，架構師還得和人打交道，這比與技術打交道難多了，因為各樣的人都有。

那么升級到架構師以后，會帶來哪些收益呢？

當然是錢多，不僅如此，架構師往往會是在某個領域里是專家，所以在這個領域更能用技術換錢，比如賣視頻教程等。

最重要的是，通過升級到架構師積累起來的一些軟實力，比如責任心，管理時間的方式，高效的工作方法以及思考問題的方式，這才是最值錢的。