深入探索云原生流水线的架构设计

目前，市面上的流水线/工作流产品层出不穷，有没有一款工作流引擎，能够同时满足：

支持各种任务运行时，包括 K8s Job、K8s Flink、K8s Spark、DC/OS Job、Docker、InMemory 等？
支持快速对接其他任务运行时？
支持任务逻辑抽象，并且快速地开发自己的 Action？
支持嵌套流水线，在流水线层面进行逻辑复用？
支持灵活的上下文参数传递，有好用的 UI 以及简单明确的工作流定义？
······

那么，不妨试试 Erda Pipeline 吧～

Erda Pipeline 是一款自研、用 Go 编写的工作流引擎。作为基础服务，它在 Erda 内部支撑了许多产品：

CI/CD
快数据平台
自动化测试平台
SRE 运维链路
……

Erda Pipeline 之所以选择自研，其中最重要的三点是：

自研能更快地响应业务需求，进行定制化开发；
时至今日，开源社区还没有一个实质上的流水线标准，各种产品百花齐放；
K8s、DC/OS 等的 Job 实现都偏弱、上下文传递缺失，无法满足我们的需求，更不用说灵活好用的 Flow 了，例如：嵌套流水线。

本文我们将主要从架构层面对 Pipeline 进行剖析，和大家一起来深入探索 Pipeline 的架构设计。主要内容包括以下几个部分：

整体架构
内部架构
水平扩展
分布式架构
功能特性
实现细节

整体架构

Pipeline 支持灵活的使用方式，目前支持 UI 可视化操作、OPENAPI 开放接口、CLI 命令行工具几种方式。
协议层面，在 Erda-Infra 微服务框架的加持下，以 HTTP 和 gRPC 形式对外提供服务：在早期的时候，我们只提供了 HTTP 服务，由于 Erda 平台本身内部是微服务架构，服务间调用就需要手动编写 HTTP 客户端，不好自动生成，麻烦且容易出错。后来我们改为使用 Protobuf 作为 IDL（Interface Define Language），在 Erda-Infra 中自动生成 gRPC 的客户端调用代码和服务端框架代码，内部服务间的调用都改为使用 gRPC 调用。
在中间件依赖层面，我们使用 ETCD 做分布式协调，用 MySQL 做数据持久化。ETCD 我们也有计划把它替换掉，使用 MySQL 来做分布式协调。
最关键的任务运行时（Task Runtime）层面，我们支持任务可以运行在 K8s、DC/OS（分布式云 OS，在 2017-2019 年非常火）、用户本地 Docker 环境等。
我们还有开放的任务扩展市场，在平台级别内置了非常多的流水线任务扩展，开箱即用。同时，用户也可以开发企业/项目/应用/个人级别的任务扩展，这部分功能在代码层面已经完全支持，产品层面正在开发中，在后续迭代中很快就可以和大家见面。

内部架构

使用 Erda-Infra 微服务框架开发，功能模块划分清晰：

Server 层包括业务逻辑，对 Pipeline 来说业务就是创建、执行、重试、重试失败节点等。
Modules 层提供不含业务逻辑的公共模块，其余两层均可调用，包括预校验机制、定时守护进程、YAML 解析器、配置管理、事件管理等。

Erda Pipeline 一直在践行：“把复杂留给自己，把简单留给别人”。

在 Pipeline 中，我们对一个任务执行的抽象是 ActionExecutor。

Engine 层负责流水线的推进，包括：
- Queue Manager 队列管理器，支持队列内工作流的优先级动态调整、资源检查、依赖检查等。
- Dispatcher 任务分发器，用于将满足出队条件的流水线分发给合适的 Worker 进行推进。
- Reconciler 协调器，负责将一条完整的流水线解析为 DAG 结构后进行推进，直至终态。
模块内部使用插件机制，对接各种任务运行时。
AOP 扩展点机制（借鉴 Spring），把代码关键节点进行暴露，方便开发同学在不修改核心代码的前提下定制流水线行为。
- 目前已经有的一些扩展点插件，譬如自动化测试报告嵌套生成、队列弹出前检查、接口测试自动登录保持等。
- 这个能力后续我们还会开放给调用方，包括用户，去做一些有意思的事情。
统一使用 Event，封装了 WebHook / WebSocket / Metrics。

水平扩展

随着 Pipeline 需要支撑的业务场景和数据量与日俱增，单实例的 Pipeline 稳定性和推进性能面临着挑战。

Pipeline 的多实例方案如下：

Leader & Worker 模式，两者在部署上不区分状态，仅为 Replicas 多实例：
- 使用 ETCD 选举，每个实例都可以是 Leader。
- 只有 Leader 开启 Queue Manager 和 Dispatcher，分发任务给 Worker。
- Leader 本身也可以作为 Worker，支持单节点部署模式，Leader 必须开启 Reconciler。
Dispatch 使用有界负载的一致性哈希算法：
- 使用一致性哈希来分配任务。但一致性哈希会超载，例如某些热点内容会持续打到一个节点上。
- 有界负载算法（The bounded-load algorithm）：
  - 只要服务器未过载，请求的分配策略与一致性哈希相同。
  - 过载服务器的溢出负载将在可用服务器之间分配。
- Pipeline 实例增减时，已经被分配的流水线不重新分配，尽可能减少切换成本，防止重复推进；新增的流水线使用一致性 Hash 算法进行分配。

在之前，我们使用过分布式锁的方案来做多实例协调。和选举比起来，竞争会更大，在具体实现里，如果想要多实例同时推进流水线，那竞争的资源就是流水线 ID。每个 ID 会请求一个分布式锁，而且这个分布式锁是阻塞性的，保证每个流水线 ID 一定会被推进，天然做了多节点重试。

分布式架构

该分布式架构是典型的 AP 模型，数据层面遵循最终一致性。

这套分布式架构的核心目标（典型场景）是在网络分区的情况下，保证边缘集群的定时任务正常执行。

我们来对比一下原有部署架构（运行时以 K8s 为例）：

中心 Pipeline 直接负责流程推进，调用边缘 K8s 创建 Job。
当网络分区时，原有部署架构下，定时任务无法正常执行。

分布式架构：

中心下发任务定义，由 Edge Pipeline 负责推进，直连 K8s，更加稳定。
在网络分区恢复时，主动上报执行数据，实现数据最终一致性。

在代码层面，我们使用同一份代码构建出同一个镜像，通过配置（不同的部署模式）使得各个实例各司其职。

另外，在数据同步时，我们遇到了前端 JavaScript Number 类型 53位最大值问题，对 SnowFlake ID 进行了 64bit -> 53bit 的改造，在保证唯一性的前提下，尽可能地增加可用性（生命周期约为 10 年，同时支持 4096 个分布式节点，每 10ms 可生成 64 个 ID）。