![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/8f80513ecdbb45e68a54f14cdb60053b.png)

作者 | 張建飛  阿里巴巴高階技術專家

# 架構

## 什麼是架構？

關於架構這個概念很難給出一個明確的定義，也沒有一個標準的定義。

硬是要給一個概述，我認為**架構就是對系統中的實體以及實體之間的關係所進行的抽象描述。**

架構始於建築，是因為人類發展（原始人自給自足住在樹上，也就不需要架構），分工協作的需要，將目標系統按某個原則進行切分，切分的原則，是要便於不同的角色進行並行工作。

## 為什麼需要架構？

有系統的地方就需要架構，大到航空飛機，小到一個電商系統裡面的一個功能元件都需要設計和架構。

我很喜歡《系統架構：複雜系統的產品設計與開發》裡面的一句話：**結構良好的創造活動要優於毫無結構的創造活動**。

與之相對應的，現在很多敏捷思想提倡 no design，只要 work 就好。期待好的架構可以在迭代中自然湧現。這個想法有點太理想化了，在現實中，只要能 work 的程式碼，工程師是很少有動力去重構和最佳化的。

## 架構師的職責

作為架構師，我們最重要的價值應該是“化繁為簡”。但凡讓事情變得更復雜，讓系統變得更晦澀難懂的架構都是值得商榷的。

**架構師的工作就是要努力訓練自己的思維，用它去理解複雜的系統，透過合理的分解和抽象，使哪些系統不再那麼難懂**。我們應該努力構建易懂的架構，使得在系統上工作的其他人員（例如設計者、實現者、操作員等）可以較為容易地理解這個系統。

# 軟體架構

軟體架構是一個系統的草圖。軟體架構描述的物件是直接構成系統的抽象元件。各個元件之間的連線則明確和相對細緻地描述元件之間的通訊。在實現階段，這些抽象元件被細化為實際的元件，比如具體某個類或者物件。在物件導向領域中，元件之間的連線通常用介面來實現。

軟體架構為**軟體系統提供了一個結構、行為和屬性的高階抽象**，由構件的描述、構件的相互作用、指導構件整合的模式以及這些模式的約束組成。軟體架構不僅顯示了軟體需求和軟體結構之間的對應關係，而且指定了整個軟體系統的組織和拓撲結構，提供了一些設計決策的基本原理。

軟體架構的核心價值應該只圍繞一個核心命題：控制複雜性。他並不意味著某個特定的分層結構，某個特定的方法論（貧血、DDD 等）。

# 軟體架構分類

在介紹應用架構之前，我們先來看一下軟體架構的分類。

隨著網際網路的發展，現在的系統要支撐數億人同時線上購物、通訊、娛樂的需要，相應的軟體體系結構也變得越來越複雜。軟體架構的含義也變得更加寬泛，我們不能簡單地用一個軟體架構來指代所有的軟體架構工作。按照我個人理解，我將軟體架構劃分為：

