给 COLA 作减法：应用架构中的“弯弯绕设计”

简介： COLA 的主要目的是为应用架构提供一套简单的能够复制、能够理解、能够落地、能够控制复杂性的”指导和约束"。在实践中做者发现 COLA 在简洁性上仍有不足，所以给 COLA 作了一次“升级”，在此次升级中，没有增长任何新的功能，而是尽可能多删减了一些概念和功能，让 COLA 更简洁有效。

原文连接：点击这里

最近，同事告诉我，COLA 做为应用架构，已经被选入阿里云的 Java 应用初始化的应用架构选项之一。

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 年，波兰天文学家哥白尼在临终时发表了一部具备历史意义的著做——《天体运行论》。这个理论体系提出了一个明确的观点：太阳是宇宙的中心，一切行星都在围绕太阳旋转。该理论认为，地球也是行星之一，它一方面像陀螺同样自转，一方面又和其余行星同样围绕太阳转动。

哥白尼的计算不只结构严谨，并且计算简单，与已经加到八十余个圈的地心说相比，哥白尼的计算与实际观测资料能更好地吻合。所以，地心说最终被日心说所取代。

设计中的弯弯绕

深刻考察一下，咱们系统中，相似于“地心说”这样的弯弯绕的设计，实在是不在少数。

从系统架构的角度看，有些弯弯绕是由于系统边界划分不合理，致使职责不清，依赖混乱。

从应用架构的角度看，有些弯弯绕是由于过分设计，为了追求所谓的灵活性和可扩展性，使用了不恰当的设计。致使原本能够直观呈现的代码逻辑，被各类包装，各类隐藏，各类转发.... 无形中极大的阻碍了代码的可读性和可理解性，增长了维护成本。

举个例子，我看过无数的业务系统，喜欢拿业务流程编排说事情。所以，在业务系统中，能够看到各类五花八门的“弯弯绕设计”。

好比，在一个业务系统中，我看到了以下的 pipeline 设计。这个设计的本质是说把一个复杂的业务操做进行结构化拆解为多个小的处理单元。

拆解是正确的，可是这种处理方式显然不够“奥卡姆”（关于更多结构化分解的内容，能够看个人另外一篇文章：如何写复杂业务代码？）。做为维护人员，进入“入口函数”后，还要去查数据库，而后才能知道哪些组件被调用了，太绕了，不够直观，也不简洁。

一样的逻辑，按照下面的方式写不香吗？

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 中“弯弯绕设计”的时候了。

去掉 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);
    }
}

去掉 Interceptor

当时设计 Interceptor，是由于有 CommandBus 做为基础，为了更好的利用命令模式带来的好处，便添加了 Interceptor 功能。其本质是一个 AOP 处理。

鉴于 Spring 的 AOP 功能已经很完善了，这个设计也是有点鸡肋。事实证实，你们在使用 COLA 框架的时候，不多会使用 Interceptor，包括我本身也是同样。既然如此，剔除也罢。

去掉 Convertor、Validator、Assembler

关于命名的重要性，这里就不赘述了。当时想着是否能从框架层面，规范一下一些经常使用功能的命名。可是在实际使用中，发现这个想法也是有些过于理想化了。

我记得，在团队实践 COLA 的初期，还常常为何是 Convertor（转换器），什么是 Assembler（组装器）的事情，争论不休。

后面我仔细想了想，命名虽然很重要，但其做用域最多也就是一个团队规范，你校验器是叫 Validator 仍是 Checker 并无什么本质区别，团队本身定义就行了。尝试从框架层面去解决团队约定问题，其效果不会太好，所以也果断挥刀剔除。

类扫描优化

业务身份和扩展点的思想，是 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 等架构思想的一种应用架构。

在此次升级中，架构思想部分基本没有变化，惟一一点是由于去除了 Command 概念，所以 CQRS 也成了可选项，而再也不是一种强要求。

另外一方面 COLA 也是框架组件，经过此次升级，我使用奥卡姆剃刀砍掉了绝大部分的组件能力，仅仅保留了扩展点功能。其用意是不但愿 COLA 做为框架给到应用开发者太多的约束，这不符合简单有效的风格。

因此，总结下来，与其说这是一次升级，不如说它是功能“降级”，是在作减法。

但我相信，减法可让 COLA 更加符合奥卡姆精神，帮助 COLA 轻装上阵，走的更远。

COLA 开源地址：

https://github.com/alibaba/COLA