工作流引擎在有赞 DevOps 中的实践

一、背景

随着有赞规模的增长, 运维的事务也日益复杂, 如何能更加高效的协调好开发, 运维, 工具与流程之间的关系, 把运维人员从低效率, 高强度, 易犯错的人工操作中彻底解放出来，让他们的能力与精力有更大程度的发挥, 是一个很大的挑战。

有赞 DevOps 平台的工作流引擎 Opsflow 经过两年时间的演进, 从最开始的仅支持简易的固定顺序加定制脚本的系统, 慢慢演化到可以通过 GUI 操作的, 无需编码的, 高度定制化的, 可视化的, 可感知进度的工作流引擎, 支撑着每天数百上千的包括但不限于各种权限申请, 应用组件申请, 大数据相关审批, 发布审批, 持续集成与交付等千差万别的流程。

本文将从以下几个主要方面分别阐述有赞 DevOps 工作流引擎 Opsflow 的建设与演进：

在 Opsflow 完善之前面临一系列的问题:

流程的可定制化程度低
卷入流程的人无法感知一个流程的进度
无法可视化流程, 需要人肉检查配置, 容易出错
前端可定制程度低
各种审批流程分散在不同的应用中, 重复造轮子
不支持动态确定流程分支
老系统无法处理审批人请假等问题
参与人类型支持缺乏
新流程接入成本高
无集中的统计报表, 较难感知运营情况
...

Opsflow 的系统设计以及在有赞的落地情况, 内容包括:

Opsflow 系统设计
目前在有赞 DevOps 平台的落地现状
Roadmap

二、工作流引擎设计

2.1 架构设计

Opsflow 的实现由管理有限状态机的 Opsflow-FSM 模块, 与外界交互的 Opsflow-Web 模块, 驱动插件的 Opsflow-Plugins 模块和执行具体任务的 Worker 模块和用来监控任务消费情况的监控模块组成, 下文逐一对这些模块进行介绍。

2.1.1 Opsflow-FSM

截止本文发布, 有赞 DevOps 平台已有 90 流程接入 Opsflow, 每个流程在 Opsflow 看来上都是一个有限状态机 ( Finite-state machine ), 当管理员在 Opsflow 管理后台通过 GUI 界面生成一个新流程, 本质上是在 Opsflow 上创建了一个新的 FSM, 例如下图的 "新建 ES 申请" 就是一个 Opsflow-FSM 管理的一个 FSM. Opsflow-FSM 作为 Opsflow 的核心, 驱动工单往前推进, 例如, 当一个 "新建 ES 申请" 工单运行到 "ES 管理员审批" 状态时, Opsflow-FSM 通过持久化在 RDS 中的工单实例可以得到当前审批人可以触发的三个流转 "同意" / "驳回" / "关闭工单", 任何一个流转通过页面被触发之后又由 Opsflow-FSM 驱动至 "审批驳回脚本执行" / "审批完成脚本执行" / "审批拒绝脚本执行" 状态之一, 以此类推, 最终 Opsflow-FSM 驱动工单 ( 也即特定 FSM 的实例 ) 至 "结束" 状态, 完成一个工单的生命周期。

2.1.2 Opsflow-Web

Opsflow-FSM 仅仅对 FSM 进行管理, 无法与外界交互, Opsflow-Web 则封装了 Opsflow-FSM, 增加了权限验证 ( 某个人是否有权限处理特定工单, 某个应用是否可以操作某类工作流 ( FSM ) 等 ) 等模块, 以 RESTful API 的方式对外界提供服务, 与有赞 DevOps 平台下的其他各个系统(发布系统, CI & CD 系统, 水位系统等 ) 进行交互. 以前文的 "新建 ES 申请" 流程为例, 工单在 "ES 管理员审批" 节点时 Opsflow-Web 根据 Opsflow-FSM 给到的三个流转信息在前端渲染出相应的三个按钮, 审批人按下其中一个按钮之后, 动作又由 Opsflow-Web 提供的 RESFful API 与前端交互, 触发 Opsflow-FSM 将 FSM 实例往相应的分支进行流转, FSM 向着 "结束" 状态推进。

2.1.3 Opsflow-Plugins

