[[431666]]

圖片來自 包圖網(wǎng)

架構(gòu)設(shè)計除了掌握技術(shù)框架、技術(shù)組件、技術(shù)原理性知識外，也需要系統(tǒng)性掌握架構(gòu)基礎(chǔ)知識，以架構(gòu)設(shè)計原則為指導，掌握架構(gòu)設(shè)計方法論，通過不斷的優(yōu)化和迭代，來實現(xiàn)更優(yōu)秀的架構(gòu)設(shè)計。

架構(gòu)設(shè)計的本質(zhì)

在了解架構(gòu)本質(zhì)之前先了解下架構(gòu)的定義，百度百科對架構(gòu)的定義：架構(gòu)又名軟件架構(gòu)，是有關(guān)軟件整體結(jié)構(gòu)與組件的抽象描述，用于指導大型軟件系統(tǒng)各個方面的設(shè)計。

從定義中我們提煉出如下幾個關(guān)鍵字：

• 組件：也可以稱為軟件元素或者是架構(gòu)要素。可以是子系統(tǒng)、模塊、應用服務(wù)，取決于不同粒度來看待。
• 結(jié)構(gòu)：是架構(gòu)之后的產(chǎn)出物，不同的軟件系統(tǒng)會有不同結(jié)構(gòu)，這些結(jié)構(gòu)為解決不同場景而設(shè)計。
• 關(guān)系：實現(xiàn)架構(gòu)組件之間的連接。連接關(guān)系可以是 JVM 內(nèi)部調(diào)用、可以是組件之間、可以是跨應用的分布式調(diào)用、也可以是與外系統(tǒng)接口集成調(diào)用。

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

架構(gòu)設(shè)計本質(zhì)就是解決軟件復雜度帶來的問題，軟件復雜度表現(xiàn)形式有很多種，比如業(yè)務(wù)復雜度、性能復雜度、可用性復雜度、可擴展性復雜度、安全復雜度等。

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

業(yè)務(wù)復雜度體現(xiàn)的是如何來拆解業(yè)務(wù)，找到合適的軟件元素和組件，按合適結(jié)構(gòu)進行連接;性能復雜度體現(xiàn)的是找到軟件元素，進行合適連接形成一定結(jié)構(gòu)，達到高性能要求。

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

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

軟件開發(fā)和架構(gòu)設(shè)計的區(qū)別

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

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

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

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

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

架構(gòu)設(shè)計三原則

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

①合適原則

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

以當前業(yè)務(wù)需求和非功能性需求為目標，匹配業(yè)務(wù)發(fā)展所處階段，合理利用資源發(fā)揮最大價值(買車子需要匹配當前經(jīng)濟狀態(tài))。

需要結(jié)合實際場景，合適的系統(tǒng)架構(gòu) (我買車子只是為了代步，不能說我覺得跑車氣派，我就買個跑車，這和業(yè)務(wù)實際場景不符合)。

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

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

②簡單原則

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

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

簡單是軟件設(shè)計的目標，簡單代碼占用的時間少，產(chǎn)生的漏洞少，并且易于修改 、維護、擴展和重構(gòu)。

不要以為簡單設(shè)計是沒有技術(shù)含量，用簡單設(shè)計處理復雜問題更需要優(yōu)秀的架構(gòu)設(shè)計能力。

軟件系統(tǒng)之所以會被說成復雜，體現(xiàn)在結(jié)構(gòu)復雜以及邏輯復雜，而一個復雜問題是由多個簡單問題構(gòu)成的。

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

邏輯復雜系統(tǒng)在內(nèi)部實現(xiàn)所有邏輯功能，幾乎會導致每個環(huán)節(jié)都有問題，它需要面對不斷變化的需求，所有人維護同一套代碼，整個開發(fā)、測試、上線流程變得異常繁重。

③演化原則

最后是演化原則，只有變化是永恒不變的，優(yōu)秀架構(gòu)一定是以業(yè)務(wù)不斷發(fā)展而不斷演進而來。

設(shè)計架構(gòu)要滿足當時業(yè)務(wù)需要 ，具有可擴展性和持續(xù)開發(fā)能力，能夠應變后續(xù)架構(gòu)升級和調(diào)整。

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

架構(gòu)設(shè)計方法論

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

它是一套方法和工具，主要包含 TOGAF 能力框架、 TOGAF 架構(gòu)開發(fā)方法、 TOGAF 企業(yè)連續(xù)體和工具三大部分。

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

ADM 軟件開發(fā)方法是由一組按照架構(gòu)領(lǐng)域的架構(gòu)開發(fā)順序而排列成一個環(huán)的多個階段所構(gòu)成的。

ADM 基礎(chǔ)結(jié)構(gòu)圖如下圖所示：

圖 1：ADM 基礎(chǔ)結(jié)構(gòu)圖

預備階段：梳理業(yè)務(wù)需求，了解需求背后真實的業(yè)務(wù)目標。

架構(gòu)遠景：最終需要達成到一個效果，需要提前做規(guī)劃。

