如何才能成為一個好的Java架構師

一、架構的定義

所謂一千個架構師中有一千種“最好的架構”模式。

“架構”是我們這行業種一個很常見的詞，表明其必然也是經曆了很長的歲月打磨所形成的一個詞。架構的這個詞出現的意義是什麼？為了解決什麼問題？隻有把這2個問題想明白了，才能設計出一個良好的項目架構。

我認為 架構類似于畫房屋設計圖，在剛開始我們蓋一層樓的小房子的時候，拍拍腦門想一下，腦子裡有個大概的樣子就開始動工了，想怎麼蓋就怎麼蓋，大部分情況下也都不會出現。但是當你要蓋一個大樓，這時候拍拍腦門的方式雖然有可能還能管用，但是由于沒有經過深思熟慮的多方考量，建造出來的必然是問題重重。另外建造大樓和蓋個一層樓的小屋所需的團隊規模肯定是不同的，每個人心中的标準不同，如果沒有一個統一的規範，最後的結果可想而知。是以架構就是定規則做限制，是在權衡各方得與失之後的一個“最合理決策”，由它來指導團隊中的每個人思想層面上的一緻，使得最終的産品達到像由一個人做出來的一樣。另外還有控制複雜度、提高團隊協作力、降低成本等等作用。

在軟體開發中，架構的意義不單單是為了讓團隊達成一緻，因為我們工作的本質是為了做出更好的支撐業務發展需要的軟體産品，是以架構也是基于業務的架構。我認為一個好的架構能夠提前預見業務發展1~2年為宜。這樣可以付出較為合理的代價換來真正達到技術引領業務成長的效果。我相信大部分在中小型公司呆過的人應該都經曆過被業務推着走的時代，每天焦頭爛額的這裡卡了，這裡挂了，這裡報錯等等問題。當我們遇到這些問題的時候是時候花成本來考量目前的架構是否存在問題？

二、如何開始設計一個架構

做架構的最重要的一點就是上面說的貼合業務，任何不基于業務做異想天開的架構都是耍流氓~

架構不是像平常寫代碼一樣，對就是對，錯就是錯，它并無對錯之分，是一個取舍的過程。當我們從0開始做架構的時候，的确是比較困難。雖然萬事開頭難，但是一個好的開始相當于成功了一半，會給我們接下去的工作打下結實的基礎。

下面來闡述一下筆者個人是如何從頭開始做一個架構的，供大家參考學習：

1.架構是一個整體–> 部分的過程，先得明确整個公司/組織對外提供的服務是什麼？這是最上層的戰略架構，這個基本是一旦确定就很難甚至無法更改了。

2.給每個部分（比如SOA的某個服務）劃分解決方案。比如根據公司的組織架構或者産品等。

3.找到每個解決方案的核心功能和支撐功能。并形成一個業務總覽圖。

4.分久必合，合久必分，結合目前的實際資源情況做出最終的決策，這是整個過程中最耗時的點，它決定着架構的複雜度和開發成本。方式上包括但不限于抽出可重用的功能、功能的組合、拆分粒度更細的功能提高可重用性等等。這一切的決策都要以“恰到好處”為宜。千萬不要盲目的跟從微服務之風！千萬不要盲目的跟從微服務之風！千萬不要盲目的跟從微服務之風！重要的事情說3遍。服務粒度越細，調用鍊路越複雜，帶來的開發成本是否适合團隊，是作為一個架構師需要着重考量的點。

5.确立每個功能塊之間的協作方式，包括但不限于通訊方式，通訊協定，依賴關系等。

6.最後要把這些形成最終的架構總覽圖，這樣能夠幫助站在一個更高的角度去考慮架構的演變問題。如果是針對現存項目重新做架構，那麼需要把現有項目架構梳理出來，作為我們上面思考過程中的一部分參考資訊。

三、一個好架構的特點

首先從心态上必須要有工匠精神，因為軟體架構和造房子還是有不同的，它不是一開始就一步到位的，好的設計肯定需要經過反複的修改，從簡單到複雜的循環驗證，不斷的打磨。

方向上我認為分以下幾個點：

1.文檔化：不管是整體還是部分的整個生命周期内都必須做好文檔化，變動的來源包括但不限于BUG，需求。

2.高可用：要盡可能的提高軟體的可用性，我想每個操作人都不願意看到自己的工作無法正常進行。黑盒白盒測試、單元測試、自動化測試、故障注入測試、提高測試覆寫率等方式來一步一步推進。

3.安全：組織的運作過程中産生的資料都是具有商業價值的，保證資料的安全也是刻不容緩的一部分。以免出現XX門之類醜聞。加密、https等為普遍手段。

4.可擴充：軟體的設計秉承着低耦合的理念去做，注意在合理的地方抽象。友善功能更改、新增和運用技術的疊代，并且支援在适時對架構做出重構。

5.快速疊代：擁抱變化，占領戰略先機。

6.高度自治：為了更好支撐第4點和第5點的，每個功能能夠高度自治帶來的好處是可以快速疊代，并且不管是功能疊代還是技術疊代所對整個系統的影響降到最小。

7.高複用：為了避免重複勞動，為了降低成本，我們希望能夠重用之前的代碼、之前的設計。這點對于架構環境的依賴是最大的。

8.可驗證：一個好的架構需要考慮到各種特殊情況，并且是可以進行專項驗證的。

四、做架構中的誤區

做任何事的時候需要不斷的跳出原來的思維角度重新審視，這樣才能避免陷入泥潭。列出幾個我能想到的誤區：

誤區1——架構專門由架構師來做，業務開發人員無需關注：架構的再好，最終還是需要代碼來落地，并且組織越大這個落地的難度越大。不單單是系統架構，每個解決方案每個項目也由自己的架構，如分層、設計模式等。如果每一塊磚瓦不夠堅固，那麼整個系統還是會由崩塌的風險。所謂“千裡之堤，潰于蟻穴”。

誤區2——架構師确定了架構藍圖之後任務就結束了：架構不是“空中樓閣”，最終還是要落地的，但是架構師完全不去深入到第一線怎麼知道“地”在哪？怎麼才能落的穩穩當當。

誤區3——不做出完美的架構設計不開工：世上沒有最好架構，隻有最合适的架構。我們需要的不是一下子造出一輛汽車，而是從單輪車 --> 自行車 --> 機車，最後再到汽車。想象一下2年後才能造出的産品，當初市場還存在嗎？

五、結語

架構之路任重而道遠。程式設計和架構設計是互通的，每個人都可以從設計好一個程式往設計好一個系統架構前進。