架構(gòu)

1. 什么是架構(gòu)？

關(guān)于架構(gòu)這個概念很難給出一個明確的定義，也沒有一個標準的定義。

硬是要給一個概述，我認為架構(gòu)就是對系統(tǒng)中的實體以及實體之間的關(guān)系所進行的抽象描述。

架構(gòu)始于建筑，是因為人類發(fā)展（原始人自給自足住在樹上，也就不需要架構(gòu)），分工協(xié)作的需要，將目標系統(tǒng)按某個原則進行切分，切分的原則，是要便于不同的角色進行并行工作。

2. 為什么需要架構(gòu)？

有系統(tǒng)的地方就需要架構(gòu)，大到航空飛機，小到一個電商系統(tǒng)里面的一個功能組件都需要設(shè)計和架構(gòu)。

我很喜歡《系統(tǒng)架構(gòu)：復(fù)雜系統(tǒng)的產(chǎn)品設(shè)計與開發(fā)》里面的一句話：結(jié)構(gòu)良好的創(chuàng)造活動要優(yōu)于毫無結(jié)構(gòu)的創(chuàng)造活動。

與之相對應(yīng)的，現(xiàn)在很多敏捷思想提倡 no design，只要 work 就好。期待好的架構(gòu)可以在迭代中自然涌現(xiàn)。這個想法有點太理想化了，在現(xiàn)實中，只要能 work 的代碼，工程師是很少有動力去重構(gòu)和優(yōu)化的。

3. 架構(gòu)師的職責(zé)

作為架構(gòu)師，我們最重要的價值應(yīng)該是“化繁為簡”。但凡讓事情變得更復(fù)雜，讓系統(tǒng)變得更晦澀難懂的架構(gòu)都是值得商榷的。

架構(gòu)師的工作就是要努力訓(xùn)練自己的思維，用它去理解復(fù)雜的系統(tǒng)，通過合理的分解和抽象，使哪些系統(tǒng)不再那么難懂。我們應(yīng)該努力構(gòu)建易懂的架構(gòu)，使得在系統(tǒng)上工作的其他人員（例如設(shè)計者、實現(xiàn)者、操作員等）可以較為容易地理解這個系統(tǒng)。

軟件架構(gòu)

軟件架構(gòu)是一個系統(tǒng)的草圖。軟件架構(gòu)描述的對象是直接構(gòu)成系統(tǒng)的抽象組件。各個組件之間的連接則明確和相對細致地描述組件之間的通信。在實現(xiàn)階段，這些抽象組件被細化為實際的組件，比如具體某個類或者對象。在面向?qū)ο箢I(lǐng)域中，組件之間的連接通常用接口來實現(xiàn)。

軟件架構(gòu)為軟件系統(tǒng)提供了一個結(jié)構(gòu)、行為和屬性的高級抽象，由構(gòu)件的描述、構(gòu)件的相互作用、指導(dǎo)構(gòu)件集成的模式以及這些模式的約束組成。軟件架構(gòu)不僅顯示了軟件需求和軟件結(jié)構(gòu)之間的對應(yīng)關(guān)系，而且指定了整個軟件系統(tǒng)的組織和拓撲結(jié)構(gòu)，提供了一些設(shè)計決策的基本原理。

軟件架構(gòu)的核心價值應(yīng)該只圍繞一個核心命題：控制復(fù)雜性。他并不意味著某個特定的分層結(jié)構(gòu)，某個特定的方法論（貧血、DDD 等）。

軟件架構(gòu)分類

在介紹應(yīng)用架構(gòu)之前，我們先來看一下軟件架構(gòu)的分類。

隨著互聯(lián)網(wǎng)的發(fā)展，現(xiàn)在的系統(tǒng)要支撐數(shù)億人同時在線購物、通信、娛樂的需要，相應(yīng)的軟件體系結(jié)構(gòu)也變得越來越復(fù)雜。軟件架構(gòu)的含義也變得更加寬泛，我們不能簡單地用一個軟件架構(gòu)來指代所有的軟件架構(gòu)工作。按照我個人理解，我將軟件架構(gòu)劃分為：

業(yè)務(wù)架構(gòu)：由業(yè)務(wù)架構(gòu)師負責(zé)，也可以稱為業(yè)務(wù)領(lǐng)域?qū)＜?、行業(yè)專家。業(yè)務(wù)架構(gòu)屬于頂層設(shè)計，其對業(yè)務(wù)的定義和劃分會影響組織結(jié)構(gòu)和技術(shù)架構(gòu)。例如，阿里巴巴在沒有中臺部門之前，每個業(yè)務(wù)部門的技術(shù)架構(gòu)都是煙囪式的，淘寶、天貓、飛豬、1688 等各有一套體系結(jié)構(gòu)。而后，成立了共享平臺事業(yè)部，打通了賬號、商品、訂單等體系，讓商業(yè)基礎(chǔ)實施的復(fù)用成為可能。

