架構設計之道

導讀

本文主要從架構設計的本質、架構設計原則、架構設計方法論三個方面來進行闡述，架構設計除了掌握技術框架、技術組件、技術原理性知識外，也需要系統性掌握架構基礎知識，以架構設計原則爲指導，掌握架構設計方法論，通過不斷的優化和迭代，來實現更優秀的架構設計。

01

本質

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

從定義中我們提煉出幾個關鍵字：組件、結構、關係。

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

架構設計本質就是解決軟件複雜度帶來的問題，軟件複雜度表現形式有很多種，比如業務複雜度、性能複雜度、可用性複雜度、可擴展性複雜度、安全複雜度等；任何一個系統都有它側重解決的複雜度問題，理解每個架構方案背後需要真正解決的是軟件複雜度的什麼問題，是評判一個架構設計目的性的關鍵因素，這也是做架構設計中常提的系統約束條件。

業務複雜度體現的是如何來拆解業務，找到合適的軟件元素和組件，按合適結構進行連接；性能複雜度體現的是找到軟件元素，進行合適連接形成一定結構，達到高性能要求。比如說一個大型 ERP 系統，屬於業務複雜度高的系統，你該如何去拆分它，拆分成一個個獨立完備、具有明確業務邊界的組件，這是做架構設計需要思考的。再比方說做一個秒殺系統，系統複雜度要求就是性能複雜度，怎麼能扛住秒殺的洪峯，這是性能複雜度需要解決的問題。

02

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

軟件開發更多是面向確定性邏輯問題，依據自身對需求的理解進行實現，實現方式較爲固定，流程化開發完成需求功能，實現最終目標。比方說實現訂單接收的能力，分幾步：參數驗證、商品查詢、庫存預佔、生成訂單、扣減庫存、修改訂單狀態、狀態回傳，業務邏輯較爲固定，如果再加上編碼規範以及框架約束，除了數據模型以及編碼設計之外，其他方面涉及較少。

架構設計更多是面向不確定性問題，怎麼將系統拆分成組件，怎麼去識別是不是組件、組件和組件之間怎麼進行連接，這些都是有很多種可能性的架構方案，解決一個軟件複雜度問題方案，有方案 A、方案 B，甚至有方案 C ，應該用哪種，原因是什麼，都是架構設計需要思考的問題。在多種方案之間如何來進行決策，如何判斷自己選擇的方案是合理的，當然決策能力也不是拍腦袋來決定的，它其實也需要一系列原則來進行指導，通過這些指導原則加上實際經驗來決策最優方案。

03

架構設計三原則

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

首先提到就是合適原則，一切不按實際場景出發的架構設計都是在耍流氓。比如你想買個車子，買貴覺得性價比不高，買便宜了覺得開起來不舒適，你最終會挑一個適合現在經濟能力範圍內又比較舒適的車子，這就是合適原則。以當前業務需求和非功能性需求爲目標，匹配業務發展所處階段，合理利用資源發揮最大價值（買車子需要匹配當前經濟狀態）；需要結合實際場景，合適的系統架構 （我買車子只是爲了代步，不能說我覺得跑車氣派，我就買個跑車，這和業務實際場景不符合）；還需要和當前的業務規模以及最近 1-2 年的發展規劃相互匹配 （雖然我一次性付不起，但有穩定經濟收入，我可以考慮貸款，分 2 年期。這樣我既買到理想的車型，也不擔心壓力大）；新技術推出，勢必是解決某一場景下的問題，但並不能解決所有問題，任何架構都要綜合來看，結合合適原則綜合選擇。

其次是簡單原則，大道至簡，一切簡單化，用最簡單的解決方案來解決問題 。KISS （Keep Simple and Stupid） 是用戶體驗的最高境界，同樣它適用於架構設計 ；簡單是軟件設計的目標，簡單代碼佔用的時間少，產生的漏洞少，並且易於修改 、維護、擴展和重構；不要以爲簡單設計是沒有技術含量，用簡單設計處理複雜問題更需要優秀的架構設計能力；軟件系統之所以會被說成複雜，體現在結構複雜以及邏輯複雜，而一個複雜問題是由多個簡單問題構成的，難的是如何拆解它，將它拆解爲多個問題，逐個解決，把複雜邏輯拆分爲一個個單一執行單元，單個執行單元代碼量一定要儘可能少。邏輯複雜系統在內部實現所有邏輯功能，幾乎會導致每個環節都有問題，它需要面對不斷變化的需求，所有人維護同一套代碼，整個開發、測試、上線流程變得異常繁重。

