头脑风暴:跨语言的工作流节点

之前做过一个跨语言的定时任务调度器, 最近写了很多工作流函数, 突然想到,其实工作流也可以做成跨语言的方式

首先, 传统的工作流, 都是写在后端中, 绑定了后端的技术框架,比如我的后端是go语言,但是可能我有一个很简单的工作流,只需要调用一个python脚本就能搞定, 或者别的有需要增加工作流的同事,他的技术栈只有python, 那么他就只能等待我们来写工作流.传统的的工作流就绑死了后端,任何工作流的节点逻辑变动都需要更新后端

新的想法:

工作流-> 工作流节点 -> 节点顺序

在工作流节点定义上, 我们可以分为审批节点或工作节点

重点在于工作节点, 这里类似于之前做的定时任务, 在创建工作节点时, 用户可以输入一些变量, 这里是一些token之类的敏感数据.接着是git地址, 工作节点语言,入口文件

我们用一个申请跳板机权限工作流举例

工作流: 申请跳板机权限

工作流节点

  • 审批节点: 指定由某个组有权限审批
  • 工作节点:
    • 创建一个git仓库,写一个python脚本
    • 一些不变的常量,在前端填好, 跟随工作流节点存储在数据库里, 比如跳板机api的token
    • 会变的变量: 比如我们要给某个用户权限, 那么我们就是2个变量, 一个是用户的跳板机账号, 一个是用户申请的权限, 这个是动态变化的, 当用户在前端选择创建申请跳板机权限的工作流,然后填写, 传到后端, 每次由后端传入

接着我们后端就很简单了, 当审批节点通过, 我们读取工作节点的数据, 创建一个容器, 克隆仓库,把用户前端填的变量以及工作节点的常量通过环境变量注入到容器的环境变量, 然后运行入口文件, 运行结束, 更改工单的状态, 发送邮件通知用户.

这里唯一的问题就是和后端内部的数据交互, 比如涉及到一些sql的操作, 那么可能需要后端提供api来实现.


评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注