![1.png](https://ucc.alicdn.com/pic/developer-ecology/92d81feb795d4a2980a336bf75f69ad3.png)

**業務架構**：由業務架構師負責，也可以稱為業務領域專家、行業專家。業務架構屬於頂層設計，其對業務的定義和劃分會影響組織結構和技術架構。例如，阿里巴巴在沒有中臺部門之前，每個業務部門的技術架構都是煙囪式的，淘寶、天貓、飛豬、1688 等各有一套體系結構。而後，成立了共享平臺事業部，打通了賬號、商品、訂單等體系，讓商業基礎實施的複用成為可能。

**應用架構**：由應用架構師負責，他需要根據業務場景的需要，設計應用的層次結構，制定應用規範、定義介面和資料互動協議等。並儘量將應用的複雜度控制在一個可以接受的水平，從而在快速的支撐業務發展的同時，在保證系統的可用性和可維護性的同時，確保應用滿足非功能屬性要求（效能、安全、穩定性等）。

**分散式系統架構**：分散式系統基本是稍具規模業務的必選項。它需要解決伺服器負載，分散式服務的註冊和發現，訊息系統，快取系統，分散式資料庫等問題，同時架構師要在 CAP（Consistency，Availability，Partition tolerance）之間進行權衡。

**資料架構**：對於規模大一些的公司，資料治理是一個很重要的課題。如何對資料收集、資料處理提供統一的服務和標準，是資料架構需要關注的問題。其目的就是統一資料定義規範，標準化資料表達，形成有效易維護的資料資產，搭建統一的大資料處理平臺，形成資料使用閉環。

**物理架構**：物理架構關注軟體元件是如何放到硬體上的，包括機房搭建、網路拓撲結構，網路分流器、代理伺服器、Web伺服器、應用伺服器、報表伺服器、整合伺服器、儲存伺服器和主機等。

**運維架構**：負責運維繫統的規劃、選型、部署上線，建立規範化的運維體系。

# 典型應用架構

## 分層架構

分層是一種常見的根據系統中的角色（職責拆分）和組織程式碼單元的常規實踐。常見的分層結構如下圖所示：

![2.png](https://ucc.alicdn.com/pic/developer-ecology/ec44c330d1b14865b7ec85721e44929e.png)

## CQRS

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

- 命令(Command): 不返回任何結果(void)，但會改變物件的狀態。
- 查詢(Query): 返回結果，但是不會改變物件的狀態，對系統沒有副作用。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/1e43abba869f43d99875288b80d8cbb9.png)

## 六邊形架構

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

![4.png](https://ucc.alicdn.com/pic/developer-ecology/a9d52a449e0944d58a97a7274502bb55.png)

六邊形架構又稱為埠-介面卡架構，這個名字更容器理解。六邊形架構將系統分為內部（內部六邊形）和外部，內部代表了應用的業務邏輯，外部代表應用的驅動邏輯、基礎設施或其他應用。

介面卡分為兩種型別（如下圖所示），左側代表 UI 的介面卡被稱為**主動介面卡（Driving Adapters）**，因為是它們發起了對應用的一些操作。而右側表示和後端工具連結的介面卡，被稱為**被動介面卡（Driven Adapters）**，因為它們只會對主介面卡的操作作出響應。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/27fd69e7191648a0a9ba69ce817ced23.png)

## 洋蔥圈架構

洋蔥架構與六邊形架構有著相同的思路，它們都透過編寫介面卡程式碼將應用核心從對基礎設施的關注中解放出來，避免基礎設施程式碼滲透到應用核心之中。這樣應用使用的工具和傳達機制都可以輕鬆地替換，可以一定程度地避免技術、工具或者供應商鎖定。

不同的是洋蔥架構還告訴我們，企業應用中存在著不止兩個層次，它在業務邏輯中加入了一些在領域驅動設計的過程中被識別出來的層次（Application，Domain Service，Domain model，Infrastructure等）。

另外，它還有著脫離真實基礎設施和傳達機制應用仍然可以執行的便利，這樣可以使用 mock 代替它們方便測試。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/96d43f532c0e405bbee1e160a7aa5e1c.png)

在洋蔥架構中，明確規定了依賴的方向：

- 外層依賴內層；
- 內層對外層無感知。

# COLA 應用架構

COLA 架構是我團隊自主研發的應用架構，目前已經開源。在 COLA 的設計中，我們充分汲取了經典架構的優秀思想。除此之外，我們補充了規範設計和擴充套件設計，並且使用 Archetype 的方式，將架構固化下來，以便可以快速的在開發中使用。

COLA 開源地址：[https://github.com/alibaba/COLA](https://github.com/alibaba/COLA)

## 分層設計

COLA 的分層是一種改良了的三層架構。主要是將傳統的業務邏輯層拆分成應用層、領域層和基礎實施層。如下圖所示，左邊是傳統的分層架構，右邊是 COLA 的分層架構。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/30c1ee0765be42fc8d9369d4cf7d41fa.png)

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

1）展現層（Presentation Layer）：負責以 Rest 的格式接受 Web 請求，然後將請求路由給 Application 層執行，並返回檢視模型（View Model），其載體通常是 DTO（Data Transfer Object）；

2）應用層（Application Layer）：主要負責獲取輸入，組裝上下文，做輸入校驗，呼叫領域層做業務處理，如果需要的話，傳送訊息通知。當然，層次是開放的，若有需要，應用層也可以直接訪問基礎實施層；

3）領域層（Domain Layer）：主要是封裝了核心業務邏輯，並透過領域服務（Domain Service）和領域物件（Entities）的函式對外部提供業務邏輯的計算和處理；

4）基礎實施層（Infrastructure Layer）主要包含 Tunnel（資料通道）、Config 和 Common。這裡我們使用 Tunnel 這個概念來對所有的資料來源進行抽象，這些資料來源可以是資料庫（MySQL，NoSql）、搜尋引擎、檔案系統、也可以是 SOA 服務等；Config 負責應用的配置；Common 是通用的工具類。

## 擴充套件設計

