本文說的是技術架構，而不是業務架構，另外，這個架構是指目前比較熱門的高并發大數據的架構。論能力，我還達不到架構師的水平，所以我目前還在不斷努力。 本文回顧了我在架構師方面的學習途徑和學習方式，也總結下我在這方面踩過的坑，從而讓大家別再重犯。

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

我自認為還算比較上進，所以，在java高級開發的崗位上也是不斷學習，當時再往上升，有項目經理和架構師等選擇，一方面，我聽說架構師很掙錢，另一方面，我也想再深入了解些技術，所以就想往這方面轉。當時我是很迷茫的，甚至不知道該學什么，以及該怎么學。

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

面試官的問題1：你用過什么架構？他的本意可能是問分布式架構，比如Dubbo等。我只能回答出，我用過Spring?MVC，其它就不知道。面試官的問題2：在項目里，怎么應對高并發流量？我的回答是，靠多線程，以及Servlet3.0的并發功能。面試官的問題3：你們在數據庫層面，如果應對海量的操作？我的回答是，用SQL調優技術，根據執行計劃，看Oracle執行的瓶頸。這個問題可能面試官想了解集群等方面的知識，但我只能從單機版的方面回答。

總之，當時的回答很多是答非所問，幸好當時的面試是用來試錯。

回想起當時的場景，雖然到處到網上搜諸如“java架構師的技能“等關鍵字，也看了不少資料，面試回來也趕緊補課，但總體上，甚至無法建立起學習規劃，所以當時的學習效率并不高。

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

因為當時在高級開發階段，自己動手搭建過spring?mvc等的實現方式，很多問題都是自己寫模塊來解決的，所以就認為很多架構級別的事情，更多的得靠自己寫代碼來解決，而架構師應當更多關注系統的結構。

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

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

這就好比一個畫家在成名后，能自己創作出各種藝術精品，但在學習階段，更多是通過臨摹大師的作品來體會大師們的創作思路。所以，在學習階段，架構師不能指望一步登天，總是先通過了解現有組件的代碼和實現方式，來慢慢積累經驗。

3 陷入各組件的細節中

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

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

當我了解到一個個組件的實現細節后，也發現自己確實也長了不少知識，但對實際工作的幫助并不大。

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

否則的話，光了解零件的構造，不了解機器的工作機制和流程，還是無法成為架構師。

4 學了一大堆組件，也了解了很多方向，但要把組件組裝到一起，不容易

在陷入學習細節的學習誤區后，我發現無法有效地把了解到的組件整合到一起，比如怎么把反向代理nginx和消息中間件整合到一起，這樣就無法讓多個組件起到1加1大于2的作用了。

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

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

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

經過不斷徘徊和摸索，現在發現，架構師的能力其實是體現在日常工作中的，在一個項目里，并不是架構師搭建好系統架構體系后就什么都不干了，架構師在項目開發過程中，更能幫助組員搭建出可用性高和可維護性強的應用系統，后者其實更能體現出架構師的能力。

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

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

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

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

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

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

設計模式

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

上述是我的一些體會和總結，大家可以留言，談談自己在升級架構師的一些體會。

最后，給大家推薦一個**Java進階內推交流群730379855**，不管你在地球哪個方位，不管你參加工作幾年都歡迎你的入駐！（群內會免費提供一些群主收藏的免費學習書籍資料以及整理好的幾百道面試題和答案文檔！）