在这篇文章中，描述了工作流应用程序从无状态到有状态设计的演变。
初始无状态设计
- 最初建立在 Heroku 的免费 dynos（容器）上，它会在传入请求时启动。
- 由于 Heroku 不提供免费存储，因此使用内存 H2 数据库。
- 由于缺乏持久存储，工作流必须在一次运行中执行并完成。
- 转换仅限于从“积压”到“放弃”、“拒绝”或“接受”状态。
迁移到有状态
- Heroku 取消免费计划后，从 Heroku 迁移到 Scaleway 的免费无服务器容器。
- 从 H2 移至 Cockroach Cloud 的免费计划以实现持久存储。
重构为新的状态设计，受益于持久存储时释放其真正威力。
借助持久存储，我们可以在任务完成后暂停流程实例，稍后恢复流程。
为此，我们依赖BPMN 术语中的消息：
- 任务可以流向消息事件。
- 任务完成后，流程将等待，直到收到消息。
- 当消息发生时，流程将恢复。
- 如果您可以发送不同类型的消息，基于事件的网关有助于将流程转发到正确的下一步。
然而，魔鬼潜伏在细节中：任何实例都可以接收消息，我们可以随消息发送业务key。
好处：
- 通过持久存储，增加了更多状态
- 引入“reopen”等新状态来处理更复杂的工作流程。
- 利用状态机来建模和验证不同的转换。