Fastflow——基于golang的轻量级工作流框架 Fastflow 是什么？用一句话来定义它：一个 基于golang协程、支持水平扩容的分布式高性能工作流框架。 它具有以下特点： 易用性：工作流模型基于 DAG 来定义，同时还提供开箱即用的 API，你可以随时通过 API 创建、运行、暂停工作流等，在开发新的原子能力时还提供了开箱即用的分布式锁功能 高性能：得益于 golang 的协程 与 channel 技术，fastflow 可以在单实例上并行执行数百、数千乃至数万个任务 可观测性：fastflow 基于 Prometheus 的 metrics 暴露了当前实例上的任务执行信息，比如并发任务数、任务分发时间等。 可伸缩性：支持水平伸缩，以克服海量任务带来的单点瓶颈，同时通过选举 Leader 节点来保障各个节点的负载均衡 可扩展性：fastflow 准备了部分开箱即用的任务操作，比如 http请求、执行脚本等，同时你也可以自行定义新的节点动作，同时你可以根据上下文来决定是否跳过节点(skip) 轻量：它仅仅是一个基础框架，而不是一个完整的产品，这意味着你可以将其很低成本融入到遗留项目而无需部署、依赖另一个项目，这既是它的优点也是缺点——当你真的需要一个开箱即用的产品时（比如 airflow），你仍然需要少量的代码开发才能使用 为什么要开发 Fastflow 组内有很多项目都涉及复杂的任务流场景，比如离线任务，集群上下架，容器迁移等，这些场景都有几个共同的特点： 流程耗时且步骤复杂，比如创建一个 k8s 集群，需要几十步操作，其中包含脚本执行、接口调用等，且相互存在依赖关系。 任务量巨大，比如容器平台每天都会有几十万的离线任务需要调度执行、再比如我们管理数百个K8S集群，几乎每天会有集群需要上下节点、迁移容器等。 我们尝试过各种解法： 硬编码实现：虽然工作量较小，但是只能满足某个场景下的特定工作流，没有可复用性。 airflow：我们最开始的离线任务引擎就是基于这个来实现的，不得不承认它的功能很全，也很方便，但是存在几个问题 由 python 编写的，我们希望团队维护的项目能够统一语言，更有助于提升工作效率，虽然对一个有经验的程序员来说多语言并不是问题，但是频繁地在多个语言间来回切换其实是不利于高效工作的 airflow 的任务执行是以 进程 来运行的，虽然有更好的隔离性，但是显然因此而牺牲了性能和并发度。 公司内的工作流平台：你可能想象不到一个世界前十的互联网公司，他们内部一个经历了数年线上考证的运维用工作流平台，会脆弱到承受不了上百工作流的并发，第一次压测就直接让他们的服务瘫痪，进而影响到其他业务的运维任务。据团队反馈称是因为我们的工作流组成太复杂，一个流包含数十个任务节点才导致了这次意外的服务过载，随后半年这个团队重写了一个新的v2版本。 当然 Github 上也还有其他的任务流引擎，我们也都评估过，无法满足需求。比如 kubeflow 是基于 Pod 执行任务的，比起 进程 更为重量，还有一些项目，要么就是没有经过海量数据的考验，要么就是没有考虑可伸缩性，面对大量任务的执行无法水平扩容。