如何打造“最好的架構”？

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

“架構”是我們這行業種一個很常見的詞，表明其必然也是經歷了很長的歲月打磨所形成的一個詞。架構的這個詞出現的意義是什么？為了解決什么問題？只有把這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年后才能造出的產品，當初市場還存在嗎？

結語

架構之路任重而道遠。程序設計和架構設計是互通的，每個人都可以從設計好一個程序往設計好一個系統架構前進。如果現在還無從下手的，我推薦大家可以從領域驅動設計這個概念入手，這是由業務為導向的設計方式，可以對培養設計出落地的架構有很大的幫助。最后引用“俞軍”一句名言，我們作為架構師要有“懷疑精神：自我迭代”的心。