張建飛技術瑣話

前幾天和幾個餓了么的同學聊天，一聽說他們還在用COLA 1.0，我二話沒說，90度鞠躬，賠禮道歉，虛心聆聽他們的吐槽。COLA的初衷旨在控制復雜度，救碼農于水火，慚愧的是，早期的思想不成熟，設計也多有缺陷，不僅沒幫到他們，反而坑了他們，實在抱歉。

實際上，我在COLA 3.0迭代的時候，已經舉起奧卡姆剃刀，砍掉了很多東西。

然而還不夠，主要體現在對架構的思考還不夠透徹。再三考量，我覺得有必要對COLA進行一次重新梳理，回歸初心，讓COLA真正成為應用架構的最佳實踐，幫助廣大的業務技術同學，脫離醬缸代碼的泥潭！

應用架構的本質

什么是架構？十個人可能有十個回答，架構在技術的語境下，就和架構師一樣魔幻。我曾經看過一本技術書，用了一章的篇幅討論架構的定義，最終也沒有說明白。

實際上，定義架構也沒那么難，如下圖所示，架構的本質，簡單來說，就是要素結構。所謂的要素（Components）是指架構中的主要元素，結構是指要素之間的相互關系（Relationship）。

例如組織架構，其要素是什么？組成組織的要素當然是人，結構呢？結構是人與人之間的關系。因此，組織架構就是關于定義人的職責劃分，以及人與人之間協作關系的一種設計方法。

同樣，對于應用架構而言，代碼是其核心組成要素，結構就是這些代碼該如何被組織，也就是要如何處理模塊（Module）、組件（Component）、包（Package）和類（Class）之間的關系。簡而言之，應用架構就是要解決代碼要如何被組織的問題。

一個沒有架構的應用系統，就像一堆隨意堆放、雜亂無章的玩具，只有熵值，沒有熵減。而一個有良好架構的應用系統，有章法、有結構，一切都顯得井井有條。

好的組織架構會遵循一定的架構模式，大部分的組織都會按職能和業務來設計自己的架構。如果你反其道而行之，硬要把銷售、財務和技術人員放在一個部門，就會顯得很奇怪。

同樣，好的應用架構，也遵循一些共同模式，不管是六邊形架構、洋蔥圈架構、整潔架構、還是COLA架構，都提倡以業務為核心，解耦外部依賴，分離業務復雜度和技術復雜度。

應用架構的本質，就是要從繁雜的業務系統中提煉出共性，找到解決業務問題的最佳共同模式，為開發人員提供統一的認知，治理混亂。幫助應用系統“從混亂到有序”，COLA架構就是為此而生，其核心職責就是定義良好的應用結構，提供最佳實踐。

COLA 架構

自從COLA誕生以來，已經被使用在很多的業務系統里面，有CRM的業務，有電商的業務，有物流的業務，有外賣業務，有排課系統…. COLA作為應用架構，有一定的普適性，是因為業務問題都有一定的共性。例如，典型的業務系統都需要：

• 接收request，響應response；

• 做業務邏輯處理，像校驗參數，狀態流轉，業務計算等等；

• 和外部系統有聯動，像數據庫，微服務，搜索引擎等；

正是有這樣的共性存在，才會有很多普適的架構思想出現，比如分層架構、六邊形架構、洋蔥圈架構、整潔架構（Clean Architecture）、DDD架構等等。

這些應用架構思想雖然很好，但我們很多同學還是“不講Co德，明白了很多道理，可還是過不好這一生”。問題就在于缺乏實踐和指導。COLA的意義就在于，他不僅是思想，還提供了可落地的實踐。應該是為數不多的應用架構層面的開源軟件。

分層結構

假如你是一個公司的CTO要管100號人，你怎么管？按照管理學的定義，一個人的管理幅度如果超過10個，管理就會變得很困難。因此，管100號人，你可以把他們分成10個小組，這樣你管理10個小組長就好了。

所有的復雜系統都會呈現出層級結構，管理如此，軟件設計也不例外，你能想象如果網絡協議不是四層，而是一層，意味著，你要在應用層去處理鏈路層的bit數據流會是怎樣的情景嗎？同樣，應用系統處理復雜業務邏輯也應該是分層的，下層對上層屏蔽處理細節，每一層各司其職，分離關注點，而不是一個ServiceImpl解決所有問題。

對于一個典型的業務應用系統來說，COLA會做如下層次定義，每一層都有明確的職責定義：

