[[431666]]

圖片來自 包圖網

架構設計除了掌握技術框架、技術組件、技術原理性知識外，也需要系統性掌握架構基礎知識，以架構設計原則為指導，掌握架構設計方法論，通過不斷的優化和迭代，來實現更優秀的架構設計。

架構設計的本質

在了解架構本質之前先了解下架構的定義，百度百科對架構的定義：架構又名軟件架構，是有關軟件整體結構與組件的抽象描述，用于指導大型軟件系統各個方面的設計。

從定義中我們提煉出如下幾個關鍵字：

• 組件：也可以稱為軟件元素或者是架構要素。可以是子系統、模塊、應用服務，取決于不同粒度來看待。
• 結構：是架構之后的產出物，不同的軟件系統會有不同結構，這些結構為解決不同場景而設計。
• 關系：實現架構組件之間的連接。連接關系可以是 JVM 內部調用、可以是組件之間、可以是跨應用的分布式調用、也可以是與外系統接口集成調用。

架構是將軟件組件按照一定結構連接起來的 ，軟件組件怎么來找、用什么結構來連接、如何來連接，這些都是軟件復雜度所帶來的問題。

架構設計本質就是解決軟件復雜度帶來的問題，軟件復雜度表現形式有很多種，比如業務復雜度、性能復雜度、可用性復雜度、可擴展性復雜度、安全復雜度等。

任何一個系統都有它側重解決的復雜度問題，理解每個架構方案背后需要真正解決的是軟件復雜度的什么問題，是評判一個架構設計目的性的關鍵因素，這也是做架構設計中常提的系統約束條件。

業務復雜度體現的是如何來拆解業務，找到合適的軟件元素和組件，按合適結構進行連接;性能復雜度體現的是找到軟件元素，進行合適連接形成一定結構，達到高性能要求。

比如說一個大型 ERP 系統，屬于業務復雜度高的系統，你該如何去拆分它，拆分成一個個獨立完備、具有明確業務邊界的組件，這是做架構設計需要思考的。

再比方說做一個秒殺系統，系統復雜度要求就是性能復雜度，怎么能扛住秒殺的洪峰，這是性能復雜度需要解決的問題。

軟件開發和架構設計的區別

軟件開發更多是面向確定性邏輯問題，依據自身對需求的理解進行實現，實現方式較為固定，流程化開發完成需求功能，實現最終目標。

比方說實現訂單接收的能力，分幾步：參數驗證、商品查詢、庫存預占、生成訂單、扣減庫存、修改訂單狀態、狀態回傳，業務邏輯較為固定，如果再加上編碼規范以及框架約束，除了數據模型以及編碼設計之外，其他方面涉及較少。

架構設計更多是面向不確定性問題，怎么將系統拆分成組件，怎么去識別是不是組件、組件和組件之間怎么進行連接，這些都是有很多種可能性的架構方案。

解決一個軟件復雜度問題方案，有方案 A、方案 B，甚至有方案 C ，應該用哪種，原因是什么，都是架構設計需要思考的問題。

在多種方案之間如何來進行決策，如何判斷自己選擇的方案是合理的，當然決策能力也不是拍腦袋來決定的，它其實也需要一系列原則來進行指導，通過這些指導原則加上實際經驗來決策最優方案。

架構設計三原則

談到架構設計不得不說三個基本原則，作為架構設計過程中的參考，更好幫忙去做分析、做決策、做支持。

①合適原則

首先提到就是合適原則，一切不按實際場景出發的架構設計都是在耍流氓。比如你想買個車子，買貴覺得性價比不高，買便宜了覺得開起來不舒適，你最終會挑一個適合現在經濟能力范圍內又比較舒適的車子，這就是合適原則。

以當前業務需求和非功能性需求為目標，匹配業務發展所處階段，合理利用資源發揮最大價值(買車子需要匹配當前經濟狀態)。

需要結合實際場景，合適的系統架構 (我買車子只是為了代步，不能說我覺得跑車氣派，我就買個跑車，這和業務實際場景不符合)。

還需要和當前的業務規模以及最近 1-2 年的發展規劃相互匹配 (雖然我一次性付不起，但有穩定經濟收入，我可以考慮貸款，分 2 年期。這樣我既買到理想的車型，也不擔心壓力大)。

新技術推出，勢必是解決某一場景下的問題，但并不能解決所有問題，任何架構都要綜合來看，結合合適原則綜合選擇。

②簡單原則

其次是簡單原則，大道至簡，一切簡單化，用最簡單的解決方案來解決問題 。

KISS (Keep Simple and Stupid) 是用戶體驗的最高境界，同樣它適用于架構設計 。

簡單是軟件設計的目標，簡單代碼占用的時間少，產生的漏洞少，并且易于修改 、維護、擴展和重構。

不要以為簡單設計是沒有技術含量，用簡單設計處理復雜問題更需要優秀的架構設計能力。

