近十年来，我一直痴迷于创建工作流引擎。工作流引擎的核心是负责在一组机器（通常称为“工作者”或节点）上尽可能快速高效地执行一系列任务（通常称为“作业”、“管道”或“工作流”）。

构建工作流引擎会带来一系列有趣的挑战。以下是一份简短且非详尽的列表：您使用什么来编写工作流？您使用通用编程语言吗？像 JSON 或 YAML 这样的配置类型语言，还是您自己开发 DSL（领域特定语言）？

我们如何决定哪些任务分配给哪些工作者，以便繁忙的工作者不会超负荷工作而其他工作者则处于空闲状态？我们如何处理根据计算需求波动而扩大或缩小容量的要求？我们如何处理间歇性任务失败？我们如何处理工作器崩溃？我们又如何处理要执行的任务多于可用容量的情况？

让我们开始实践

我们以一家视频流公司的工作流为例。当时，该公司将其所有视频处理需求外包给另一家公司。

现有流程缓慢、昂贵且脆弱。该公司定期获得新内容（电影、预告片、奖励视频材料、隐藏式字幕等），我们需要一种快速处理这些内容的方法，以便将其发布到服务中供客户享受。

此外，现有流程非常僵化，对它的任何更改（例如引入新的音频技术）都需要数月时间，甚至根本不可能实现。

工作流引擎的初始迭代使我们能够开始处理“低风险”内容（例如预告片），随着我们对新系统越来越有信心，我们慢慢地完全淘汰了旧流程。

构建工作流引擎的目的不是为了一劳永逸，它始终是在帮助诊断企业当前工作流状态优良与否的关键。有时，旧的流程需要革新，工作流引擎也需要革新，但这种革新依托于大家都意识到，工作流引擎不代表业务从头开始，而代表实践其可用性的重新开始。