1）適配層（Adapter Layer）：負責對前端展示（web，wireless，wap）的路由和適配，對于傳統B/S系統而言，adapter就相當于MVC中的controller；

2）應用層（Application Layer）：主要負責獲取輸入，組裝上下文，參數校驗，調用領域層做業務處理，如果需要的話，發送消息通知等。層次是開放的，應用層也可以繞過領域層，直接訪問基礎實施層；

3）領域層（Domain Layer）：主要是封裝了核心業務邏輯，并通過領域服務（Domain Service）和領域對象（Domain Entity）的方法對App層提供業務實體和業務邏輯計算。領域是應用的核心，不依賴任何其他層次；

4）基礎實施層（Infrastructure Layer）：主要負責技術細節問題的處理，比如數據庫的CRUD、搜索引擎、文件系統、分布式服務的RPC等。此外，領域防腐的重任也落在這里，外部依賴需要通過gateway的轉義處理，才能被上面的App層和Domain層使用。

包結構

分層是屬于大粒度的職責劃分，太粗，我們有必要往下再down一層，細化到包結構的粒度，才能更好的指導我們的工作。

還是拿一堆玩具舉例子，分層類似于拿來了一個架子，分包類似于在每一層架子上又放置了多個收納盒。所謂的內聚，就是把功能類似的玩具放在一個盒子里，這樣可以讓應用結構清晰，極大的降低系統的認知成本和維護成本。

那么，對于一個后端應用來說，應該需要哪些收納盒呢？這一塊的設計真可謂是費了老鼻子勁了，基本上每一次COLA的迭代都會涉及到包結構的調整，迭代到現在，才算基本穩定下來。

各個包結構的簡要功能描述，如下表所示：

層次

包名

功能

必選

Adapter層

web

處理頁面請求的Controller

否

Adapter層

wireless

處理無線端的適配

否

Adapter層

wap

處理wap端的適配

否

App層

executor

處理request，包括command和query

是

App層

consumer

處理外部message

否

App層

scheduler

處理定時任務

否

Domain層

model

領域模型

否

Domain層

ability

領域能力，包括DomainService

否

Domain層

gateway

領域網關，解耦利器

是

Infra層

gatewayimpl

網關實現

是

Infra層

mapper

ibatis數據庫映射

否

Infra層

config

配置信息

否

Client SDK

api

服務對外透出的API

是

Client SDK

dto

服務對外的DTO

是

你可能會有疑問，為什么Domain的model是可選的？因為COLA是應用架構，不是DDD架構。在工作中，很多同學問我領域模型要怎么設計，我的回答通常是：無有必要勿增實體。領域模型對設計能力要求很高，沒把握用好，一個錯誤的抽象還不如不抽象，寧可不要用，也不要濫用，不要為了DDD而DDD。

問題的關鍵是要看，新增的模型沒有給你帶來收益。比如有沒有幫助系統解耦，有沒有提升業務語義表達能力的提升，有沒有提升系統的可維護性和可測性等等。

模型雖然可選，但DDD的思想是一定要去學習和貫徹的，特別是統一語言、邊界上下文、防腐層的思想，值得深入學習，仔細體會。實際上，COLA里面的很多設計思想都來自于DDD。其中就包括領域包的設計。

前面的包定義，都是功能維度的定義。為了兼顧領域維度的內聚性，我們有必要對包結構進行一下微調，即頂層包結構應該是按照領域劃分，讓領域內聚。

也就是說，我們要綜合考慮功能和領域兩個維度包結構定義。按照領域和功能兩個維度分包策略，最后呈現出來的，是如下圖所示的頂層包節點是領域名稱，領域之下，再按功能劃分包結構。

例如，在我們剛剛上線的一個云店鋪（cloudstore）項目中，按照COLA的分包策略，我們在每一個module下面首先按照領域做一個頂層劃分，然后在領域內，再按照功能進行分包。

解耦

“高內聚，低耦合”這句話，你工作的越久，就越會覺得其有道理。

所謂耦合就是聯系的緊密程度，只要有依賴就會有耦合，不管是進程內的依賴，還是跨進程的RPC依賴，都會產生耦合。依賴不可消除，同樣，耦合也不可避免。我們所能做的不是消除耦合，而是把耦合降低到可以接受的程度。在軟件設計中，有大量的設計模式，設計原則都是為了解耦這一目的。

在DDD中有一個很棒的解耦設計思想——防腐層（Anti-Corruption），簡單說，就是應用不要直接依賴外域的信息，要把外域的信息轉換成自己領域上下文（Context）的實體再去使用，從而實現本域和外部依賴的解耦。