基于可扩展性的考虑, Opsflow 提供插件系统 Opsflow-Plugins, 插件系统发送 Opsflow-FSM 在 FSM 在不同状态间流转的过程中的各种事件, 例如, "工单设置了新的参与人" 事件, 得益于 Opsflow-Plugins, 运维开发同学一旦接到诸如 "在工单设置新的参与人的时候通知一下 xxx" 等需求的时候, 实现起来不费吹灰之力, 只需要提供一个实现起来非常简单的插件即可, 具体来说就是订阅相应事件, 提供回调接口即可. 目前有企业微信通知, Ops 待办事项等插件通过 Opsflow-Plugins 接入 Opsflow, 在保持 Opsflow 核心精简的同时丰富了 Opsflow 的功能。

2.1.4 Worker

工单经过审批节点后通常会流转到状态机中设定好的 "脚本" 节点 ( 节点的参与人属性是 "脚本" 的 FSM 节点 ), Opsflow-Web 将会推送相应的任务 ( 例如前文 "新建 ES 申请" 流程的具体负责新建 ES 相关资源的任务 ) 到消息队列中, Worker 则从消息队列中获取任务执行, 执行完具体任务后, 触发 Opsflow-FSM 继续流转. Worker 的实现使用分布式任务队列 Celery 队列堆积时可快速水平扩展。

2.1.5 前端

前端页面结构

Opsflow 前端为所有工作流提供了默认的页面展示, 包括 "流程图" / "工单进度" / "工单详情" ( key / value 的形式呈现工单实例的信息) / "工单操作" 等组件, 管理员可以在管理后台对这些组件进行是否显示以及顺序等进行方便地配置。

工作流自定义前端组件案例

不同的工作流很可能需要定制自己的前端, 例如前文的 "新建 ES 申请" 流程就需要在页面上展示 "字段信息" / "SLA" 等信息, Opsflow 对自定义工作流前端提供了丰富的支持, 对于 "新建 ES 申请" 这个流程而言, 负责开发的同学仅需提供一个 React 组件, Opsflow 在渲染工单详情页面的时候会根据配置动态加载 ( 通过 react-loadable ) 相应的前端组件渲染在上图所示的位置, Opsflow 提供给自定义组件提供丰富的 properties, 这些 properties 涵盖当前工单的所有信息, 自定义组件可以根据这些 properties, 在相应后端拉取相应的数据进行渲染, 如上图的各个例子。

流程图绘制

Opsflow-FSM 维护的有限状态机在数据结构上是 Directed acyclic graph (DAG), Opsflow 使用了非常优秀的基于 A Technique for Drawing Directed Graphs 中介绍的基于 rank 分层布局算法的 DAG 流程图绘制库 dagre-d3绘制非常飘逸的流程, 见下图中的例子。

2.2 Opsflow 设计中对前文 "一系列问题" 的解决

针对问题 1, 2, 3, 4, 9：

Opsflow 提供了 GUI 界面对 FSM 进行管理, 流程管理员可以在页面上配置 FSM 中的节点和边的各种属性, 流程中不合理的地方可以通过实时呈现的流程图暴露出来, 管理员可立即做出调整, 前文减少的前端结构解决了 2, 4 两个问题.

针对问题 5：

有赞 DevOps 平台中的绝大多数流程已经迁移到 Opsflow, 基于老的工作流系统的流程已经下线, 众多流程中的共性需求都会在 Opsflow 实现, 避免重复造轮子.

针对问题 6：

Opsflow 提供 "条件表达式" 功能, 具体来说, 工单管理员在配置一个 FSM "流转" 的时候可以指定一个 "条件表达式" 例如 Hive 语句审批流程中的

{row_count} >= 1000000 and not {upload}

Opsflow-FSM 在决定工单下一个状态的时候会根据该表达式动态的计算下一个流程节点, 例子中花括号 row_count 和 upload 分别是该工单实例的的不同属性, 例如 row_count 代表 "Hive 语句审批流程" 流程工单实例中 SQL 影响的行数, 上面的表达式翻译成 "人话" 就是: "行数大于 1000000 且用户进行了上传则到 XXX 节点", 其中 "XXX 节点" 可能是某个有 Hive 管理权限的人, 否则可能是 TL 等等.