應(yīng)用架構(gòu)：由應(yīng)用架構(gòu)師負責(zé)，他需要根據(jù)業(yè)務(wù)場景的需要，設(shè)計應(yīng)用的層次結(jié)構(gòu)，制定應(yīng)用規(guī)范、定義接口和數(shù)據(jù)交互協(xié)議等。并盡量將應(yīng)用的復(fù)雜度控制在一個可以接受的水平，從而在快速的支撐業(yè)務(wù)發(fā)展的同時，在保證系統(tǒng)的可用性和可維護性的同時，確保應(yīng)用滿足非功能屬性要求（性能、安全、穩(wěn)定性等）。

分布式系統(tǒng)架構(gòu)：分布式系統(tǒng)基本是稍具規(guī)模業(yè)務(wù)的必選項。它需要解決服務(wù)器負載，分布式服務(wù)的注冊和發(fā)現(xiàn)，消息系統(tǒng)，緩存系統(tǒng)，分布式數(shù)據(jù)庫等問題，同時架構(gòu)師要在 CAP（Consistency，Availability，Partition tolerance）之間進行權(quán)衡。

數(shù)據(jù)架構(gòu)：對于規(guī)模大一些的公司，數(shù)據(jù)治理是一個很重要的課題。如何對數(shù)據(jù)收集、數(shù)據(jù)處理提供統(tǒng)一的服務(wù)和標準，是數(shù)據(jù)架構(gòu)需要關(guān)注的問題。其目的就是統(tǒng)一數(shù)據(jù)定義規(guī)范，標準化數(shù)據(jù)表達，形成有效易維護的數(shù)據(jù)資產(chǎn)，搭建統(tǒng)一的大數(shù)據(jù)處理平臺，形成數(shù)據(jù)使用閉環(huán)。

物理架構(gòu)：物理架構(gòu)關(guān)注軟件元件是如何放到硬件上的，包括機房搭建、網(wǎng)絡(luò)拓撲結(jié)構(gòu)，網(wǎng)絡(luò)分流器、代理服務(wù)器、Web 服務(wù)器、應(yīng)用服務(wù)器、報表服務(wù)器、整合服務(wù)器、存儲服務(wù)器和主機等。

運維架構(gòu)：負責(zé)運維系統(tǒng)的規(guī)劃、選型、部署上線，建立規(guī)范化的運維體系。

典型應(yīng)用架構(gòu)

1. 分層架構(gòu)

分層是一種常見的根據(jù)系統(tǒng)中的角色（職責(zé)拆分）和組織代碼單元的常規(guī)實踐。常見的分層結(jié)構(gòu)如下圖所示：

2. CQRS

CQS(Command Query Separation，命令查詢分離)，最早來自于 Betrand Meyer（Eiffel 語言之父，OCP 提出者）提出的概念。其基本思想在于，任何一個對象的方法可以分為兩大類：

命令(Command): 不返回任何結(jié)果(void)，但會改變對象的狀態(tài)。

查詢(Query): 返回結(jié)果，但是不會改變對象的狀態(tài)，對系統(tǒng)沒有副作用。

3. 六邊形架構(gòu)

六邊形架構(gòu)是 Alistair Cockburn 在 2005 年提出，解決了傳統(tǒng)的分層架構(gòu)所帶來的問題，實際上它也是一種分層架構(gòu)，只不過不是上下，而是變成了內(nèi)部和外部（如下圖所示）。

六邊形架構(gòu)又稱為端口-適配器架構(gòu)，這個名字更容器理解。六邊形架構(gòu)將系統(tǒng)分為內(nèi)部（內(nèi)部六邊形）和外部，內(nèi)部代表了應(yīng)用的業(yè)務(wù)邏輯，外部代表應(yīng)用的驅(qū)動邏輯、基礎(chǔ)設(shè)施或其他應(yīng)用。

適配器分為兩種類型（如下圖所示），左側(cè)代表 UI 的適配器被稱為主動適配器（Driving Adapters），因為是它們發(fā)起了對應(yīng)用的一些操作。而右側(cè)表示和后端工具鏈接的適配器，被稱為被動適配器（Driven Adapters），因為它們只會對主適配器的操作作出響應(yīng)。

