只需使用 Postgres 即可实现持久的工作流程

耐用的工作流程是构建可靠程序的简单但功能强大的工具。这个想法是，当程序运行时，您定期将其进度检查到数据库。这样，如果您的程序崩溃或失败，您可以从最后一个检查点重新加载，以从最后完成的步骤恢复它。您可以将其视为保存在视频游戏中：您定期“保存”程序的进度，以便如果程序崩溃，您可以从最后一个检查点“重新加载”它。最常见的是，持久的工作流程是通过外部编排来实现的。这是 Temporal、Airflow 和 AWS Step Functions 等系统使用的模式。在此模型中，持久程序被编写为步骤的工作流程，其执行由中央编排器协调。当客户端提交工作流时，编排器会在数据存储中为其创建一条记录，然后将其分派给工作人员执行。每次工作人员完成一个步骤时，都会将该步骤的结果发送回协调器。协调器在其数据存储中检查输出，然后分派下一步。如果某个工作线程崩溃或失败，编排器会将其工作流程分派给另一个工作线程，从最后一个检查点步骤启动它们。在这篇博文中，我们将认为外部编排从根本上来说过于复杂。持久工作流程的核心思想是在数据库中检查程序状态。但如果持久工作流程与数据库有关，那么就没有理由拥有单独的协调器服务器。相反，使用数据库本身作为协调器更简单、更高效。为了使这一点更加具体，我们将特别关注在 Postgres 上构建持久的工作流程，因为它的受欢迎程度、可扩展性和丰富的生态系统使其成为理想的选择。在 Postgres 支持的持久工作流系统中，应用程序服务器直接与 Postgres 通信来执行工作流，而不是通过中央编排器。客户端通过在 Postgres 工作流表中创建一个条目来提交要执行的工作流。应用程序服务器轮询表以查找要出列和执行的工作流。当服务器执行工作流时，它将每个步骤的输出检查点发送到 Postgres。如果执行工作流的服务器崩溃或失败，另一台服务器可以从其检查点恢复其工作流。这种设计使得中央协调器变得不必要，因为应用程序服务器可以通过 Postgres 进行协调。服务器不依赖中央编排器将工作流程分派给工作人员，而是协作地将工作流程从 Postgres 表中出队，使用锁定子句等机制来确保每个工作流程仅由一个工作人员出队。工作人员不依赖协调器来检查步骤输出，而是对 Postgres 本身进行检查点步骤。如果多个工作人员尝试同时执行相同的工作流程，Postgres 数据库完整性约束可以让他们检测检查点上的重复工作并退出。用 Postgres（或其他数据库）替换中央协调器使持久工作流程从根本上变得更简单。特别是，这意味着可使用易于理解的 Postgres 原生解决方案来解决可扩展性、可用性、可观察性和安全性等难题。可扩展性和可用性 数据库支持的持久工作流系统的可扩展性和可用性从根本上由底层数据库决定。该系统可以通过添加更多工作服务器来水平扩展，因此其最大容量取决于数据库处理工作流的速度。同样，worker 是可替代的，可以自由恢复彼此的状态，因此只要底层数据库可用，系统就可用。当专门使用 Postgres 时，这是有益的，因为 Postgres 的可扩展性和可用性是经过充分研究的稳健解决方案问题。为了可扩展性，单个 Postgres 服务器可以垂直扩展以每秒处理数万个工作流，并且可以通过使用分布式（例如 CockroachDB ）或分片 Postgres 来实现进一步扩展。在可用性方面，Postgres 支持具有自动故障转移功能的流式复制，托管产品可提供具有开箱即用的高可用性 SLA 的多可用区部署。因此，数十年来大规模运营 Postgres 的工程工作和研究可以直接转化为持久的工作流程。可观察性 当使用 Postgres 支持的持久执行时，工作流程及其步骤将检查点设置到 Postgres 表。这意味着可观察性是内置的：您可以扫描这些检查点以实时监控工作流程并可视化工作流程执行情况。 Postgres 擅长于此，因为几乎任何工作流可观察性查询都可以用 SQL 表达。例如，这里有一个查询，用于查找上个月出错的所有工作流程：这样的查询可能看起来很明显，但很难夸大它的强大功能。这是可能的，因为 Postgres 的关系模型让