如何成爲一個Java高薪架構師？

從心裏講我真的不想回答架構具體須要作什麼，架構師應該具體負責什麼。由於從實際狀況看，在不一樣的系統層級，不一樣的需求下架構師的職責也會不一樣；從不一樣的技術角度看，架構師又是個變色龍——一時是技術的大拿，一時是技術的規劃者，一時是技術團隊的指揮者。

那麼，該如何回答「什麼是架構，什麼是架構師」這個問題呢？這或許須要先搞清楚另一個問題——一名程序員是如何走上架構師之路的？我從許多朋友那裏瞭解到了不少實際案例，程序員走上架構師之路，總結起來最多的緣由是由於他早前代碼寫的好。

那麼，代碼寫的好就是架構嗎？顯然不是。代碼寫的好只是表象，作全部事情都須要規劃，尤爲是一個複雜的軟件系統，這更須要規劃，不然可能連一行代碼都寫不出。複雜的軟件系統必定會須要作不少抽象設計、對象規劃、接口規劃等準備動做。也就是「上一輩程序員」口中所說的：詳細設計。作架構主要的事情也依舊如此，須要對整個系統進行系統的規劃：模塊、通信、邊界、擴展、技術下沉等工做。這樣的規劃完成以後項目方能正常跑起來。

固然，架構也不只僅是規劃，還要作的另外一件大事就是技術識別。識別出系統中技術的難易區域，並分解複雜技術，使之成爲一個個技術的黑盒子，在此之上再進行新的技術規劃，使整個系統從技術角度來看是分層次的，從難到易，從大到小，但各層之間又是互相的黑盒。這也常說的讓系統模塊間達到「雞犬相聞老死不相往來「的狀態。

一個架構師須要足夠的技術的寬度。從軟件到硬件，從開發到測試，從運維到安全等都須要面面俱到的瞭解。固然你可能不是這單方面領域裏面最深刻的人，可是你須要知道它們是怎麼作的（不只僅是皮毛，要深刻原理），而且要知道它們組合起來是個什麼樣的東西。技術面也足夠寬了以後，是否是就會成爲完美架構師呢？

答案是不會，由於還有新的問題要過來。此次的問題諸如「系統在將來的運行過程當中運維須要作什麼？」「系統在將來的功能迭代中如何更方便的擴展？」「系統應該怎麼修改？」「系統應該被怎麼樣升級？」這時的你是不時很困惑？是否是感受這個架構的世界好長啊，怎麼像保姆同樣什麼都要管。但仔細想一想這是應該的，由於一個系統初次開發並交付只是它生命週期中的一小部分而已。後面的維護、改造、升級才佔了整個軟件生命週期的絕大部分時間。你是它的架構設計者，是它靈魂之所在，你固然應該設計好它的將來。這也是架構師作好的最後一件事情：系統將來的設計。

架構師的定義？

我的以爲架構師須要具備如下幾特色：

知識廣度：須要知道主流技術爲何誕生，能解決什麼問題？若是同一種業務用不用的技術來實現，會有什麼哪些優缺點？好比：流行的ORM框架Mybatis 和 hibernate ，他們之間的優缺點是什麼？要有清晰的認識會能在技術造型時作出正確的決定。

抽象能力：對業務和技術進行抽象。業務抽象就是對需求進行分析後，可以創建完美的實體類以及他們之間的聯繫。技術抽象是對總體架構進行一個分層，各層之間的交互。這相當重要，若是技術抽象能力不足，這會致使整個系統的架構不靈活，難以維護和擴展。

知識的深度：至少是某個領域的專家，好比消息隊列，activeMQ熟悉其源碼，知道其實現。

優秀的學習能力：對新的技術和前沿性的技術進行學習，使用它來解決工做中的業務問題。

那麼你該如何去作呢?我以爲能夠從如下幾個步驟開始：

1: 紮實的JAVA 基礎，Think in java上介紹的內容都能理解，作到這一步恭喜成爲了程序員。

2：熟練使用主流框架，如：mybatis，spring 等。

3：研究過至少一種以web框架的源碼，如spring mvc ，struts 等。

4：架構過或者參與太高併發系統設計，知道如何應對突發狀況。

5：對本身所處的業務可以根據本身的知識維度，提出優化建議或者預測其風險點。

以上是我想分享給你們的，也許說的不夠好，不夠全面，可是但願對大家有所幫助。

哦對了，喜歡就別忘了關注一下哦~