4. 洋蔥圈架構(gòu)

洋蔥架構(gòu)與六邊形架構(gòu)有著相同的思路，它們都通過編寫適配器代碼將應(yīng)用核心從對基礎(chǔ)設(shè)施的關(guān)注中解放出來，避免基礎(chǔ)設(shè)施代碼滲透到應(yīng)用核心之中。這樣應(yīng)用使用的工具和傳達機制都可以輕松地替換，可以一定程度地避免技術(shù)、工具或者供應(yīng)商鎖定。

不同的是洋蔥架構(gòu)還告訴我們，企業(yè)應(yīng)用中存在著不止兩個層次，它在業(yè)務(wù)邏輯中加入了一些在領(lǐng)域驅(qū)動設(shè)計的過程中被識別出來的層次（Application，Domain Service，Domain model，Infrastructure 等）。

另外，它還有著脫離真實基礎(chǔ)設(shè)施和傳達機制應(yīng)用仍然可以運行的便利，這樣可以使用 mock 代替它們方便測試。

在洋蔥架構(gòu)中，明確規(guī)定了依賴的方向：

外層依賴內(nèi)層

內(nèi)層對外層無感知

COLA應(yīng)用架構(gòu)

COLA 架構(gòu)是我團隊自主研發(fā)的應(yīng)用架構(gòu)，目前已經(jīng)開源。在 COLA 的設(shè)計中，我們充分汲取了經(jīng)典架構(gòu)的優(yōu)秀思想。除此之外，我們補充了規(guī)范設(shè)計和擴展設(shè)計，并且使用 Archetype 的方式，將架構(gòu)固化下來，以便可以快速的在開發(fā)中使用。

COLA 開源地址：https://github.com/alibaba/COLA

1. 分層設(shè)計

COLA 的分層是一種改良了的三層架構(gòu)。主要是將傳統(tǒng)的業(yè)務(wù)邏輯層拆分成應(yīng)用層、領(lǐng)域?qū)雍突A(chǔ)實施層。如下圖所示，左邊是傳統(tǒng)的分層架構(gòu)，右邊是 COLA 的分層架構(gòu)。

其每一層的作用范圍和含義如下：

1）展現(xiàn)層（Presentation Layer）

負責(zé)以 Rest 的格式接受 Web 請求，然后將請求路由給 Application 層執(zhí)行，并返回視圖模型（View Model），其載體通常是 DTO（Data Transfer Object）。

2）應(yīng)用層（Application Layer）

主要負責(zé)獲取輸入，組裝上下文，做輸入校驗，調(diào)用領(lǐng)域?qū)幼鰳I(yè)務(wù)處理，如果需要的話，發(fā)送消息通知。當(dāng)然，層次是開放的，若有需要，應(yīng)用層也可以直接訪問基礎(chǔ)實施層。

3）領(lǐng)域?qū)樱―omain Layer）

主要是封裝了核心業(yè)務(wù)邏輯，并通過領(lǐng)域服務(wù)（Domain Service）和領(lǐng)域?qū)ο螅‥ntities）的函數(shù)對外部提供業(yè)務(wù)邏輯的計算和處理.

4）基礎(chǔ)實施層（Infrastructure Layer）

主要包含 Tunnel（數(shù)據(jù)通道）、Config 和 Common。這里我們使用 Tunnel 概念來對所有的數(shù)據(jù)來源進行抽象，這些數(shù)據(jù)來源可以是數(shù)據(jù)庫（MySQL，NoSql）、搜索引擎、文件系統(tǒng)、也可以是 SOA 服務(wù)等；Config 負責(zé)應(yīng)用的配置；Common 是通用的工具類。

2. 擴展設(shè)計

對于只有一個業(yè)務(wù)的簡單場景，對擴展性的要求并不突出，這也是為什么擴展設(shè)計常被忽略的原因，因為我們大部分的系統(tǒng)都是從單一業(yè)務(wù)開始的。但是隨著業(yè)務(wù)場景越來越復(fù)雜，代碼里面開始出現(xiàn)大量的 if-else 邏輯。此時除了常規(guī)的策略模式以外，我們可以考慮在架構(gòu)層面提供統(tǒng)一的擴展解決方案。

在擴展設(shè)計中，我們提煉出兩個重要的概念，一個是業(yè)務(wù)身份，另一個是擴展點。

