不論是開發(fā)人員還是架構(gòu)師，我們都一直在跟軟件系統(tǒng)打交道，架構(gòu)是在工作中出現(xiàn)最頻繁的術(shù)語之一。那么，到底什么是架構(gòu)？你可能有自己的答案，也有可能沒有答案。對“架構(gòu)”的理解需要我們不斷在實踐中思考、歸納、演繹，形成自己的認知。

1 到底什么是軟件架構(gòu) ？

定義 ”架構(gòu)是什么“ 是件非常困難的事情，不同的組織對于軟件架構(gòu)有不同的定義，每個人心中也有自身對于系統(tǒng)架構(gòu)定義的認知。就好比我們無法百分之百表述模型而只能產(chǎn)出模型不同維度的視圖，對架構(gòu)進行完備的定義是不可能的。

“道可道，非常道。名可名，非常名”，道是如此，架構(gòu)亦是如此。

行業(yè)內(nèi)不同的組織和個人從不同的視角對 “什么是架構(gòu)” 進行了定義或闡述。

IEEE 關(guān)于架構(gòu)的定義

將系統(tǒng)架構(gòu)定義為：架構(gòu)是系統(tǒng)組織結(jié)構(gòu)+組件及聯(lián)系（組件間以及組件和環(huán)境之間）+原則的組合。通過圖形化的形式表述該架構(gòu)定義如下圖所示，這是一個非常簡潔、概念清晰的定義，其言簡意賅的表達了架構(gòu)的幾個核心要素：

系統(tǒng)的組織：表達系統(tǒng)的宏觀結(jié)構(gòu)

組件及聯(lián)系：組件化的思維，同時突出了環(huán)境要素。組件表達了系統(tǒng)的模塊化，組件相互之間及組件與環(huán)境之間的關(guān)聯(lián)表達元素間的相互作用。

原則：用于指導設(shè)計和系統(tǒng)演進的原則

大師Martin Fowler和Ralph Johnson對于架構(gòu)的定義有著類似的、更加簡潔和抽象，Martin Fowler 認為軟件架構(gòu)是：重要并且難以改變的決策。架構(gòu)設(shè)計是關(guān)于權(quán)衡的藝術(shù)，架構(gòu)設(shè)計過程中充滿了各種各樣的決策，這些決策也終將反應(yīng)系統(tǒng)架構(gòu)。

Software Architecture = Important and hard to change decisions --Martin Fowler

The software architecutre is the important stuff ! Whatever it is ! --Ralph Johnson