在COLA中，我們把AC這個概念進行了泛化，將數據庫、搜索引擎等數據存儲都列為外部依賴的范疇。利用依賴倒置，統一使用gateway來實現業務領域和外部依賴的解耦。

其實現方式如下圖所示，主要是在Domain層定義Gateway接口，然后在Infrastructure提供Gateway接口的實現。

舉個例子，假如有一個電商系統，對于下單這個操作，它需要聯動訂單服務、商品服務、庫存服務、營銷服務等多個系統才能完成。

那么在訂單域，該如何獲取商品和庫存信息呢？最直接的方式，無外乎就是RPC調用商品和庫存服務，拿到DTO直接使用就完了。

然而，商品域吐出的是一個大而全的DTO（可能包含幾十個字段），而在下單這個階段，訂單所需要的可能只是其中幾個字段而已。更合適的做法，應該是在訂單域中，使用gateway對商品域和庫存域的依賴進行解耦。

這樣做有兩個好處，一個是降低了對外域信息依賴的耦合；另一個是通過上下文映射（Context mapping），確保本領域邊界上下文（Bounded context）下領域知識的完整性，實現了統一語言（Ubiquitous language）。

COLA Archetype

以上就是COLA架構的核心內容了。然而這么多module，這么多package，如果要手動去創建的話，是非常繁瑣和費時的。為了能夠快速創建滿足COLA架構的應用，我創建了兩個Maven Archetype。

1. 一個是用來創建純后端服務的archetype：cola-archetype-service。

2. 一個是用來創建adapter和后端服務一體的web應用archetype：cola-archetype-web。

另外，你也可以使用阿里云的應用生成器去生成一個COLA應用，只是那邊的版本沒有同步更新，可能會老舊一點。

COLA組件

使用過老版本COLA的同學，應該知道，COLA除了架構之外，還提供了一些框架級別的功能，比如攔截器功能，擴展點功能等。

之前，這種框架功能和架構混淆在一起，會讓人以為使用COLA，就必須要使用這些功能。實際上二者是可以分開使用的，也就是說，你可以單純的使用COLA架構，而不使用任何COLA組件提供的功能也是完全沒問題的。

當然，我還是強烈推薦你可以有選擇的使用這些COLA組件，畢竟這些組件都是我們在實際工作中的總結沉淀，其復用性和價值是被反復驗證過的。

為了方便管理，以及更清晰的把架構和框架區分開來。在此次COLA 4.0的升級中，我把這些功能組件全部收攏到了cola-components下面。到目前為止，我們已經沉淀了以下組件：

組件名稱

功能

版本

依賴

cola-component-dto

定義了DTO格式，包括分頁

1.0.0

無

cola-component-exception

定義了異常格式，主要有BizException和SysException

1.0.0

無

cola-component-statemachine

狀態機組件

1.0.0

無

cola-component-domain-starter

Spring托管的領域實體組件

1.0.0

無

cola-component-catchlog-starter

異常處理和日志組件

1.0.0

exception,dto組件

cola-component-extension-starter

擴展點組件

1.0.0

無

cola-component-test-container

測試容器組件

1.0.0

無

這些組件是一個良好的開端，我相信，在未來會有更多有用的組件加入。當然，作為一個開源項目，如果你有好的組件idea，歡迎你隨時為這個組件庫添磚加瓦。

COLA 4.0

總結一下，在本次COLA升級中，我們進一步明確了架構和框架功能的定義。升級之后，如下圖所示，COLA會被分成COLA架構和COLA組件兩個部分：

1. COLA架構：關注應用架構的定義和構建，提升應用質量。

2. COLA組件：提供應用開發所需要的可復用組件，提升研發效率。

image.png

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

你可以按照以下步驟去使用COLA：

** 第一步：安裝 cola archetype ** 下載cola-archetypes下的源碼到本地，然后本地運行mvn install安裝。

** 第二步：安裝 cola components ** 下載cola-components下的源碼到本地，然后本地運行mvn install安裝。

** 第三步：創建應用 ** 執行以下命令：

mvn archetype:generate -DgroupId=com.alibaba.demo -DartifactId=demoWeb -Dversion=1.0.0-SNAPSHOT -Dpackage=com.alibaba.demo -DarchetypeArtifactId=cola-framework-archetype-web -DarchetypeGroupId=com.alibaba.cola -DarchetypeVersion=4.0.0

命令執行成功的話，會看到如下的應用代碼結構：