總結我在架構師升級過程中的那些坑以及各種體會
先說明，本文說的是技術架構，而不是業務架構，另外，這個架構是指目前比較熱門的高併發大資料的架構。論能力，我還達不到架構師的水平，所以我目前還在不斷努力。 本文回顧了我在架構師方面的學習途徑和學習方式，也總結下我在這方面踩過的坑，從而讓大家別再重犯。
一、剛開始，只知道架構師很掙錢，但不知道該學什麼
我自認為還算比較上進，所以，在java高階開發的崗位上也是不斷學習，當時再往上升，有專案經理和架構師等選擇，一方面，我聽說架構師很掙錢，另一方面，我也想再深入瞭解些技術，所以就想往這方面轉。當時我是很迷茫的，甚至不知道該學什麼，以及該怎麼學。
那個時候，我就開始用面試來探路了，投了不少公司的架構師職位，記得當年面試真的是答非所問。
面試官的問題1：你用過什麼架構？他的本意可能是問分散式架構，比如Dubbo等。
我只能回答出，我用過Spring MVC，其它就不知道。
面試官的問題2：在專案裡，怎麼應對高併發流量？
我的回答是，靠多執行緒，以及Servlet3.0的併發功能。
面試官的問題3：你們在資料庫層面，如果應對海量的操作？
我的回答是，用SQL調優技術，根據執行計劃，看Oracle執行的瓶頸。
這個問題可能面試官想了解叢集等方面的知識，但我只能從單機版的方面回答。
總之，當時的回答很多是答非所問，幸好當時的面試是用來試錯。
回想起當時的場景，雖然到處到網上搜諸如“java架構師的技能“等關鍵字，也看了不少資料，面試回來也趕緊補課，但總體上，甚至無法建立起學習規劃，所以當時的學習效率並不高。
二、過於偏重程式碼層面的解決方案，其實也得靠元件
因為當時在高階開發階段，自己動手搭建過spring mvc等的實現方式，很多問題都是自己寫模組來解決的，所以就認為很多架構級別的事情，更多的得靠自己寫程式碼來解決，而架構師應當更多關注系統的結構。
比如，當時我在學習負載均衡，總想著自己寫一個模組，通過NIO或佇列的形式，自己把請求轉發到合適的伺服器上，又如，在安全容錯方面，總想著自己寫一個異常處理的模組，來解決超時的請求。
這種做法本身沒錯，因為資深級別的架構師確實是自己通過程式碼寫諸如負載均衡等的實現方案，但在剛開始的升級階段，更多的得靠現有的元件來解決實際問題。
這就好比一個畫家在成名後，能自己創作出各種藝術精品，但在學習階段，更多是通過臨摹大師的作品來體會大師們的創作思路。所以，在學習階段，架構師不能指望一步登天，總是先通過了解現有元件的程式碼和實現方式，來慢慢積累經驗。
三、陷入各元件的細節中
在經過一些大神的幫助後，我也知道了一些架構級別的元件，比如訊息級別的元件Kafka，以及zookeeper等，這時，當我看到這些元件神奇的功效後，就忍不住去看底層實現，當我沉浸於底層實現的精妙時，就不知不覺地陷入到它們的細節中。
這時，我確實能向別人吹噓某種元件的底層實現細節，讓別人也感覺我很厲害，但僅此而起。
當我瞭解到一個個元件的實現細節後，也發現自己確實也長了不少知識，但對實際工作的幫助並不大。
現在回想下，當時應當是先了解面上的知識點，比如我要搭建一個分散式高併發的系統，我應當瞭解這個系統應當包括哪些功能模組（比如反向代理，資料庫叢集，訊息中介軟體等），在這基礎上，然後在每個方面再選用合適的元件。
否則的話，光了解零件的構造，不瞭解機器的工作機制和流程，還是無法成為架構師。
四、學了一大堆元件，也瞭解了很多方向，但要把元件組裝到一起，不容易
在陷入學習細節的學習誤區後，我發現無法有效地把了解到的元件整合到一起，比如怎麼把反向代理nginx和訊息中介軟體整合到一起，這樣就無法讓多個元件起到1加1大於2的作用了。
這時，我就結合了具體的業務功能，看了不少程式碼，或者是別人的解決方案，終於知道各元件之間是怎麼整合的。
而且，在此基礎上，也開始自己動手組裝一些元件。在剛開始的階段，自己搭建的這些系統只能是實現功能，效果和外觀上只能是呵呵了。但我感覺很欣慰，至少能動手實踐了，能通過對比自己和大神之間的成果來了解進步方向了。
五、後來發現架構師更得考慮可重用和可維護性
經過不斷徘徊和摸索，現在發現，架構師的能力其實是體現在日常工作中的，在一個專案裡，並不是架構師搭建好系統架構體系後就什麼都不幹了，架構師在專案開發過程中，更能幫助組員搭建出可用性高和可維護性強的應用系統，後者其實更能體現出架構師的能力。
比如某個收銀系統得支援預付卡，銀行卡，微信，支付寶還有積分等的支付方式，而且支付的渠道還得分銀聯和網聯以及門店等，如何搭建一個能支援上述渠道和上述支付方式的系統？
可能一般的程式設計師就會就事論事，用最簡單最快速的方式，針對每種方式建一個類，做多在方法級別抽象出來，估計這樣只能實現方法級別的重用。
但發現這樣遠遠不夠，因為沒有一成不變的程式碼，上述程式碼在經過多次需求變更以及多次功能改動後，就會變得一團糟，基本上就很難維護了。甚至會發現修改程式碼的時間會比寫新程式碼的時間要長很多。
架構師在處理這類問題時，不會光想著當前如何實現功能，更會主動地考慮，當功能變更時，如何更高效地修改？如果當有類似功能來時，如何最大限度地利用現有的模組？
其實答案我們都知道，即面向物件思想以及基於設計模式的解決方案。這裡我的體會是，當我們陷入修改泥潭時，或者不得不做重複勞動時，這時再回顧面向物件和設計模式，再嘗試著用其中的一些方法（無非是繼承，抽象類，介面，內聚，組合等方式）改善程式碼結構時，從中我們能得到意想不到的收穫，我的一些對設計的感悟就這樣來的。
我們不可能每天都會面對架構層面的設計，但寫程式碼是每天必不可少的工作，我們如果每天能及時回想下，我今天寫的程式碼，如果遇到功能改動時，會不會修改起來很困難？如果可維護性差，那麼該怎麼改進？然後再進一步考慮下，我面臨的問題場景能否和設計模式中的一種或多種匹配上？如果能的話，該怎麼用設計模式的思路來改進？
多想下這類問題，我們就會有收穫，雖然我目前還談不上是架構師，但至少我就通過這種方式提升了不少能力。
上述是我的一些體會和總結，大家可以留言，談談自己在升級架構師的一些體會。
