從熟練工的狀態下提升到架構師的基本功和技巧架構師更多的是和人打交道，說說我見到和聽說到的架構師升級步驟和平時的工作內容看下資深架構師平時需要解決的問題，對比你離資深架構師還有多少距離——再論技術架構的
- 2019 年 10 月 8 日
- 筆記
本人自認為已經是高級開發，自認為還算勤懇，用了不少時間看了架構師方面的資料，也有機會從事了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 在轉載時，請原文轉載 ，如要在轉載修改本文，請事先告知，謝絕在轉載時通過修改本文達到有利於轉載者的目的。