業(yè)務(wù)身份是指業(yè)務(wù)在系統(tǒng)唯一標識一個業(yè)務(wù)或者一個場景的標志。在具體實現(xiàn)中，我們使用 BizCode 來表示業(yè)務(wù)身份，其中 BizCode 采用類似 Java 包名命名空間的方式。例如，我們可以用 “ali.tmall” 表示阿里天貓業(yè)務(wù)，用 “ali.tmall.car” 表示阿里天貓的汽車業(yè)務(wù)，而用 'ali.tmall.car.aftermarket' 代表這是阿里天貓的汽車業(yè)務(wù)的后市場場景。

每個業(yè)務(wù)或者場景都可以實現(xiàn)一個或多個擴展點（ExtensionPoint），也就是說一個業(yè)務(wù)身份加上一個擴展點，可以唯一地確定一個擴展實現(xiàn)（Extension）。而這個業(yè)務(wù)身份和擴展點的組合，我們將其稱之為擴展坐標（ExtensionCoordinate），如下圖所示。

這樣，通過業(yè)務(wù)身份+擴展點，我們就可以從框架層面實現(xiàn)對不同租戶，不同業(yè)務(wù)，不同場景的擴展定制了。整個阿里業(yè)務(wù)中臺正是基于這個思想，實現(xiàn)的多業(yè)務(wù)支撐的。

3. 規(guī)范設(shè)計

任何事物都是規(guī)則性和隨機性的組合。規(guī)范的意義就在于我們可以將規(guī)則性的東西固化下來，盡量減少隨心所欲帶來的復(fù)雜度，一致性可以降低系統(tǒng)復(fù)雜度。從命名到架構(gòu)皆是如此，而架構(gòu)本身就是一種規(guī)范和約束，破壞這個約束，也就破壞了架構(gòu)。

COLA 制定了一些列的規(guī)范：包括組件（Module）結(jié)構(gòu)、包（Package）結(jié)構(gòu)、命名等。

比如對于組件，我們要求使用 COLA 的應(yīng)用都應(yīng)該遵循如下圖所示的組件劃分：

4. COLA 架構(gòu)總覽

在架構(gòu)思想上，COLA 主張像六邊形架構(gòu)那樣，使用端口-適配器去解耦技術(shù)細節(jié)；主張像洋蔥圈架構(gòu)那樣，以領(lǐng)域為核心，并通過依賴倒置反轉(zhuǎn)領(lǐng)域?qū)拥囊蕾嚪较?。最終形成如下圖所示的組件關(guān)系。

換一個視角，從 COLA 應(yīng)用處理響應(yīng)一個請求的過程來看。COLA 使用了 CQRS 來分離命令和查詢的職責(zé)，使用擴展點和元數(shù)據(jù)來提升應(yīng)用的擴展性。整個處理流程如下圖所示：

應(yīng)用架構(gòu)的核心

縱觀上面介紹的所有應(yīng)用架構(gòu)，我們可以發(fā)現(xiàn)一個共同點，就是“核心業(yè)務(wù)邏輯和技術(shù)細節(jié)分離”。

是的，六邊形架構(gòu)、洋蔥圈架構(gòu)、以及 COLA 架構(gòu)的核心職責(zé)就是要做核心業(yè)務(wù)邏輯和技術(shù)細節(jié)的分離和解耦。

試想一下，業(yè)務(wù)邏輯和技術(shù)細節(jié)糅雜在一起的情況，所有的代碼都寫在 ServiceImpl 里面，前幾行代碼是做 validation 的事，接下來幾行是做 convert 的事，然后是幾行業(yè)務(wù)處理邏輯的代碼，穿插著，我們需要通過 RPC 或者 DAO 獲取更多的數(shù)據(jù)，拿到數(shù)據(jù)后，又是幾行 convert 的代碼，在接上一段業(yè)務(wù)邏輯代碼，然后還要落庫，發(fā)消息.....等等。

再簡單的業(yè)務(wù)，按照上面這種寫代碼的方式，都會變得復(fù)雜，難維護。

因此，我認為應(yīng)用架構(gòu)的核心使命就是要分離業(yè)務(wù)邏輯和技術(shù)細節(jié)。讓核心業(yè)務(wù)邏輯可以反映領(lǐng)域模型和領(lǐng)域應(yīng)用，可以復(fù)用，可以很容易被看懂。讓技術(shù)細節(jié)在輔助實現(xiàn)業(yè)務(wù)功能的同時，可以被替換。

最后我們發(fā)現(xiàn)，應(yīng)用架構(gòu)的道就是：讓上帝的歸上帝，凱撒的歸凱撒。

責(zé)任編輯：xj

原文標題：架構(gòu)設(shè)計：業(yè)務(wù)邏輯和技術(shù)分離

文章出處：【微信公眾號：嵌入式ARM】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。