去年，有一些用户基于 ArchGuard 定制了自己的版本，但是遇到了一系列的问题；简单来说，就是可定制性差。与此同时，构建企业级的架构治理流程时，还需要考虑适用于不同团队的可扩展性、任务可追溯性等问题。

为了解决这些问题，我们开始着手设计 ArchGuard Pipeline 来构建轻量级的架构治理流程。现在，这个功能处于一个可工作的 MVP 状态，如果你对这个功能有兴趣，欢迎来加入开发：https://github.com/archguard/codedb-poc

为什么需要一个轻量级数据 pipeline？

在 ArchGuard 2023 的 Roadmap 里，我们的核心是：自定义的架构适应度函数，而其原因包含了：

• 不同时间关注点不同。
• 不同系统间存在明显架构属性差异。
• 度量指标不通用。
• ……

除此，有的团队还想要精细化的控制架构演进，如通过自定义的架构适应度函数，可以更加细致地控制系统的架构，从而实现更好的管理和治理效果。

而在当前的版本中，想要定制的话存在一些问题，包括：

1. 定制性不足：当前版本定制性很差，需要修改的代码范围很大，非常不灵活。
2. 扩展性有限：当需要添加新的构建步骤或治理工具时，扩展非常困难。
3. 可视性差：分析过程非常复杂，难以跟踪和调试，可视性很差。
4. 无重试机制：当单个任务出错时，需要重新分析整个过程，缺乏重试机制。
5. 过程不透明：分析过程是一个黑盒，无法知道具体的任务细节，这给问题定位和解决带来了很大的困难。

上述问题，我们预期是通过 ArchGuard Pipeline 得到解决。

什么是 ArchGuard Pipeline？

ArchGuard Pipeline 是一个轻量级的架构治理流程工具，可以定制化、可扩展，让用户轻松创建和管理自定义的架构适应度函数。并计划（预计是在 CodeDB 中提供）提供了丰富的可视化工具，实现更好的可视性和透明度。

ArchGuard Pipeline 可以帮助团队更加细致地控制系统的架构演进。通过自定义的架构适应度函数，团队可以根据自己的具体需求和关注点，灵活地定义系统的架构特性和度量指标。这样，团队可以更加精细地管理和治理系统的架构，从而提高系统的稳定性、可维护性和可扩展性。

ArchGuard Pipeline 使用场景

我们思考的使用场景包括但不限于：

• 构建企业级的架构治理框架
• 团队自定义架构适应度函数
• 添加自定义的构建步骤和治理工具

我们也在思考提供可视化工具，以帮助用户更好地跟踪和调试整个流程，提高可视性和透明度。

ArchGuard Pipeline 特征

起初，因为已经有一个 ArchGuard Gradle 插件。所以，打算参考 Gradle 设计整体的工作流程，遇到了一些问题，如中心化框架等等。

在之前的 Meetup 里，我们已经介绍了 ArchGuard 的数据处理是一种 Pipeline 风格的架构。那么作为一个构建系统，它也 Jenkinsfile、GitHub Action 也是相似的，具备如下的特征：

1. 声明式语法: GitHub Action 和 Jenkins Pipeline 都支持声明式语法，这使得开发人员可以将流水线定义为代码并将其存储在版本控制系统中。
2. 插件架构: 两个平台都有插件架构，允许用户通过添加新插件或与第三方工具集成来扩展平台的功能。
3. 流水线可视化: 两个平台都提供了一种可视化流水线的方式，帮助开发人员快速了解流水线的状态并识别需要解决的任何问题。
4. 并行执行: 两个平台都允许用户并行运行多个任务或流水线阶段，有助于提高流水线的性能和速度。

上述的特性，对于 ArchGuard Pipeline 也是类似的。考虑到 DSL 的学习和设计成本，便想着参考 GitHub Action，又因为开发人数有限，我们就直接~~复制~~参考了 GitHub Action。

ArchGuard Pipeline 使用示例

如下是 ~~GitHub Action~~ ArchGuard Pipeline 的配置：

jobs:
 backend:
   steps:
     - name: "Source Code with Linter"
       uses: archguard/scanner@v2
       with:
         type: "source_code"
         language: kotlin
         features: [ "datamap" ]
         output: [ "json", "arrow" ]
         rules: [ "webapi", "test", "sql" ]
         path: "."

