學習自己不難，可貴是瞭解該學哪些——總結下我在架構師升級過程當中的那些坑以及各類體會

    先說明，本文說的是技術架構，而不是業務架構，另外，這個架構是指目前比較熱門的高併發大數據的架構。論能力，我還達不到架構師的水平，因此我目前還在不斷努力。 

    以前我寫過一篇博文，架構師更多的是和人打交道，說說我見到和據說到的架構師升級步驟和平時的工做內容，反響不錯，因此今天我再回顧下我在架構師方面的學習途徑和學習方式，也總結下我在這方面踩過的坑，從而讓你們別再重犯。 

1  剛開始，只知道架構師很掙錢，但不知道該學什麼

    我自認爲還算比較上進，因此，在java高級開發的崗位上也是不斷學習，根據學習結果整理了一本書，java web輕量級開發面試教程，當時感受在這個級別裏也不算差了，就萌生了升級的想法。

 

    當時再往上升，有項目經理和架構師等選擇，一方面，我據說架構師很掙錢，另外一方面，我也想再深刻了解些技術，因此就想往這方面轉。當時我是很迷茫的，甚至不知道該學什麼，以及該怎麼學。

     

    那個時候，我就開始用面試來探路了，投了很多公司的架構師職位，記得當年面試真的是答非所問。

     面試官的問題1：你用過什麼架構？他的本意多是問分佈式架構，好比Dubbo等。

     我只能回答出，我用過Spring MVC，其它就不知道。

     面試官的問題2：在項目裏，怎麼應對高併發流量？

     個人回答是，靠多線程，以及Servlet3.0的併發功能。

     面試官的問題3：大家在數據庫層面，若是應對海量的操做？

     個人回答是，用SQL調優技術，根據執行計劃，看Oracle執行的瓶頸。

     這個問題可能面試官想了解集羣等方面的知識，但我只能從單機版的方面回答。

 

     總之，當時的回答不少是答非所問，幸虧當時的面試是用來試錯。

    回想起當時的場景，雖然處處到網上搜諸如「java架構師的技能「等關鍵字，也看了很多資料，面試回來也趕忙補課，但整體上，甚至沒法創建起學習規劃，因此當時的學習效率並不高。 

2  過於偏重代碼層面的解決方案，其實也得靠組件

    由於當時在高級開發階段，本身動手搭建過spring mvc等的實現方式，不少問題都是本身寫模塊來解決的，因此就認爲不少架構級別的事情，更多的得靠本身寫代碼來解決，而架構師應當更多關注系統的結構。     

    好比，當時我在學習負載均衡，總想着本身寫一個模塊，經過NIO或隊列的形式，本身把請求轉發到合適的服務器上，又如，在安全容錯方面，總想着本身寫一個異常處理的模塊，來解決超時的請求。

    這種作法自己沒錯，由於資深級別的架構師確實是本身經過代碼寫諸如負載均衡等的實現方案，但在剛開始的升級階段，更多的得靠現有的組件來解決實際問題。

     這就比如一個畫家在成名後，能本身創做出各類藝術精品，但在學習階段，更可能是經過臨摹大師的做品來體會大師們的創做思路。因此，在學習階段，架構師不能期望一步登天，老是先經過了解現有組件的代碼和實現方式，來慢慢積累經驗。

 

3  陷入各組件的細節中

    在通過一些大神的幫助後，我也知道了一些架構級別的組件，好比消息級別的組件Kafka，以及zookeeper等，這時，當我看到這些組件神奇的功效後，就忍不住去看底層實現，當我沉浸於底層實現的精妙時，就不知不覺地陷入到它們的細節中。

    這時，我確實能向別人吹噓某種組件的底層實現細節，讓別人也感受我很厲害，但僅此而起。

    當我瞭解到一個個組件的實現細節後，也發現本身確實也長了很多知識，但對實際工做的幫助並不大。

    如今回想下，當時應當是先了解面上的知識點，好比我要搭建一個分佈式高併發的系統，我應當瞭解這個系統應當包括哪些功能模塊（好比反向代理，數據庫集羣，消息中間件等），在這基礎上，而後在每一個方面再選用合適的組件。

    不然的話，光了解零件的構造，不瞭解機器的工做機制和流程，仍是沒法成爲架構師。

