背景

在运维的工作中，经常会有一些小脚本承担粘合各个系统的功能，比如发一些 http 请求、比如封装调用某个 cli 、比如下载一个文件并做一些特定的处理、比如创建一个xx系统的账号 等等。

这类小脚本经常具备一些相似的特点：功能简单、参数固定、对特定 cli 的特定功能做简便封装、大都是 shell 或简单的 python scripts。

遇到的问题是：

• 每个脚本的使用频率都不高，每次使用时都要重新看有哪些参数，以及理解不同参数的含义
• 调用脚本有时需要特定的环境，例如特定工具、环境变量等，容易出现在另一台机器上运行出错的情况
• 脚本有时候需要提供给他人使用，但一些特殊的账号、token 之类又不能直接共享，同时还希望脚本被调用时有审计日志
• 一些脚本的功能逻辑本身挺简单，但为了提供给外部调用，需要写大量适配的代码，比如 http server、cli、client sdk 等等

为了实现快速集成到系统，需要有一个 scripts 管理工具，用这个工具去解决上面遇到的这些问题。姑且把这个工具称为 taskframe 吧。

梳理

和 k8s 的异同

从实现的角度，scripts 每次需要都要有运行环境，一个不错的方案是在特定的容器中运行，因此类似于一个 k8s job 的运行。 但从触发机制上来看，taskframe 应当至少提供 http、cron 的触发方式，而 k8s job 是手动触发、cronjob 是 cron 触发。

k8s 本身的 API 扩展机制和 taskframe 创建特定路由的 task 是类似的，都会提供动态更新的 api 扩展、提供 鉴权、参数校验 的方法。这都是 taskframe 可以借鉴的地方。

和 serverless 的异同

serverless 是为了简化服务运维而生的一种更便捷的服务部署方式，一般认为 serverless = fc + baas。 如果站在 fc (function compute) 的角度来看，和 taskframe 有很多类似的机制。
fc 会管理服务的计算资源，在触发的时候调度，提供运行的容器，在未使用之后对容器进行回收。 这点和 taskframe 基本一致。

fc 框架一般会提供了多种触发机制，例如 http request、cron、对象存储变动、消息队列变动 以及 其他事件驱动的触发器 adaptor。taskframe 主要提供 http 和 cron。

当 fc 触发为 http request 时，一般会提供可选的网关 auth 方式，例如基于 basic auth、 jwt 或者配置 auth 插件。 这和 taskframe 基本一致。

不同的是，serverless 是一个通用的体系，没有针对 scripts 的管理方案，而 taskframe 是专门为 task 管理而生的方案，提供开箱即用的 auth 方案、cli 和 sdk 生成方案、日志审计方案等。

和 task flow 的异同

flow 的核心是 task 之间的触发拓扑关系，例如开源的 n8n、argo workflow 之类。
flow 的模式可以认为是 taskframe 的超集，而 taskframe 可以认为是在 scripts 管理方面的专门优化版本。

从 taskframe 的实践角度看，单个节点的 task 应当尽可能独立而完整，而不是拆分成多个子功能进行组装，大多数 task 都应当只有一个 script，而不是使用例如 flow 中的 steps 和 next node 的方式。 (因为复杂的拆分会让对于本身就改动不多、体量较小的 script 更加难以管理)

和 service 的异同

在现代 server 框架中，常采用分层架构的代码组织形式，主体可以看做是：上层是 api 层，中间层是 service 层，下层是 dao 层。

从 taskframe 要提供的能力来看，是 api 层的能力，主要包括 路由、鉴权、频控、参数校验、日志记录 的能力，而我们的每一个 script 都可以认为是一个 service。

实现方式的探讨

基于 k8s 的实现

• 基于 kube builder

基于宿主机的实现

• 基于 taskfile

---

One of the most beautiful qualities of true friendship is to understand and to be understood.
— Seneca the Younger