對於只有一個業務的簡單場景，對擴充套件性的要求並不突出，這也是為什麼擴充套件設計常被忽略的原因，因為我們大部分的系統都是從單一業務開始的。但是隨著業務場景越來越複雜，程式碼裡面開始出現大量的if-else邏輯。此時除了常規的策略模式以外，我們可以考慮在架構層面提供統一的擴充套件解決方案。

在擴充套件設計中，我們提煉出兩個重要的概念，一個是**業務身份**，另一個是**擴充套件點**。

**業務身份是指業務在系統唯一標識一個業務或者一個場景的標誌**。在具體實現中，我們使用 BizCode 來表示業務身份，其中 BizCode 採用類似 Java 包名名稱空間的方式。例如，我們可以用“ali.tmall”表示阿里天貓業務，用“ali.tmall.car” 表示阿里天貓的汽車業務，而用"ali.tmall.car.aftermarket"代表這是阿里天貓的汽車業務的後市場場景。

**每個業務或者場景都可以實現一個或多個擴充套件點（ExtensionPoint）**，也就是說一個業務身份加上一個擴充套件點，可以唯一地確定一個擴充套件實現（Extension）。而這個業務身份和擴充套件點的組合，我們將其稱之為擴充套件座標（ExtensionCoordinate），如下圖所示。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/810581d817914fde8e39f626ccdd2bbc.png)

這樣，透過業務身份+擴充套件點，我們就可以從框架層面實現對不同租戶，不同業務，不同場景的擴充套件定製了。整個阿里業務中臺正是基於這個思想，實現的多業務支撐的。

## 規範設計

任何事物都是規則性和隨機性的組合。規範的意義就在於我們可以將規則性的東西固化下來，儘量減少隨心所欲帶來的複雜度，一致性可以降低系統複雜度。從命名到架構皆是如此，而架構本身就是一種規範和約束，破壞這個約束，也就破壞了架構。

COLA 制定了一些列的規範：包括元件（Module）結構、包（Package）結構、命名等。

比如對於元件，我們要求使用 COLA 的應用都應該遵循如下圖所示的元件劃分：

![9.png](https://ucc.alicdn.com/pic/developer-ecology/ac4ebbb487324798a2868159942f0462.png)

## COLA 架構總覽

在架構思想上，COLA 主張像六邊形架構那樣，使用埠-介面卡去解耦技術細節；主張像洋蔥圈架構那樣，以領域為核心，並透過依賴倒置反轉領域層的依賴方向。最終形成如下圖所示的元件關係。

![10.png](https://ucc.alicdn.com/pic/developer-ecology/2c169144a35f49e085a1c234b109e74c.png)

換一個視角，從 COLA 應用處理響應一個請求的過程來看。COLA 使用了 CQRS 來分離命令和查詢的職責，使用擴充套件點和後設資料來提升應用的擴充套件性。整個處理流程如下圖所示：

![11.png](https://ucc.alicdn.com/pic/developer-ecology/62255038f9e24f29ab16f7daea3be682.png)

# 應用架構的核心

縱觀上面介紹的所有應用架構，我們可以發現一個共同點，就是“**核心業務邏輯和技術細節分離**”。

![12.png](https://ucc.alicdn.com/pic/developer-ecology/5f4b82a2c7d5449e8770f6f558cef2fb.png)

是的，六邊形架構、洋蔥圈架構、以及 COLA 架構的核心職責就是要做核心業務邏輯和技術細節的分離和解耦。

試想一下，業務邏輯和技術細節糅雜在一起的情況，所有的程式碼都寫在 ServiceImpl 裡面，前幾行程式碼是做 validation 的事，接下來幾行是做 convert 的事，然後是幾行業務處理邏輯的程式碼，穿插著，我們需要透過 RPC 或者 DAO 獲取更多的資料，拿到資料後，又是幾行 convert 的程式碼，在接上一段業務邏輯程式碼，然後還要落庫，發訊息.....等等。

再簡單的業務，按照上面這種寫程式碼的方式，都會變得複雜，難維護。

因此，我認為應用架構的核心使命就是要分離業務邏輯和技術細節。讓核心業務邏輯可以反映領域模型和領域應用，可以複用，可以很容易被看懂。讓技術細節在輔助實現業務功能的同時，可以被替換。

最後我們發現，應用架構的道就是：“**讓上帝的歸上帝，凱撒的歸凱撒**。”

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247495124&idx=1&sn=bbec0784ce1de25c09810cb65655a6ef&chksm=fae6e61bcd916f0d465a6eda68726fd98f620a9fec54ae58d59db48d73657aaa4bf329e065e2&token=1765928011&lang=zh_CN#rd)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

應用架構之道：分離業務邏輯和技術細節

相關文章