本人自認為已經是高級開發，自認為還算勤懇，用了不少時間看了架構師方面的資料，也有機會從事了1年左右架構相關的活。本人尚有自知之明，還談不到技術架構的水准，但在本人目前工作環境里，能得到牛人親歷指導，本人也不斷通過拜師學藝，自認為走在正確升級的途徑上，即只要繼續努力，在不久的將來能拿到架構師的工資。
回想我當年處於高級開發階段，也算是個熟練工，每天干的都是體力活，說白了就是不斷復制熟悉的工作模式。由於在工作中沒法實踐到高並發組件等架構師所必需的知識點，當時只也只能靠看資料來積累，靠面試來感受對公司架構師的實際要求，自己感覺也走了不少彎路。
為了更好地繼續后面的升級之路，我寫下這篇階段性總結文章，也一方面通過總結，讓我更加明確后繼的計划和目標，另一方面，也希望能盡個人的微薄之力讓各位同路人少走彎路。這篇文章也算是我之前兩篇博文架構師更多的是和人打交道，說說我見到和聽說到的架構師升級步驟和平時的工作內容，以及看下資深架構師平時需要解決的問題，對比你離資深架構師還有多少距離——再論技術架構的升級之路的后繼系列文。
1 熟練工有退步的風險，所以首先主觀上得不斷上進
每個公司做的活其實都有局限性，如果就停留在本公司熟練工的階段，那么一定無法緊跟技術進步的步伐，長而久之就會落后了。
話說回來，不是每個熟練工都能經得起舒適區誘惑的，我就拿我經歷過的舒適區和目前的挑戰區狀況對比一下。
上班前，在外企的時候，由於每天干的活都能應付，所以沒絲毫壓力，而且由於是彈性工作制，所以10點到算常態，一周總有1次10點半前到，上班路上，還能用悠閑的心情看風景。在目前互聯網公司，上班前就得規划一天的工作，有時候想想今天要干的活技術上我不大熟，或者得催別的組要接口，所以經常有忐忑不安的感覺，一路上有時還得小跑，雖然也是彈性工作制，但總是9點前到，早到就能早開始做事情。
上班時，在外企的時候，對進度的壓力不大，而且干的活都會，所以可以優哉地干，平時有空可以逛個網站，而且出去逛一圈是常事，加班到8點就會埋怨，到了周五下午，大多數人都沒心思干活了，基本都是坐等下班。而在互聯網公司，每天都有干不完的活，干好活，就得不斷反思，看如何才能干更好，否則就壓力很大。晚上加班到9點是常事，而且最頭痛的是，不少事情不是能用時間都能解決，比如出個技術方案，里面涉及到的技術不熟，就得拼命學。
周末以及下班后，在外企的時候，由於無需積累，所以很輕松，也能享受生活，像我當時寫書寫博客，還出了兩本書，Java Web輕量級開發面試教程和Java核心技術及面試指南，還算比較勤奮的，而在互聯網公司，對不起了，平時一定得看資料，而且絕對不能裝模作樣地看，如果一個階段里不進步，那么就坐等被說。
由奢入儉難，而且舒適區用的技術要比挑戰區落后很多，而高級開發到架構師的升級任務未必是容易達成的，所以在舒適區的時候，只能平時多上進，要怎么上進？其實拿出當年高考四分之一的努力程度即可。
2 從會用分布式組件開始，而且不能光看資料
架構師的重要工作任務是解決分布式高並發的問題，所以升級可以從會用一些分布式框架開始。
比如nginx怎么配置，dubbo和zookeeper怎么整合，kafka消息中間件怎么配置，redis怎么配置，或者ETL該怎么配置。看了各種教程后，一定得自己找個環境配置一下，比如我通過nginx配置，確實能把請求發送到不同的服務器上，或者通過設置dubbo配置，確實能做到超時重發。
這個步驟的難點是，在自己的機器上未必能模擬出分布式環境，所以如果可以，就找公司測試環境實踐，或者自己機器上裝個虛擬機。如果實在沒有辦法，安裝個環境，然后自己設置一遍配置，哪怕沒法調試，自己設置一遍總比光看教程要好。
3 思考兩個問題，從中能歸納出升級所必須的基本功
不少高級開發摸不到升級架構師的方法，其實很多技巧平時工作時就能接觸到。可能這里一時無法列全升級到架構師所需要的基本功，但大家可以思考如下兩方面的問題。
1 當前系統的運維方面，為了讓你的系統能平穩地運行平穩地升級版本，你需要掌握哪些技能？當系統在線上表現出有問題時，你該如何通過查日志等方面來排查問題點？
2 再進一步，可以考慮系統高並發方面的問題。你的系統當前能應付多少並發量？當前系統的瓶頸在哪？任何系統都有瓶頸，比如SQL壓力大，非常容易導致OOM異常。如何通過看日志等方式確認當前系統的瓶頸所在？
為了得到上述兩個問題的答案，我們需要掌握各類技能，比如通過jenkins打包發布版本，通過linux日志查看問題，通過MAT查看OOM異常時的Dump文件，諸如此類，這就是升級到架構師所必須的基本功。
所以當我們在一個公司成為熟練工，達到“舒適區”以后，一定不能局限於自己所被分配的活。如果再達到高級開發的水平后，一定有機會接觸架構配置調優等方面的活，這時候，有條件的最好能親身參與，如果沒條件，哪怕看配置看流程看代碼也行。
4 架構師得從底層代碼角度，進一步查看實現細節
java語法誰都會，但從初級開發，高級開發和架構師等不同的視角，關注的點一定不同。
初級開發會專注於“如何調用”和“如何才能保證沒有語法和邏輯上的問題”，高級開發會根據當前需求選擇一些合適的語法點，比如遇到高並發會選擇“線程池”，遇到NIO類需求時則選用netty，而架構師則需要在使用各種組件時，進一步了解各種坑。
比如在使用netty時，則需要了解如何解決半包粘包問題，在使用堆外內存時如何保證能正確回收內存。這就要求高級開發在升級到架構師的路上，更得關注必要的底層代碼，比如netty里LengthFieldBasedFrameDecoder解決半包的實現代碼，以及DirectBuffer部分的相關代碼。
推而廣之，除了netty之外，高級開發在“會用分布式組件”的基礎上，更得從高可用（一台down了能自動切換）高並發（這不用說了）集群上下功夫，這只能一個個組件自己看了，網上這類資料不少，比如我前幾天看到篇阿里架構師面試指南，里面針對各組件提了不少問題，大家可以逐一對比，根據問題查看底層實現細節。
對高級開發而言，組件可能就是一個個jar包，但對架構師而言絕不是這樣，比如某個基於netty的系統一直出現OOM異常，那么架構師首先得熟悉netty jar包里的底層代碼，而且必要時，得debug進這些底層代碼，或者通過dump文件發現現有系統在使用堆外內存時未釋放內存的點。
看底層代碼，說起來容易做起來很難，要看到什么程度？如何才能不拘泥於細節？我目前的體會是，第一看流程，從流程里看這個組件的關鍵模塊和重要方法，第二還是結合阿里架構師面試題里的問題，比如提到dubbo底層通訊協議，那么就把對應的模塊和對應的方法看一下。
5 架構師的思維：更得讓架構切合業務，還得控制風險
記得我在入門架構師的開始階段，總是很理想話，總是會畫出一個解決高並發的框圖，里面包含了各種組件，這不算錯，但只是第一步。
在大多數場景里，架構師不是從零起點設計，而是需要結合現有系統的各種痛點改造系統。舉個例子，當前數據庫性能很慢，如果有錢的話，比較直接的辦法是升級到oracle，但往往不現實，所以架構師可以搭建多個mysql實例，然后用mycat做分庫分表。而且，從單庫切換成分庫分表時，得考慮到，萬一切換失敗，我該如何回退，由此可以設計出開關和匯總表等方案。
那么高級開發如何在這方面提升自己的能力呢？只能跟在架構師后面，仔細分析具體的設計方案。俗話說，熟讀唐詩三百首,不會作詩也會吟，而各公司多少會有些線上的組件，大家可以通過看配置文件以及架構的工作流程，而且，在上線一個新架構方案時，可以多了解下避規風險和回退的方案。
6 實踐才能提升，那如何沒實踐機會怎么提升？
今年我在加入到一個互聯網公司后，由於有機會接觸到各種架構，所以感覺有所提升。相比之下，我之前在一家外企，在架構方面更多的是“看視頻看組件”，然后在組內分享架構的內部代碼（總之就是實踐的機會很少），所以在那段時間里，我自己感覺進度速度不快。
要應聘架構師的職位，首先要有相關實踐經驗， 但對一些沒機會實踐的朋友來說，該怎么辦？之前我的做法是，看資料，然后冒充自己是架構師去面試，但這很難，因為有經驗的架構師級別的面試官，一看就能看出是真實做過還是理論經驗。下面就說些真實有效的做法。
1 可以在現有公司，多申請干些系統上線系統維護方面的工作，在外企，這類職位叫Support，在國內公司叫“系統運維”，具體的工作是負責把系統部署到產線上，以及在產線上搭建各種諸如oracle,mysql, nginx,mq等組件，這些崗位在各公司都有，如果有機會，最好是能在這類崗位上干一段時間，如果沒機會，就可以跟相關人員混熟，然后看些配置，了解些架構搭建的方式。
2 遇到架構方面的方案評審，盡可能多參加。組內如果有架構方面的活，盡量多做些，剛開始一定是不會，不會的時候千萬別怕丟臉，多跟着熟悉架構的同事后面多問，多看看人家是怎么排查和調試架構方面的活，一來二去就熟悉了。
我也見到過一些同學，所在的公司用的技術比較傳統，在整個公司里都沒有機會用到分布式組件架構，那么沒辦法了，要么自己看資料自己練習（這其實效果並不好），要么自己找個機會跳到互聯網公司。
7 總結，求推薦
說到底，升級的訣竅只能是多觀察多揣摩多實踐，而升級路上的艱辛，真的是如人飲水，冷暖自知。
本人尚屬勤奮，所以雖然天賦一般，在升級的路上也是一波三折步步艱辛，但在堅持之下，自認為也算有些進步，所以尚敢寫些心得供大家參考。
如果大家感覺本文有所幫助，請幫忙推薦此文，如果感覺文章內尚有不足，也請通過評論多多幫助本人，本人不勝感激。
關於轉載有如下的說明。
1 本文可轉載，無需告知，轉載時請用鏈接的方式，給出原文出處，別簡單地通過文本方式給出，同時寫明原作者是hsm_computer。
2 在轉載時，請原文轉載 ，如要在轉載修改本文，請事先告知，謝絕在轉載時通過修改本文達到有利於轉載者的目的。