随后，通过 ArchGuard Runner 就可以运行我们的分析任务，并将数据上传到服务端。而如果是服务端来运行的话，还需要 Checkout 一下代码：

      - uses: actions/checkout@0.1.0-SNAPSHOT
        with:
          repository: https://github.com/archguard/code-poc.git
          branch: master

这就是全新的 ~~GitHub Action~~ ArchGuard Pipeline，新时代的架构治理编排工具。这里的每个 Action 便是一系列可执行的命令、jar 等，相当于是一系列的插件，可以直接在客户端、服务端运行。

未来会根据分析、治理等不同维度划分 action，示例如下：

      - uses: analyser/architecture@0.0.1
        with:

      - uses: linter/database@v1
      - used: metric/oo@v1
      - used: metric/complexity@v1

      - used: factor/sonarqube@v1

不过，在那之前，需要进一步进行设计和完善。

ArchGuard Pipeline 是如何工作的？

ArchGuard Pipeline 主要由三部分组件：

• Runner。负责执行 pipeline，参考了 GitHub Action 的设计，暂时不支持并行等高级功能。
• Registry。负责存储 action 包的服务器；未实现，现在只是一个基于 GitHub 的 JSON 静态服务器。
• Action。一个个运行自动化任务的工具

与此同时，为了减少 action 之间序列化带来的性能问题，我们正在试验引入 Apache Arrow，并采用 Kotlin dataframe 来支持直接基于 Apache Arrow 的数据科学计算。

执行：Pipeline Runner

设计之后的 ArchGuard Runner 主要过程如下：

即：

1. 用户通过编写 archguard.yml 文件来定义工作流程。
2. ArchGuard Runner 根据 archguard.yml 文件中的定义，自动下载并加载不同的 Action，如 checkout、scanner 等，来执行不同的任务。
3. Runner 执行任务后，会生成相应的输出制品（不同格式的数据文件）。
4. 将生成的数据上传到服务器，诸如采用 Apache Arrow 格式上传可以节省空间和时间。

这样一来，我们的主要工作就变成了创建各类的 Action，以方便团队进行架构观测。

注册：Pipeline Registry（只设计了 API）

我们参考了 NPM Registry、Maven Central 等制品仓库的思想，构建了基本的 Runner registry API。它包含了以下的功能：

1. 中央化的 Registry 机制：使用一个中央化的方式来存储和管理软件包或制品，可以方便地实现版本控制和依赖管理。
2. 多版本存储和管理：支持多版本的软件包或制品，每个版本都可以通过一个唯一的标识符进行访问和管理，这样可以方便地实现版本回滚和升级等操作。
3. API 接口：所有工具都提供了一组 API 接口，可以通过这些接口来实现自动化构建、发布和部署等操作，方便自动化流程的集成和实现。

于是乎，我们需要在 archguard.yml 中引入新的配置：

env:
  registry:
    url: https://registry.archguard.org/

现在的 Registry 是一个放在 GitHub Pages 的 JSON 文件，相当于是一个 fake server。

组件：Pipeline Runner

在 GitHub Action 里，Runner 是一系列的 JobService：

• Worker：GitHub Action 的执行环境，可以理解为一个虚拟机，每个 Worker 可以执行一个或多个 Job。
• JobRunner：运行在 Worker 上的一个进程，负责协调 Job 中多个 Step 的执行顺序，管理 StepRunner 的运行和通信。
• StepRunner：每个 Job 中的一个 Step 对应一个 StepRunner，StepRunner 负责运行一个或多个 ActionRunner。
• ActionRunner：每个 Step 中的一个 Action 对应一个 ActionRunner，ActionRunner 负责执行一个 Action 中的具体命令或脚本。

考虑到我们当前并没有执行环境、进程等，只需要好好写 ActionRunner 即可，即解析上面 Yaml 中的 steps 里的 Action 字段。根据不同的 action 来执行，并将上面的 with 字段转换成对应的参数，因此上面的配置在执行时会变成：

java -jar plugins/scanner-v2.jar --output json --output arrow --features datamap --path . --language kotlin --rules webapi --rules test --rules sql --type source_code

然后，将构建的 jar 上传到 registry，并编写一个 Json，就实现了完成的 Runner 原型。

总结

本文介绍了 ArchGuard Pipeline，一个轻量级的架构治理流程工具，可以定制化、可扩展，让用户轻松创建和管理自定义的架构适应度函数。该工具可以帮助团队更加细致地控制系统的架构演进，提高系统的稳定性、可维护性和可扩展性。

如果你也有兴趣，欢迎来加入我们：https://github.com/archguard/codedb-poc