4  學了一大堆組件，也瞭解了不少方向，但要把組件組裝到一塊兒，不容易

     在陷入學習細節的學習誤區後，我發現沒法有效地把了解到的組件整合到一塊兒，好比怎麼把反向代理nginx和消息中間件整合到一塊兒，這樣就沒法讓多個組件起到1加1大於2的做用了。

    這時，我就結合了具體的業務功能，看了很多代碼，或者是別人的解決方案，終於知道各組件之間是怎麼整合的。    

    

    並且，在此基礎上，也開始本身動手組裝一些組件。在剛開始的階段，本身搭建的這些系統只能是實現功能，效果和外觀上只能是呵呵了。但我感受很欣慰，至少能動手實踐了，能經過對比本身和大神之間的成果來了解進步方向了。     

5  後來發現架構師更得考慮可重用和可維護性 

     通過不斷徘徊和摸索，如今發現，架構師的能力實際上是體如今平常工做中的，在一個項目裏，並非架構師搭建好系統架構體系後就什麼都不幹了，架構師在項目開發過程當中，更能幫助組員搭建出可用性高和可維護性強的應用系統，後者其實更能體現出架構師的能力。

    好比某個收銀系統得支持預付卡，銀行卡，微信，支付寶還有積分等的支付方式，並且支付的渠道還得分銀聯和網聯以及門店等，如何搭建一個能支持上述渠道和上述支付方式的系統？

    可能通常的程序員就會就事論事，用最簡單最快速的方式，針對每種方式建一個類，作多在方法級別抽象出來，估計這樣只能實現方法級別的重用。

    但發現這樣遠遠不夠，由於沒有一成不變的代碼，上述代碼在通過屢次需求變動以及屢次功能改動後，就會變得一團糟，基本上就很難維護了。甚至會發現修改代碼的時間會比寫新代碼的時間要長不少。

    架構師在處理這類問題時，不會光想着當前如何實現功能，更會主動地考慮，當功能變動時，如何更高效地修改？若是當有相似功能來時，如何最大限度地利用現有的模塊？

    其實答案咱們都知道，即面向對象思想以及基於設計模式的解決方案。這裏個人體會是，當咱們陷入修改泥潭時，或者不得不作重複勞動時，這時再回顧面向對象和設計模式，再嘗試着用其中的一些方法（無非是繼承，抽象類，接口，內聚，組合等方式）改善代碼結構時，從中咱們能獲得意想不到的收穫，個人一些對設計的感悟就這樣來的。

     咱們不可能天天都會面對架構層面的設計，但寫代碼是天天必不可少的工做，咱們若是天天能及時回想下，我今天寫的代碼，若是遇到功能改動時，會不會修改起來很困難？若是可維護性差，那麼該怎麼改進？而後再進一步考慮下，我面臨的問題場景可否和設計模式中的一種或多種匹配上？若是能的話，該怎麼用設計模式的思路來改進？

 

    多想下這類問題，咱們就會有收穫，雖然我目前還談不上是架構師，但至少我就經過這種方式提高了很多能力。 

6  我目前的狀況和學習方向（請大神們指導） 

    上述是個人一些體會和總結，另外，我目前也在看些架構方面的書，好比架構探險：從零開始寫分佈式服務框架，以及Spring Cloud方面的書，更重要的是，我平時也在不斷練習。

    目前，我將進一步學習Spring Cloud，以及更多地學習並實踐高併發場景下的架構體系。

    這裏，我也想借這個機會，請你們給出具體的指導。

    好比你們能夠經過留言，說下本身在升級架構師的一些體會，或者能夠推薦些好的書籍，這樣也能幫助我少走些彎路。 

8  版權聲明和求推薦

    本文能夠在不作二次加工的前提下被轉載，但謝絕用於商業用途，轉載時請註明原出處。

    寫博文不容易，何況，我自認爲此文都是個人體會，先後也用了3個小時來寫本文，因此若是你們感受能夠，請多幫忙推薦下，你們的推薦是我不斷寫博文乃至不斷進步的動力。

    最後，你們也能夠列下想聽哪一個話題的分享？若是能夠，我會盡可能知足你們。