作者：hsm_computer
來源：https://www.cnblogs.com/JavaArchitect/p/10708262.html
目前我在網際網路公司里乾了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案例」之類的，以此深挖技術的落地方式。
而且，架構師還得和人打交道，這比與技術打交道難多了，因為各樣的人都有。
那麼升級到架構師以後，會帶來哪些收益呢？
當然是錢多，不僅如此，架構師往往會是在某個領域裡是專家，所以在這個領域更能用技術換錢，比如賣視頻教程等。
最重要的是，通過升級到架構師積累起來的一些軟實力，比如責任心，管理時間的方式，高效的工作方法以及思考問題的方式，這才是最值錢的。