Postgres 事务是分布式系统的超能力
在构建分布式系统时，开发者常常面临一个根本性的挑战：如何协调多个服务之间的状态，确保数据一致性和工作流的可靠性。传统方案往往引入复杂的外部工作流引擎，但DBOS（Database-Oriented Operating System）团队提出了一个截然不同的观点——Postgres 事务本身就是分布式系统的"超能力"，而工作流状态与业务数据应当在同一个 Postgres 数据库中共同存放。
核心论点：将工作流状态与业务数据共置
分布式应用的核心难题在于如何保证跨多个组件的一致性。当工作流的元数据（当前执行到哪一步、状态如何）和业务数据（用户记录、订单信息）位于不同的存储系统中时，开发者必须手动处理两者之间的同步问题。这就是所谓的"双写问题"（Dual-Write Problem）。
Postgres 提供了解决这一问题的原生答案：当事务性工作流状态与业务数据位于同一数据库时，原子性保证是免费的。整个工作流要么全部成功，要么什么都不发生。不存在"数据库更新成功但工作流引擎通知失败"的尴尬中间状态。
这一洞察彻底改变了分布式应用架构的思考方式：与其借助外部协调器来保证一致性，不如让数据库事务本身成为一致性的来源。
DBOS：将工作流嵌入 Postgres
DBOS 是基于这一原则从头构建的分布式工作流平台。它的核心设计决策是：不依赖 Temporal 或 AWS Step Functions 等外部工作流引擎，而是将工作流执行直接嵌入 Postgres 数据库内部。
在 DBOS 中，工作流的每一步都是一个数据库事务。每个步骤原子性地读写两部分内容：工作流自身的状态（当前执行进度、已完成的步骤）和应用层业务数据。这意味着 BEGIN 和 COMMIT 同时保证了业务逻辑和数据一致性的边界。
这种设计带来的好处是显而易见的：
消除双写问题。传统架构中，应用必须在更新业务数据库的同时向工作流引擎发送消息。这两个操作各自独立，一个可能成功而另一个失败。在 DBOS 模型中，数据库事务自然地将业务写入和工作流状态更新捆绑在一起——要么同时提交，要么同时回滚，不存在不一致的时间窗口。
简化运维。如果团队已经在使用 Postgres，则无需引入新的基础设施组件。没有额外的消息队列要维护，没有独立的工作流引擎要调优，没有两阶段提交协议要配置。Postgres 是唯一的可信数据源（Single Source of Truth）。
关键技术实现
DBOS 利用了几项关键的 Postgres 特性和最佳实践来实现其分布式工作流能力：
UUID v7。与传统的 UUID v4 随机 ID 不同，UUID v7 基于时间戳生成，天然有序。这使得它在分布式环境中可以作为唯一标识符使用，同时支持基于时间的排序和高效的 B-tree 索引性能。工作流实例 ID 和步骤 ID 都采用 UUID v7 生成。
Postgres 表存储工作流状态。DBOS 将工作流的执行状态直接存储在关系型表中。每个工作流实例对应一行记录，记录了当前状态、已完成步骤、输入参数和输出结果。这使得工作流状态的查询、审计和恢复变得与普通数据库查询一样简单——直接使用 SELECT 和 UPDATE 即可。
LISTEN/NOTIFY 用于步间通信。Postgres 内置的发布-订阅机制 LISTEN 和 NOTIFY 被用于工作流步骤之间的异步通信。当一个工作流步骤完成并提交后，后续步骤通过 NOTIFY 得到触发信号。这种方法不需要额外的消息队列系统，完全利用 Postgres 自身的异步能力实现步骤间的协调。
序列化隔离级别。为了保证分布式工作流的正确性，DBOS 使用 Postgres 的 SERIALIZABLE 隔离级别。这是最强的隔离级别，它保证了并发事务的执行结果与某种串行顺序执行的结果一致。虽然序列化隔离级别在冲突较多时可能导致更多的事务回滚，但它为工作流一致性提供了无懈可击的保证。
对开发者意味着什么
对于已经在使用 Postgres 的开发团队来说，DBOS 的方案意味着零额外依赖。不需要学习新的工作流 DSL（Domain-Specific Language），不需要部署新的中间件集群，不需要管理额外的状态存储。工作流就是数据库事务，而数据库事务就是工作流。
这也意味着开发者可以用他们已经熟悉的 SQL 和事务语义来编写可靠的分布式工作流。学习曲线被降到最低，而正确性保证则达到最高水平。
更重要的是，这种模式天然支持可观测性和恢复能力。由于工作流状态存储在标准的 Postgres 表中，开发者可以直接查询工作流的当前进度、检查失败原因、甚至手动干预——全部使用他们已经熟悉的 SQL 查询。不需要专用的控制面板或 API 来查看工作流状态。
适用场景与局限
DBOS 的架构特别适合以下场景：数据密集型的业务流程，如订单处理、支付流水线、用户注册/验证流程、ETL 管道等。在这些场景中，工作流的大部分逻辑涉及读取和写入数据库，将工作流状态与业务数据共置可以最大化原子性带来的好处。
然而，这种架构也可能不适合所有场景。对于涉及大量外部 API 调用或长时间等待（如人工审批流程）的工作流，Postgres 事务的持续时间有限制，需要结合补偿事务（Compensating Transaction）或 Saga 模式来处理。此外，序列化隔离级别在高并发场景下的性能开销也需要评估。
总结
Postgres 事务远不止是单数据库的数据一致性工具——它是构建可靠分布式系统的"超能力"。通过将工作流状态与业务数据共置于同一 Postgres 数据库中，开发者可以获得免费的原子性保证，消除双写问题，并显著简化系统架构。
DBOS 的实践证明：在外部分布式工作流引擎之外，存在一条更简洁的道路。对于已经有 Postgres 基础设施的团队来说，这条路几乎不需要额外的依赖，却能在正确性、可观测性和运维简易性上带来显著收益。当你下次设计分布式工作流时，不妨思考一个问题：能否让数据库事务本身成为你的工作流引擎？
原文出处：原文链接
原文出处：原文链接
