8.0
热点
AI SCORE
技术实践2026-08-03 23:01
DBOS：数据库操作系统化解复杂时序任务容错难题
dev.to · AI#分布式系统#数据库#架构
Editor brief · 编辑速览
DBOS提供数据库级的操作系统抽象，通过数据库原子性解决分布式流程中的容错、幂等性和金融级一致性问题，避免saga/Kafka复杂编排。
一位客户注册了金融产品。系统验证资格、创建账户、冻结或扣款、激活订阅、发送事件、安排后续检查。流程在第三步之后某处死掉了。
不是优雅地失败。是死掉了。
容器被杀死。部署推出。工作进程失去连接。流程重启时早已改变了外部世界。
现在问题不再是"我们如何运行这段代码？"
而是：我们是否已经转账了？
这就是精美的流程图变成生产系统的地方。如果第三步扣费了卡、记了账、冻结了余额或调用了合作方，从头重新执行整个任务不是恢复——而是重复。
在北美的一家金融科技公司，答案基本就是：Saga、Kafka、幂等性键、对账作业和纪律。
那套架构现在众所周知。你把业务流程建模为本地事务。每个服务掌管自己的数据。事件驱动流程推进。出问题时，另一个步骤补偿、重试或标记为人工审查。你和最终一致性达成和解，然后交上运维账单。
账单是真的。
每个边界都需要幂等性。每个消费者都需要知道重复消息是否无害。每个 Saga 都需要地方记录进度。每个超时都需要语义。每个补偿都需要理解反向是否可能，或者唯一诚实的选择是否是人工审查。
机制并不优雅。你最后得到工作流状态表、去重约束、Kafka 主题、死信队列、仪表板、重放脚本和对账作业。对账作业问金融软件最重要的问题：
"什么应该是真的，什么实际是真的？"
这套模型有效。我尊重它。它迫使工程师真正理解业务流程。它也在公司内部创造了一个无声的平台。到某个时刻，"我们就用事件"变成了"我们维护了一个由约定组成的分布式工作流引擎"。
当公司足够大时没问题。当每个团队都重新发现同样的故障模式，因为这个原语从未成为工程平台内的产品时，就不那么好了。
我现在在海湾一家银行看到了相似的结构换了不同的名字：订阅激活、定期扫账、周期性检查、合作方调用、延迟操作、宕机后重试。名字不同，但问题永远无聊而残酷：
这个多步骤作业能否在不撒谎的情况下活过一次崩溃？
这就是为什么 DBOS 吸引了我的注意。不是因为我认为每个团队都应该用 DBOS。这不是 DBOS 评测。有趣的部分更通用。
持久化执行已经从"每个严肃的后端团队最终都会构建这东西"转变为"你可以安装一个给你控制平面特性的东西"。
DBOS 和 Temporal 用不同的方法处理这个问题，但在开发者层面承诺相似的东西：用普通代码写工作流、标记有意义的步骤，运行时记录足够的状态来在故障后继续。
DBOS Transact 是那个想法的轻量级 Postgres 风格版本。目前 DBOS 的定位是 Transact 开源、随应用运行，并将工作流或队列状态存储在 Postgres 兼容数据库中。DBOS 说那个数据库可以是你的应用数据库。应用重启时，未完成的工作流从最后完成的步骤继续。
这很重要，因为采用路径很小。不需要单独的工作流集群才能开始。很多团队已经在 Postgres 中存储持久真相。付费模式围绕 Pro 和 Teams 工具、支持、Conductor 工作流管理、检查点额度和托管或自托管选项。
Temporal 是更大的平台。Temporal Workflow 在 Temporal 服务中记录事件历史。Activity 被调度、启动、完成、失败、超时或取消，这些事实追加到持久历史。工作进程崩溃时，工作流状态可以通过重放重建。Temporal Cloud 定价是月度计划加基于 Action 和存储的消费。
品味有一个很好的区别。DBOS 说，粗略地，"你已经有 Postgres 了，让我们在这里使执行持久化"。
Temporal 说，粗略地，"在专用持久化执行平台上运行你的业务流程"。两者都合理。更好的选择取决于编排权重、运维胃口、工作流生命周期，以及 Postgres 作为控制平面感觉像简化还是耦合。
但战略转变在两种情况下都一样。问题从"我们如何构建故障安全的工作流基础设施？"转变为"持久化执行应该住在哪里，当它恢复时谁拥有语义？"
人们听到"持久化执行"在心里翻译为"硬的部分解决了"。
烦人的部分变小了。硬的部分变得更可见了。框架可以记录第三步完成了。它可以避免再次运行第三步。它可以重试第四步。它可以暴露历史、日志、状态，也许让你重放或分叉一个工作流。
但它无法告诉你第三步是否是正确的边界。
它无法告诉你失败的合作方调用应该重试两分钟、两天还是永不。它无法告诉你扣费是否应该反向、账本记录是否需要冲销条目、客户应该看到"待处理"还是"失败"，或者人类是否需要检查这个案例。
这些是领域决策。在金融科技中，它们是会计决策。
这就是为什么我喜欢持久化执行作为概念，但不喜欢它周围的神奇营销。故障不会消失。它们变得足够明确，能够被设计出来。
你仍然需要边界处的幂等性。如果你的工作流调用支付提供商、账本、通知服务或合作方 API，那个边界必须容忍重复请求和歧义结果。外部世界仍然需要键、引用、关联 ID、唯一约束和对账。
你仍然需要补偿语义。"撤销"很少是真正的撤销。金融系统不删除过去。它们发布更正。它们反向、退款、过期、释放、取消或标记为审查。这些词不是同义词。
你仍然需要决定什么是一个步骤。太小，历史变成嘈杂且昂贵。太大，崩溃迫使你推理一个声称是原子的步骤内的隐藏部分进度。有用的边界通常在业务事实改变的地方。
这是真正的工程工作。持久化执行不会移除它。它使其更难隐藏。
一个属性从艰难获得的内部工程纪律开始。然后它成为框架特性。然后它成为平台原语。最终团队停止问他们是否能构建它，开始问他们还想要多少所有权。
我们看到了这个和可观测性、密钥管理、CI/CD、特性开关、策略引擎、身份、推出控制和基础设施漂移检测。持久化执行正在经历相同的处理。
无聊的控制平面属性"这个作业在崩溃后知道已经发生了什么"正在变成可购买的。
这很好。我不希望每个产品团队从 Kafka 和 cron 构建一个小 Temporal。我也不希望每个创业公司运营工作流平台因为一个激活流有五个步骤。
有用的未来是混合的。一些工作流属于应用代码内，带有 Postgres 支持的持久库。一些属于专用编排平台。一些属于简单的数据库状态机。一些应该保持为定时对账作业，因为真正的业务流程不够同步来假装其他方式。
成熟的举动是命名故障所有者。
如果工作流在钱移动后崩溃，谁决定是重试、反向、等待还是升级？如果定时扫账在三小时宕机后恢复，它处理错过的时间窗口、跳过它们还是压缩它们？如果合作方返回歧义超时，你信任本地状态、它们最终的回调还是对账拉取？
DBOS 和 Temporal 可以帮你保留进度。它们无法决定什么进度意味着什么。那仍然是你的工作。一直都是你的工作。
那是值得关注的部分。
To test my projects, I use Railway. If you want $20 USD to get started, use this link.
For further actions, you may consider blocking this person and/or reporting abuse