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

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

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

那么，不妨试试 Erda Pipeline 吧～

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

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

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

1. 自研能更快地响应业务需求，进行定制化开发；
2. 时至今日，开源社区还没有一个实质上的流水线标准，各种产品百花齐放；
3. 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 年非常火）