軟件系統之所以會被說成復雜，體現在結構復雜以及邏輯復雜，而一個復雜問題是由多個簡單問題構成的。

難的是如何拆解它，將它拆解為多個問題，逐個解決，把復雜邏輯拆分為一個個單一執行單元，單個執行單元代碼量一定要盡可能少。

邏輯復雜系統在內部實現所有邏輯功能，幾乎會導致每個環節都有問題，它需要面對不斷變化的需求，所有人維護同一套代碼，整個開發、測試、上線流程變得異常繁重。

③演化原則

最后是演化原則，只有變化是永恒不變的，優秀架構一定是以業務不斷發展而不斷演進而來。

設計架構要滿足當時業務需要 ，具有可擴展性和持續開發能力，能夠應變后續架構升級和調整。

要不斷地在實際應用過程中迭代，保留優秀設計，修復有缺陷設計，改正錯誤設計，剔除無用設計，使架構逐漸完善，要將變化部分和不變部分區分開。

架構設計方法論

提到架構設計方法論，先介紹下 TOGAF(The Open Group Architecture Framework)，它由國際標準權威組織 The Open Group 制定 ，是一個行業標準的體系架構框架 。

它是一套方法和工具，主要包含 TOGAF 能力框架、 TOGAF 架構開發方法、 TOGAF 企業連續體和工具三大部分。

下面主要介紹下軟件開發方法(Architecture Development Method) ADM。

ADM 軟件開發方法是由一組按照架構領域的架構開發順序而排列成一個環的多個階段所構成的。

ADM 基礎結構圖如下圖所示：

圖 1：ADM 基礎結構圖

預備階段：梳理業務需求，了解需求背后真實的業務目標。

架構遠景：最終需要達成到一個效果，需要提前做規劃。

業務架構、信息系統架構、技術架構：屬于架構域設計框架。

技術及解決方案：碰到技術問題都需要有一套甚至是多套解決方案，架構設計職責就是做取舍、做決策。

遷移規劃、實施治理：后續線上運維相關事項，給出合理解決方案。

架構設計方法論：是指導你如何來做架構設計，它有架構域劃分，在軟件設計中架構域包括：業務架構、數據架構、產品架構、應用架構、技術架構。

首先需要進行業務需求結合業務場景的梳理，熟悉業務后，通過歸納以及抽象的方式，形成業務架構。

依據業務架構的理解，研發人員需要對業務做進一步的抽象和沉淀，畫出與之相對應的數據架構和應用架構，最后技術人員通過技術架構來做功能實現。

業務架構是目標、是方向，應用架構是抽象、是歸納，技術架構是手段、是系統落地的參考物。

下圖為 ADM 架構開發概念藍圖：

圖 2：ADM 架構開發概念藍圖

首先來看業務架構，業務一般為按照如下四層畫出業務架構圖：

• 場景層：描述業務場景。
• 產品功能層：劃分產品功能以及模塊。
• 領域模型層：通過對產品功能分析，抽象領域模型。
• 依賴層：從業務層面考慮涉及到底層業務依賴哪些子系統或者組件。

其次是數據架構，數據架構解決的是：

• 需要什么數據
• 怎么存儲
• 如何設計

數據模型最常用視圖就是 ER 圖，它主要描述數據實體、屬性和關系。

• 實體(Entity)：領域對象。
• 屬性(Attribute)：領域對象屬性。
• 聯系(RelationShip)：兩個領域對象之間的關系(1:1，1:n或者)。

再就是應用架構，應用架構劃分出不同功能模塊，再根據功能模塊間的關系，組合成子系統。

應用架構關系三個問題：

• 子系統如何劃分
• 子系統之間什么關系
• 考慮模塊的復用和功能的抽象

應用架構需要體現應用架構是否清晰、層次劃分是否明確、各應用系統之間連接關系是否合理、系統之間耦合程度是否低、是否以統一方式對外提供一致服務接口。

最后是技術架構，技術架構關注的問題有，如何使用技術手段來解決實際問題、技術框架如何選擇、技術中間件如何選擇、存儲如何來做、非功能性需求如何來實現等。

整體技術方案的輸出就是實現技術架構的過程，最終會形成關鍵技術實現要點，形成一個完整的技術架構。

寫在最后

上文闡述了架構設計的一些基本原則，幫助讀者思考如何通過架構設計理論知識提升自身的架構能力，從而成為一名合格架構人員。

架構設計是一個長期并且需要不斷打磨的過程，任何系統的架構都做不到一蹴而就，需要系統面臨技術問題、業務問題時不斷地優化和迭代。

架構設計除了掌握技術框架、技術組件、技術原理性知識外，也需要系統性掌握架構基礎知識，以架構設計原則為指導，掌握架構設計方法論，通過不斷地優化和迭代，來實現更優秀的架構設計。

作者：京東物流江龍飛

編輯：陶家龍

來源：轉載自公眾號京東技術(ID：jingdongjishu)