最後是演化原則，只有變化是永恆不變的，優秀架構一定是以業務不斷髮展而不斷演進而來；設計架構要滿足當時業務需要 ，具有可擴展性和持續開發能力，能夠應變後續架構升級和調整；要不斷地在實際應用過程中迭代，保留優秀設計，修復有缺陷設計，改正錯誤設計，剔除無用設計，使架構逐漸完善，要將變化部分和不變部分區分開。

04

架構設計方法論

提到架構設計方法論，先介紹下 TOGAF（The Open Group Architecture Framework），它由國際標準權威組織 The Open Group 制定 ，是一個行業標準的體系架構框架 。它是一套方法和工具，主要包含 TOGAF 能力框架、 TOGAF 架構開發方法、 TOGAF 企業連續體和工具三大部分。

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

ADM 軟件開發方法是由一組按照架構領域的架構開發順序而排列成一個環的多個階段所構成的，ADM 基礎結構圖如下圖所示。

圖一 ADM 基礎結構圖

**預備階段：**梳理業務需求，瞭解需求背後真實的業務目標；

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

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

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

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

架構設計方法論是指導你如何來做架構設計，它有架構域劃分，在軟件設計中架構域包括：業務架構、數據架構、產品架構、應用架構、技術架構，首先需要進行業務需求結合業務場景的梳理，熟悉業務後，通過歸納以及抽象的方式，形成業務架構，依據業務架構的理解，研發人員需要對業務做進一步的抽象和沉澱，畫出與之相對應的數據架構和應用架構，最後技術人員通過技術架構來做功能實現。業務架構是目標、是方向，應用架構是抽象、是歸納，技術架構是手段、是系統落地的參考物。

下圖爲 ADM 架構開發概念藍圖。

圖二 ADM 架構開發概念藍圖

首先來看業務架構，業務一般爲按照場景層、產品功能層、領域模型層、依賴層這四層畫出業務架構圖。

**場景層：**描述業務場景；

**產品功能層：**劃分產品功能以及模塊；

**領域模型層：**通過對產品功能分析，抽象領域模型；

**依賴層：**從業務層面考慮涉及到底層業務依賴哪些子系統或者組件。

其次是數據架構：數據架構解決的是，第一，需要什麼數據；第二，怎麼存儲；第三，如何設計。

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

再就是應用架構，應用架構劃分出不同功能模塊，再根據功能模塊間的關係，組合成子系統。應用架構關係三個問題。第一，子系統如何劃分；第二，子系統之間什麼關係；第三，考慮模塊的複用和功能的抽象。應用架構需要體現應用架構是否清晰、層次劃分是否明確、各應用系統之間連接關係是否合理、系統之間耦合程度是否低、是否以統一方式對外提供一致服務接口。

最後是技術架構，技術架構關注的問題有，如何使用技術手段來解決實際問題、技術框架如何選擇、技術中間件如何選擇、存儲如何來做、非功能性需求如何來實現等。整體技術方案的輸出就是實現技術架構的過程，最終會形成關鍵技術實現要點，形成一個完整的技術架構。

05

寫在最後

上文闡述了架構設計的一些基本原則，幫助讀者思考如何通過架構設計理論知識提升自身的架構能力，從而成爲一名合格架構人員。架構設計是一個長期並且需要不斷打磨的過程，任何系統的架構都做不到一蹴而就，需要系統面臨技術問題、業務問題時不斷地優化和迭代。架構設計除了掌握技術框架、技術組件、技術原理性知識外，也需要系統性掌握架構基礎知識，以架構設計原則爲指導，掌握架構設計方法論，通過不斷地優化和迭代，來實現更優秀的架構設計。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/A9LDJ_5n8e2fETgBh8Vx1Q

猜你喜歡