以上的定義從高層抽象視角對什么是架構(gòu)給予了自己的回答，相比之下，Neil Ford 在《軟件架構(gòu)基礎(chǔ)》一書中對架構(gòu)給出了更具象的闡述，其從架構(gòu)組成元素入手，從更偏向?qū)嵺`的角度對架構(gòu)進行了闡述。核心思想是軟件系統(tǒng)的架構(gòu)包括以下組合元素：

結(jié)構(gòu)：應(yīng)用系統(tǒng)所選擇的架構(gòu)風格，比如微服務(wù)架構(gòu)、單體架構(gòu)還是SOA等

架構(gòu)屬性：系統(tǒng)的非功能性屬性，比如性能、可用性、可維護性等

架構(gòu)決策：系統(tǒng)設(shè)計過程中重要的架構(gòu)決策

設(shè)計原則：設(shè)計過程中的指導性原則

結(jié)構(gòu)

結(jié)構(gòu)是系統(tǒng)架構(gòu)的重要組成部分，其從宏觀上表述了系統(tǒng)的結(jié)構(gòu)組成。架構(gòu)設(shè)計的核心任務(wù)之一是為系統(tǒng)選擇合適的架構(gòu)風格。比如，架構(gòu)師基于上下文的權(quán)衡，可以選擇模塊化單體架構(gòu)風格，也可以選擇微服務(wù)架構(gòu)風格。

架構(gòu)屬性

架構(gòu)屬性亦稱質(zhì)量屬性，或非功能屬性，通常表示系統(tǒng)需要具備或滿足的某種 “能力”，比如高性能、可擴展性、彈性、伸縮性、容錯性、可測試性、可維護性等等。架構(gòu)設(shè)計的目標需要關(guān)注系統(tǒng)需要滿足的架構(gòu)屬性，架構(gòu)最終要體現(xiàn)對架構(gòu)屬性支持的相關(guān)架構(gòu)決策。架構(gòu)屬性眾多，系統(tǒng)需要關(guān)注的是這些架構(gòu)屬性的子集，具體的某次特定的架構(gòu)設(shè)計所需要關(guān)注的架構(gòu)屬性需要依據(jù)問題域的上下文而具體分析。同時，不同的架構(gòu)屬性間可能存在沖突，這種情況同樣需要架構(gòu)師的權(quán)衡和決策。

架構(gòu)決策

架構(gòu)決策是系統(tǒng)架構(gòu)設(shè)計過程中對解決方案的選擇，其描述了系統(tǒng)必須遵循的規(guī)則。架構(gòu)決策隨著權(quán)衡分析而自然存在，其是系統(tǒng)架構(gòu)設(shè)計的重要維度之一。并不是所有的決策都是架構(gòu)決策，架構(gòu)決策應(yīng)該關(guān)注對系統(tǒng)有重要影響的部分。比如對架構(gòu)風格的選擇對系統(tǒng)存在重要影響，其改變的成本較高，理當屬于架構(gòu)決策的范疇。比較典型架構(gòu)決策包括但不限于：

直接影響高優(yōu)先級的架構(gòu)屬性

修改對外接口：對外提供的接口修改往往需要進行充分影響分析

引入或者移除依賴：依賴的加入和移除往往標示著組件能力的引進和廢棄

改變系統(tǒng)的通用結(jié)構(gòu)：工程結(jié)構(gòu)是應(yīng)用架構(gòu)的重要維度之一

迫使研發(fā)人員改變開發(fā)方式

接受戰(zhàn)略性技術(shù)債：重構(gòu)影響較大的技術(shù)債往往對現(xiàn)有系統(tǒng)會有較大影響

注：架構(gòu)決策建議以輕量級的文檔化形式進行記錄，參考文章 《輕量級的架構(gòu)決策記錄機制》一文

設(shè)計原則

設(shè)計原則與架構(gòu)決策不同，其本質(zhì)區(qū)別是：設(shè)計原則是一種指導，而非強制的規(guī)則。架構(gòu)決策需要遵守，設(shè)計原則提供參考性指引。

比如，設(shè)計原則可能是：在可能的情況下，跨系統(tǒng)間的通信盡可能使用異步消息機制以提高性能和降低耦合。

2 架構(gòu)設(shè)計的邊界

如果你是團隊的架構(gòu)師，你是否有以下困惑：

系統(tǒng)的架構(gòu)應(yīng)該設(shè)計到什么粒度？

架構(gòu)設(shè)計是否要足夠詳細以便能直接指導開發(fā)人員開展編碼工作？

如果你是團隊的核心開發(fā)人員，你是否 “抱怨” 過：

"架構(gòu)設(shè)計" 太過詳細，涵蓋了實現(xiàn)的 “細枝末節(jié)”，自己除了CRUD沒有發(fā)揮的空間

"架構(gòu)設(shè)計" 太過宏觀，基于設(shè)計方案根本無法指導開發(fā)，自己還得重新設(shè)計

很多架構(gòu)師自身對架構(gòu)和設(shè)計的邊界缺乏深入認知，相比于對架構(gòu)邊界的縮小，更多時候會出現(xiàn)架構(gòu)設(shè)計邊界放大的情況：

架構(gòu)師把架構(gòu)設(shè)計當作詳細的技術(shù)方案設(shè)計，牢牢把控系統(tǒng)實現(xiàn)的所有細節(jié)，產(chǎn)出大量的設(shè)計文檔，然后交由核心開發(fā)人員做代碼實現(xiàn)的執(zhí)行工作。

這種現(xiàn)象會導致如下問題：

壓縮了團隊核心開發(fā)人員的設(shè)計發(fā)揮空間，不利于其技術(shù)水平及認知的提升

作為架構(gòu)師你真的能講所有的細節(jié)都Cover住嗎？即使耗費巨大精力完成了 “完備” 的設(shè)計，來自一線開發(fā)所面臨的各種場景是否能夠提前預知和捕獲？

如果需求迭代持續(xù)如此，作為核心開發(fā)人員多半會有所 “怨言”

作為團隊的架構(gòu)師精力有限，持續(xù)的細節(jié)輸出會耗費巨大精力，而無法關(guān)注更加宏觀的層面

.......

以上問題的根源是什么？不能明確架構(gòu)設(shè)計的邊界！

架構(gòu)設(shè)計與設(shè)計（實現(xiàn)相關(guān)）的邊界或粒度問題

團隊架構(gòu)師與開發(fā)人員間的職責邊界

判斷架構(gòu)邊界的前提之一是：明確架構(gòu)和設(shè)計的關(guān)系！

所有的架構(gòu)都是設(shè)計，但設(shè)計不一定是架構(gòu)！

從架構(gòu)的定義看架構(gòu)設(shè)計的邊界，選取兩個視角：

架構(gòu)是系統(tǒng)中重要的東西！無論它是什么（之所以重要，是因為改變的成本高）

架構(gòu)設(shè)計涵蓋系統(tǒng)中重要的架構(gòu)決策

所以，架構(gòu)設(shè)計應(yīng)該涵蓋系統(tǒng)中重要的東西，這些 “重要的東西” 可能是：

應(yīng)用架構(gòu)風格的選擇

子系統(tǒng)間信息通信的方式

工程采取的分層以及層間約束

工程應(yīng)該遵循的開發(fā)規(guī)范

工程引入的三方類庫，或者三方框架

高優(yōu)先級的架構(gòu)屬性：比如某次需求建設(shè)非常關(guān)注系統(tǒng)的性能，或者擴展性等架構(gòu)屬性

其它 "重要的東西"

架構(gòu)設(shè)計涵蓋了系統(tǒng)所需的重要的架構(gòu)決策，從宏觀層面對系統(tǒng)實現(xiàn)予以指引。而詳細的設(shè)計則為具體的開發(fā)實現(xiàn)提供指導，比如，詳細的E-R圖設(shè)計、具體的代碼級別的模式選擇、某個組件的具體實現(xiàn)等等。

架構(gòu)不是一成不變，需要持續(xù)演進，而實現(xiàn)相關(guān)的設(shè)計也可能在項目進行中持續(xù)變化，因此，二者不能完全割裂，而是需要在實現(xiàn)過程中進行雙向反饋：

架構(gòu)設(shè)計信息要高效的同步至開發(fā)人員

實現(xiàn)過程中的變更同樣也要回向反饋至架構(gòu)，以便對架構(gòu)設(shè)計進行調(diào)整

在進行架構(gòu)邊界判定時要注意一個至關(guān)重要的因子：上下文！！！以上的判斷準則必須要給定的上下文中才有價值。

比如：實現(xiàn)過程中大家經(jīng)常會適用一些設(shè)計模式，例如策略模式。那么，這種設(shè)計模式的選擇是屬于架構(gòu)設(shè)計還是詳細的實現(xiàn)設(shè)計？答案就是：It depends!!! 具體情況，具體分析。

如果當前上下文，我們非常關(guān)注系統(tǒng)的擴展性，該架構(gòu)屬性是我們高優(yōu)先級的架構(gòu)屬性，那么，核心模塊的策略模式的應(yīng)用可以看作是架構(gòu)設(shè)計的范疇。而如果上下文中擴展性不是我們關(guān)注的高優(yōu)先級的架構(gòu)屬性，相比我們更關(guān)注性能，那么，這種代碼級的設(shè)計模式選擇應(yīng)該屬于架構(gòu)設(shè)計的范疇之外了，而需要劃分到實現(xiàn)設(shè)計層面，交由核心開發(fā)自主決定。

3 架構(gòu)模式（Patterns）與架構(gòu)風格（Styles）

架構(gòu)模式和架構(gòu)風格是極容易混淆的兩個概念，很多開發(fā)人員將其理解為同一事物，而實際上二者有本質(zhì)區(qū)別。

架構(gòu)風格是系統(tǒng)設(shè)計的頂層抽象，從宏觀視角表述我們的系統(tǒng)組成。更進一步，架構(gòu)風格聚焦于系統(tǒng)的分層、模塊以及交互形式。

架構(gòu)模式聚焦于對重復出現(xiàn)問題提供解決方案

二者概念不同，并不存在沖突，其聯(lián)系如下圖所示：

架構(gòu)模式可以應(yīng)用于架構(gòu)風格，在同一架構(gòu)風格上下文內(nèi)可以應(yīng)用一或多中架構(gòu)模式

架構(gòu)風格可以組合以產(chǎn)生新的架構(gòu)風格

比較典型的例子是CQRS：CQRS本身是一種模式，將命令和查詢的職責在不同維度進行分離。該模式我們可以在單體架構(gòu)風格中使用，也可以在微服務(wù)架構(gòu)風格中使用，當然也可以在SOA架構(gòu)中使用。

4 為什么要做架構(gòu)設(shè)計 ？

至于 “為什么要做架構(gòu)設(shè)計” 也是一個古老且頻繁出現(xiàn)的問題，有太多的文章闡述為社么要架構(gòu)設(shè)計：有的宏觀，有的具體，有的“務(wù)實”，有的“務(wù)虛”。我把這個問題作為一個獨立章節(jié)闡述，并不是想進行大篇幅的論述，只是想突出它的重要性，這個問題值得耗費一些精力去深入理解其背后的原因。但，在此不做展開過多說明，通過一句話來進行概括：

之所以要進行架構(gòu)設(shè)計，是因為：重要 ！

做，收益高

不做，成本高

5 開發(fā)人員和架構(gòu)師的知識模型

作為開發(fā)人員，更加關(guān)注知識的深度，以便有足夠的知識儲備滿足工作需要。開發(fā)人員在職業(yè)生涯的早期，應(yīng)該關(guān)注于自身知識儲備的增長，并保持技術(shù)深度。

作為架構(gòu)師，之所以技術(shù)的廣度比深度更重要，是因為架構(gòu)師的重要職責之一是進行架構(gòu)決策。系統(tǒng)架構(gòu)設(shè)計是關(guān)于權(quán)衡的藝術(shù)，在特定的問題域上下文下，架構(gòu)師需要在諸多可行的解決方案間進行權(quán)衡和決策，這也對其技術(shù)廣度提出了要求。開發(fā)人員成長為架構(gòu)師，應(yīng)該更加關(guān)注知識的廣度，并在幾個特定領(lǐng)域深耕，以便有足夠的知識支撐架構(gòu)決策。

雖然開發(fā)人員和架構(gòu)師在知識域的關(guān)注點上存在差異，但在認知層面都可以統(tǒng)一到Bloom認知層次模型。該模型將認知層次劃分為逐步遞進的六個層次：

識記：識別和回溯事實性知識

理解：理解事實的內(nèi)涵

應(yīng)用：將事實、規(guī)則、概念、思想加以應(yīng)用

分析：將信息分解、關(guān)聯(lián)、區(qū)分、實驗、測試

評估：將信息或思想的價值進行評價

創(chuàng)造：整合不同的信息形成新的知識體系

不論是架構(gòu)師還是開發(fā)人員，Bloom認知層次模型都適用。通過不斷的學習擴展自身的知識體系，在識記、理解和應(yīng)用的同時，要持續(xù)的培養(yǎng)分析、評估和創(chuàng)造的能力，逐步向高層次的認知水平提升。

但需要注意的是：知識不等于認知，避免陷入知識學習的陷阱。知識是無限的，沒有人能夠以無限的精力去學習無限的知識。不論是開發(fā)人員還是架構(gòu)師，又或者其他角色，不應(yīng)該只將精力投入在知識邊界的擴充，而應(yīng)該注重從知識到認知提升的轉(zhuǎn)變。

吾生也有涯，而知也無涯。以有涯隨無涯，殆矣！已而為知者，殆而已矣！ ----《莊子》

格物以致知，對表象不斷的歸納、演繹直至事物的本象，探尋事物背后的規(guī)律，建立更高層的認知。這種認知層次由下及上的躍升有兩種方式：

悟：由內(nèi)向外，通過不斷積累、持續(xù)思考，由量變到質(zhì)變，直至 “開悟”

破：自外向內(nèi)，高層次或不同的思想輸入碰撞，加速認知層次的突破

6 結(jié)語

對架構(gòu)定義的探討實際上是一種樸素的 “格物” 的過程，每個人都應(yīng)該尋找自己的答案。跳脫對架構(gòu)定義探討的視野，大家的工作和學習何嘗不是如此呢 ？！

審核編輯：郭婷