![](https://s4.51cto.com/images/blog/202007/09/88bf8b7cd6195492fae5e128f9bc91ed.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)

**導讀：**COLA 的主要目的是為應用架構提供一套簡單的可以複製、可以理解、可以落地、可以控制複雜性的”指導和約束"。在實踐中作者發現 COLA 在簡潔性上仍有不足，因此給 COLA 做了一次“升級”，在這次升級中，沒有增加任何新的功能，而是儘量多刪減了一些概念和功能，讓 COLA 更簡潔有效。

最近，同事告訴我，COLA 作為應用架構，已經被選入阿里雲的 Java 應用初始化的應用架構選項之一。

![](https://s4.51cto.com/images/blog/202007/09/4e9174da1d0140e7b5579bf8bd06118f.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)

This is really something，於是，在這個里程碑節點上，我開始回過頭來，重新審視 COLA 一路走來的得與失。

COLA 作為一種架構思想無疑是成功的。但是作為框架，個人感覺有點雞肋之嫌。特別是在簡潔性上做的不好，感覺做了不少畫蛇添足的事情。

試想一下，有些功能我作為作者都很少去使用，我實在想不到，它為什麼還有存在的理由。

基於上面的思考，我做了這一次 COLA 2.0 到 COLA 3.0 的升級。在本次升級中，我沒有增加任何新的功能，而是儘量多刪減了一些概念和功能。讓 COLA 可以更加純粹的 focus 在應用架構上，而不是框架支援和架構約束上。

支援我做這些決策的背後原因只有一個——奧卡姆剃刀原理。

# 奧卡姆剃刀原理

奧卡姆剃刀原理，是指如無必要，勿增實體（Entities should not be multiplied unnecessarily），即“簡單有效原理”。正如奧卡姆在《箴言書注》2 卷 15 題說“切勿浪費較多東西去做，用較少的東西，同樣可以做好的事情。”

在具體的應用過程中，我們可以遵循以下原則去做事情：

“如果同一個現象有 n 種理論，最簡單的那個便是最正確的。能用 n 做好事情，那就不要有第 n+1 個動作。”

比如，《皇帝的新衣》的皇帝到底穿沒穿衣服呢？如果你在現場，你很有可能就是大臣之一。

如果懂得了奧卡姆剃刀原理，可以用邏輯手段，判斷誰是真理。

- 第一種邏輯如下：假設皇帝是真的穿了衣服→假設愚蠢的人看不見→假設你就是愚蠢的人→所以你沒看見皇帝穿衣服；

- 第二種邏輯如下：假設皇帝沒穿衣服→所以你沒看見皇帝穿衣服。

同樣看見光身子的皇帝，第二種解釋簡單明瞭。而第一種解釋，可能正因為它是錯誤的，就需要更多假設來補救漏洞，就像說謊圓謊一樣。

真相不需要偽裝掩飾，簡單明瞭。

再比如，地心說和日心說，托勒密的地心說模型是一個本輪均輪模型。人們可以按照這個模型，定量計算行星的運動，據此推測行星所在的位置。

到了中世紀後期隨著觀察儀器的不斷改進，人們能夠更加精確地測量出行星的位置和運動，觀測到行星實際位置與這個模型的計算結果存在偏差，一開始還能勉強應付，後來小本輪增加到八十多個，卻仍然不能精確地計算出行星的準確位置。

1543 年，波蘭天文學家哥白尼在臨終時發表了一部具有歷史意義的著作——《天體執行論》。這個理論體系提出了一個明確的觀點：太陽是宇宙的中心，一切行星都在圍繞太陽旋轉。該理論認為，地球也是行星之一，它一方面像陀螺一樣自轉，一方面又和其他行星一樣圍繞太陽轉動。

![](https://s4.51cto.com/images/blog/202007/09/50a52a6fed167afa086fe317acac13fb.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)

哥白尼的計算不僅結構嚴謹，而且計算簡單，與已經加到八十餘個圈的地心說相比，哥白尼的計算與實際觀測資料能更好地吻合。因此，地心說最終被日心說所取代。

# 設計中的彎彎繞

深入考察一下，我們系統中，類似於“地心說”這樣的彎彎繞的設計，實在是不在少數。

從系統架構的角度看，有些彎彎繞是因為系統邊界劃分不合理，導致職責不清，依賴混亂。

從應用架構的角度看，有些彎彎繞是因為過度設計，為了追求所謂的靈活性和可擴充套件性，使用了不恰當的設計。導致本來可以直觀呈現的程式碼邏輯，被各種包裝，各種隱藏，各種轉發.... 無形中極大的阻礙了程式碼的可讀性和可理解性，增加了維護成本。

舉個例子，我看過無數的業務系統，喜歡拿業務流程編排說事情。因此，在業務系統中，可以看到各種五花八門的“彎彎繞設計”。

比如，在一個業務系統中，我看到了如下的 pipeline 設計。這個設計的本質是說把一個複雜的業務操作進行結構化拆解為多個小的處理單元。

![](https://s4.51cto.com/images/blog/202007/09/170d56ae8fae83640aa2e3a533e628dd.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)

拆解是正確的，但是這種處理方式顯然不夠“奧卡姆”（關於更多結構化分解的內容，可以看我的另一篇文章：[如何寫複雜業務程式碼？](http://mp.weixin.qq.com/s?__biz=MzIzOTU0NTQ0MA==&mid=2247491068&idx=1&sn=2e724face6f7e1df5e81c377c84862a6&chksm=e92920f3de5ea9e574cdc9b183e837aab9eb032694d44f44c61b4637d8e477e0c0de831f7f51&scene=21#wechat_redirect)）。作為維護人員，進入“入口函式”後，還要去查資料庫，然後才能知道哪些元件被呼叫了，太繞了，不夠直觀，也不簡潔。

同樣的邏輯，按照下面的方式寫不香嗎？

```
public class CreateCSPUExecutor {
    @Resource
    private InitContextStep initContextStep;
    @Resource
    private CheckRequiredParamStep checkRequiredParamStep;
    @Resource
    private CheckUnitStep checkUnitStep;
    @Resource
    private CheckExpiringDateStep checkExpiringDateStep;
    @Resource
    private CheckBarCodeStep checkBarCodeStep;
    @Resource
    private CheckBarCodeImgStep checkBarCodeImgStep;
    @Resource
    private CheckBrandCategoryStep checkBrandCategoryStep;
    @Resource
    private CheckProductDetailStep checkProductDetailStep;
    @Resource
    private CheckSpecImgStep checkSpecImgStep;
    @Resource
    private CreateCSPUStep createCSPUStep;
    @Resource
    private CreateCSPULogStep createCSPULogStep;
    @Resource
    private SendCSPUCreatedEventStep sendCSPUCreatedEventStep;
    public Long create(MyCspuSaveParam myCspuSaveParam){
        SaveCSPUContext context = initContextStep.initContext(myCspuSaveParam);
        checkRequiredParamStep.check(context);
        checkUnitStep.check(context);
        checkExpiringDateStep.check(context);
        checkBarCodeStep.check(context);
        checkBarCodeImgStep.check(context);
        checkBrandCategoryStep.check(context);
        checkProductDetailStep.check(context);
        checkSpecImgStep.check(context);
        createCSPUStep.create(context);
        createCSPULogStep.log(context);
        sendCSPUCreatedEventStep.sendEvent(context);
        return context.getCspu().getId();
    }
}
```

```
public class CreateCSPUExecutor {
    @Resource
    private InitContextStep initContextStep;

@Resource
    private CheckRequiredParamStep checkRequiredParamStep;

@Resource
    private CheckUnitStep checkUnitStep;

@Resource
    private CheckExpiringDateStep checkExpiringDateStep;

@Resource
    private CheckBarCodeStep checkBarCodeStep;

@Resource
    private CheckBarCodeImgStep checkBarCodeImgStep;

@Resource
    private CheckBrandCategoryStep checkBrandCategoryStep;

@Resource
    private CheckProductDetailStep checkProductDetailStep;

@Resource
    private CheckSpecImgStep checkSpecImgStep;

@Resource
    private CreateCSPUStep createCSPUStep;

@Resource
    private CreateCSPULogStep createCSPULogStep;

@Resource
    private SendCSPUCreatedEventStep sendCSPUCreatedEventStep;

public Long create(MyCspuSaveParam myCspuSaveParam){
        SaveCSPUContext context = initContextStep.initContext(myCspuSaveParam);

checkRequiredParamStep.check(context);

checkUnitStep.check(context);

checkExpiringDateStep.check(context);

checkBarCodeStep.check(context);

checkBarCodeImgStep.check(context);

checkBrandCategoryStep.check(context);

checkProductDetailStep.check(context);

checkSpecImgStep.check(context);

createCSPUStep.create(context);

createCSPULogStep.log(context);

sendCSPUCreatedEventStep.sendEvent(context);

return context.getCspu().getId();
    }
}
```

這種寫法簡單直觀，易維護，與前一種方式相比，具有同樣的元件複用性。符合奧卡姆剃刀的精神，相比較而言，前面那種彎彎繞設計，雖然看起來有點設計感，帶來了一點點 OCP 的好處。但是無端增加了理解和認知成本，孰優孰劣，不難分辨。

# COLA 3.0 升級

做了這麼長的鋪墊，終於到了批鬥 COLA 中“彎彎繞設計”的時候了。

## 1. 去掉 Command

在 COLA 的初始階段，因為受到 CQRS 的影響，於是想到了使用命令模式來處理使用者請求。設計的初衷是想透過框架，一方面強制約束 Command 和 Query 的處理方式，另一方面把 Service 裡面的邏輯，強制拆分到 CommandExecutor 中去，防止 Service 膨脹過快。

和上面介紹過的 pipeline 設計類似，這種設計有點繞，不夠直觀，如下所示：

```
public class MetricsServiceImpl implements MetricsServiceI{

@Autowired
    private CommandBusI commandBus;

@Override
    public Response addATAMetric(ATAMetricAddCmd cmd) {
        return commandBus.send(cmd);
    }

@Override
    public Response addSharingMetric(SharingMetricAddCmd cmd) {
        return commandBus.send(cmd);
    }

@Override
    public Response addPatentMetric(PatentMetricAddCmd cmd) {
        return  commandBus.send(cmd);
    }

@Override
    public Response addPaperMetric(PaperMetricAddCmd cmd) {
        return  commandBus.send(cmd);
    }
}
```

看起來還挺乾淨的，可是 ATAMetricAddCmd 到底是被哪個 Executor 處理的呢，不直觀。我還要去理解 CommandBus，以及 CommandBus 是如何註冊 Executor 的。無形中增加了認知成本，不好。

既然這樣，為何不用奧卡姆剃刀把這個 CommandBus 剔除呢。如下所示，去除 CommandBus 之後，程式碼是不是直觀了很多，唯一的損失是我們會失去框架層面提供的 Interceptor 功能，然而，Interceptor 正是我下一個要動刀的地方。

```
public class MetricsServiceImpl implements MetricsServiceI{

@Resource
    private ATAMetricAddCmdExe ataMetricAddCmdExe;
    @Resource
    private SharingMetricAddCmdExe sharingMetricAddCmdExe;
    @Resource
    private PatentMetricAddCmdExe patentMetricAddCmdExe;
    @Resource
    private PaperMetricAddCmdExe paperMetricAddCmdExe;

@Override
    public Response addATAMetric(ATAMetricAddCmd cmd) {
        return ataMetricAddCmdExe.execute(cmd);
    }

@Override
    public Response addSharingMetric(SharingMetricAddCmd cmd) {
        return sharingMetricAddCmdExe.execute(cmd);
    }

@Override
    public Response addPatentMetric(PatentMetricAddCmd cmd) {
        return  patentMetricAddCmdExe.execute(cmd);
    }

@Override
    public Response addPaperMetric(PaperMetricAddCmd cmd) {
        return  paperMetricAddCmdExe.execute(cmd);
    }
}
```

## 2. 去掉 Interceptor

當時設計 Interceptor，是因為有 CommandBus 作為基礎，為了更好的利用命令模式帶來的好處，便新增了 Interceptor 功能。其本質是一個 AOP 處理。

鑑於 Spring 的 AOP 功能已經很完善了，這個設計也是有點雞肋。事實證明，大家在使用 COLA 框架的時候，很少會使用 Interceptor，包括我自己也是一樣。既然如此，剔除也罷。

## 3. 去掉 Convertor、Validator、Assembler

關於命名的重要性，這裡就不贅述了。當時想著是否能從框架層面，規範一下一些常用功能的命名。但是在實際使用中，發現這個想法也是有些過於理想化了。

我記得，在團隊實踐 COLA 的初期，還經常為什麼是 Convertor（轉換器），什麼是 Assembler（組裝器）的事情，爭論不休。

後面我仔細想了想，命名雖然很重要，但其作用域最多也就是一個團隊規範，你校驗器是叫 Validator 還是 Checker 並沒有什麼本質區別，團隊自己定義就好了。嘗試從框架層面去解決團隊約定問題，其效果不會太好，因此也果斷揮刀剔除。

## 4. 類掃描最佳化

業務身份和擴充套件點的思想，是 TMF 的核心理念，也是阿里業務中臺的進行多業務支援的核心方法論。

COLA 致力於提供一種輕量級的擴充套件實現方式，因此該功能在奧卡姆的屠刀下得以儲存。因為 COLA 的擴充套件點設計是借鑑了中臺的 TMF，因此在前面的設計中，其類掃描方案是直接照搬 TMF 的做法。

實際上，TMF 的類掃描方案對 COLA 來說有點多餘。因為 COLA 本身就是架設在 Spring 的基礎之上，而 Spring 又是建立在類掃描的基礎之上。因此，我們完全可以複用 Spring 的類掃描，沒必要自己寫一套。

在原生的 Spring 中，至少有 3 種方式可以獲取到使用者自定義 Annotation 的 Bean，最簡潔的是透過 ListableBeanFactory.getBeansWithAnnotation 方法，或者使用 ClassPathScanningCandidateComponentProvider 進行掃包。

在這次改版中，我選用的是 getBeansWithAnnotation 方法，主要是為了獲取 @Extension 的 Bean，用來實現擴充套件點功能，廢棄了原來的 TMF 類掃描實現。

# 總結

觸發這次升級的動機，主要是因為，自己在實踐 COLA 的過程中，的確發現有些華而不實的功能。在 COLA 作為阿里雲的基礎應用架構，其影響力越來越大的時候，我有責任給到大家一個正確的引導——去偽存真，簡潔有效，而不是引入更多的複雜度。

實際上，COLA 是由兩部分組成的：

一方面 COLA 是一種架構思想，是整合了洋蔥圈架構、介面卡架構、DDD、整潔架構、TMF 等架構思想的一種應用架構。

![](https://s4.51cto.com/images/blog/202007/09/acb4208f17ce03b682b8d07f25ae27a0.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)

在這次升級中，架構思想部分基本沒有變化，唯一一點是因為去除了 Command 概念，因此 CQRS 也成了可選項，而不再是一種強要求。

另一方面 COLA 也是框架元件，透過這次升級，我使用奧卡姆剃刀砍掉了絕大部分的元件能力，僅僅保留了擴充套件點功能。其用意是不希望 COLA 作為框架給到應用開發者太多的約束，這不符合簡單有效的風格。

所以，總結下來，與其說這是一次升級，不如說它是功能“降級”，是在做減法。

但我相信，減法可以讓 COLA 更加符合奧卡姆精神，幫助 COLA 輕裝上陣，走的更遠。

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

# 阿里雲 JAVA 應用腳手架

start.aliyun.com 是基於 Spring-initializr 實現的工程腳手架生成平臺，開發者們只需要新增一些註解和少量配置，就可以快速搭建分散式應用系統，它使用更親切的中文，也不會有網路延遲問題，最重要的是提供更多本地化的元件依賴。

點選連結，立即體驗阿里雲 JAVA 應用腳手架：[https://start.aliyun.com/?utm_content=g_1000150531](https://start.aliyun.com/?utm_content=g_1000150531)

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

架構簡潔之道：從阿里開源應用架構 COLA 說起

相關文章