Java架構師有哪些要求

什麽是架構？什麽是架構師？Java架構師和工程師有何區別？這似乎是聊架構話題時永恒的問題。

因為從實際情況看，在不同的系統層級，不同的需求下架構師的職責也會不同；從不同的技術角度看，架構師又是個變色龍，壹時是技術的大拿，壹時是技術的規劃者，壹時是技術團隊的指揮者。

那麽，該如何回答“什麽是架構，什麽是架構師”這個問題呢？這或許需要先搞清楚另外壹個問題——壹名程序員是如何走上架構師之路的？通過很多實際案例，可以看出，程序員走上架構師之路，總結起來最多的原因是因為他早前代碼寫的好。

那麽，代碼寫的好就是架構嗎？顯然不是。代碼寫的好只是表象，做所有事情都需要規劃，尤其是壹個復雜的軟件系統，這更需要規劃，否則可能連壹行代碼都寫不出。復雜的軟件系統壹定會需要做很多抽象設計、對象規劃、接口規劃等準備動作。也就是“傳統老壹輩兒程序員”口中所說的：詳細設計。做架構主要的事情也依舊如此，需要對整個系統進行系統的規劃：模塊、通訊、邊界、擴展、技術下沈等工作。這樣的規劃完成之後項目方能正常跑起來。

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

壹個架構師需要足夠的技術的寬度。從軟件到硬件，從開發到測試，從運維到安全等都需要面面俱到的了解。當然妳可能不是這單方面領域裏面最深入的人，但是妳需要知道它們是怎麽做的（不僅僅是皮毛，要深入原理），並且要知道它們組合起來是個什麽樣的東西。技術面也足夠寬了之後，是不是就會成為完美架構師呢？

答案是不會，因為還有新的問題要過來。這次的問題諸如“系統在未來的運行過程中運維需要做什麽？”“系統在未來的功能叠代中如何更方便的擴展？”“系統應該怎麽修改？”“系統應該被怎麽樣升級？”這時的妳是不時很困惑？是不是感覺這個架構的世界好長啊，怎麽像保姆壹樣什麽都要管。但仔細想想這是應該的，因為壹個系統初次開發並交付只是它生命周期中的壹小部分而已。後面的維護、改造、升級才占了整個軟件生命周期的絕大部分時間。妳是它的架構設計者，是它靈魂之所在，妳當然應該設計好它的未來。這也是架構師做好的最後壹件事情：系統未來的設計。

架構師的定義？

個人覺得架構師需要具有以下幾特點：

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

抽象能力：對業務和技術進行抽象。業務抽象就是對需求進行分析後，能夠建立完美的實體類以及他們之間的聯系。技術抽象是對整體架構進行壹個分層，各層之間的交互。這至關重要，如果技術抽象能力不足，這會導致整個系統的架構不靈活，難以維護和擴展。

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

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

那麽妳該如何去做呢?我覺得可以從以下幾個步驟開始：

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

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

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

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

5：對自己所處的業務能夠根據自己的知識維度，提出優化建議或者預測其風險點。