架構

1. 什么是架構？

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

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

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

2. 為什么需要架構？

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

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

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

3. 架構師的職責

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

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

軟件架構

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

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

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

軟件架構分類

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

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

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

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

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

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

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

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

典型應用架構

1. 分層架構

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

2. CQRS

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

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

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

3. 六邊形架構

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

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

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

4. 洋蔥圈架構

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

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

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

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

• 外層依賴內層

• 內層對外層無感知

COLA?應用架構

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

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

1. 分層設計

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

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

1）展現層（Presentation Layer）

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

2）應用層（Application Layer）

主要負責獲取輸入，組裝上下文，做輸入校驗，調用領域層做業(yè)務處理，如果需要的話，發(fā)送消息通知。當然，層次是開放的，若有需要，應用層也可以直接訪問基礎實施層。

3）領域層（Domain Layer）

主要是封裝了核心業(yè)務邏輯，并通過領域服務（Domain Service）和領域對象（Entities）的函數對外部提供業(yè)務邏輯的計算和處理.

4）基礎實施層（Infrastructure Layer）

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

2. 擴展設計

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

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

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

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

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

3. 規(guī)范設計

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

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

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

4. COLA 架構總覽

在架構思想上，COLA 主張像六邊形架構那樣，使用端口-適配器去解耦技術細節(jié)；主張像洋蔥圈架構那樣，以領域為核心，并通過依賴倒置反轉領域層的依賴方向。最終形成如下圖所示的組件關系。

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

應用架構的核心

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

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

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

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

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

最后我們發(fā)現，應用架構的道就是：讓上帝的歸上帝，凱撒的歸凱撒。

-END-

來源 | 未來技術研究院

|?整理文章為傳播相關技術，版權歸原作者所有?|

|?如有侵權，請聯(lián)系刪除?|

【1】超長干貨為你解析：從串口驅動到Linux驅動模型，嵌入式必會！

【2】超全！嵌入式必懂的CAN總線一文講通了

【3】干貨：嵌入式系統(tǒng)設計開發(fā)大全?。ㄈf字總結）

【4】嵌入式系統(tǒng)求職回憶錄：廣嵌、邁瑞、華為、智光……

【5】嵌入式行業(yè)真的沒有前途嗎？

---