業(yè)務(wù)架構(gòu)、信息系統(tǒng)架構(gòu)、技術(shù)架構(gòu)：屬于架構(gòu)域設(shè)計框架。

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

遷移規(guī)劃、實施治理：后續(xù)線上運維相關(guān)事項，給出合理解決方案。

架構(gòu)設(shè)計方法論：是指導你如何來做架構(gòu)設(shè)計，它有架構(gòu)域劃分，在軟件設(shè)計中架構(gòu)域包括：業(yè)務(wù)架構(gòu)、數(shù)據(jù)架構(gòu)、產(chǎn)品架構(gòu)、應用架構(gòu)、技術(shù)架構(gòu)。

首先需要進行業(yè)務(wù)需求結(jié)合業(yè)務(wù)場景的梳理，熟悉業(yè)務(wù)后，通過歸納以及抽象的方式，形成業(yè)務(wù)架構(gòu)。

依據(jù)業(yè)務(wù)架構(gòu)的理解，研發(fā)人員需要對業(yè)務(wù)做進一步的抽象和沉淀，畫出與之相對應的數(shù)據(jù)架構(gòu)和應用架構(gòu)，最后技術(shù)人員通過技術(shù)架構(gòu)來做功能實現(xiàn)。

業(yè)務(wù)架構(gòu)是目標、是方向，應用架構(gòu)是抽象、是歸納，技術(shù)架構(gòu)是手段、是系統(tǒng)落地的參考物。

下圖為 ADM 架構(gòu)開發(fā)概念藍圖：

圖 2：ADM 架構(gòu)開發(fā)概念藍圖

首先來看業(yè)務(wù)架構(gòu)，業(yè)務(wù)一般為按照如下四層畫出業(yè)務(wù)架構(gòu)圖：

• 場景層：描述業(yè)務(wù)場景。
• 產(chǎn)品功能層：劃分產(chǎn)品功能以及模塊。
• 領(lǐng)域模型層：通過對產(chǎn)品功能分析，抽象領(lǐng)域模型。
• 依賴層：從業(yè)務(wù)層面考慮涉及到底層業(yè)務(wù)依賴哪些子系統(tǒng)或者組件。

其次是數(shù)據(jù)架構(gòu)，數(shù)據(jù)架構(gòu)解決的是：

• 需要什么數(shù)據(jù)
• 怎么存儲
• 如何設(shè)計

數(shù)據(jù)模型最常用視圖就是 ER 圖，它主要描述數(shù)據(jù)實體、屬性和關(guān)系。

• 實體(Entity)：領(lǐng)域?qū)ο蟆?/li>
• 屬性(Attribute)：領(lǐng)域?qū)ο髮傩浴?/li>
• 聯(lián)系(RelationShip)：兩個領(lǐng)域?qū)ο笾g的關(guān)系(1:1，1:n或者)。

再就是應用架構(gòu)，應用架構(gòu)劃分出不同功能模塊，再根據(jù)功能模塊間的關(guān)系，組合成子系統(tǒng)。

應用架構(gòu)關(guān)系三個問題：

• 子系統(tǒng)如何劃分
• 子系統(tǒng)之間什么關(guān)系
• 考慮模塊的復用和功能的抽象

應用架構(gòu)需要體現(xiàn)應用架構(gòu)是否清晰、層次劃分是否明確、各應用系統(tǒng)之間連接關(guān)系是否合理、系統(tǒng)之間耦合程度是否低、是否以統(tǒng)一方式對外提供一致服務(wù)接口。

最后是技術(shù)架構(gòu)，技術(shù)架構(gòu)關(guān)注的問題有，如何使用技術(shù)手段來解決實際問題、技術(shù)框架如何選擇、技術(shù)中間件如何選擇、存儲如何來做、非功能性需求如何來實現(xiàn)等。

整體技術(shù)方案的輸出就是實現(xiàn)技術(shù)架構(gòu)的過程，最終會形成關(guān)鍵技術(shù)實現(xiàn)要點，形成一個完整的技術(shù)架構(gòu)。

寫在最后

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

架構(gòu)設(shè)計是一個長期并且需要不斷打磨的過程，任何系統(tǒng)的架構(gòu)都做不到一蹴而就，需要系統(tǒng)面臨技術(shù)問題、業(yè)務(wù)問題時不斷地優(yōu)化和迭代。

架構(gòu)設(shè)計除了掌握技術(shù)框架、技術(shù)組件、技術(shù)原理性知識外，也需要系統(tǒng)性掌握架構(gòu)基礎(chǔ)知識，以架構(gòu)設(shè)計原則為指導，掌握架構(gòu)設(shè)計方法論，通過不斷地優(yōu)化和迭代，來實現(xiàn)更優(yōu)秀的架構(gòu)設(shè)計。

作者：京東物流江龍飛

編輯：陶家龍

來源：轉(zhuǎn)載自公眾號京東技術(shù)(ID：jingdongjishu)