:showtitle: :toc: left :icons: font

steno

此仓库包含一个基于 Caitie McAffrey 描述的分布式 Sagas（见 https://www.youtube.com/watch?v=0UTOLRTwOX0[Distributed Sagas）的正在进行的原型界面。有关详细信息，请参阅 crate 文档。您可以使用以下命令自行构建文档：

cargo doc

Sagas 旨在将复杂任务分解为相对简单的操作。saga 的执行（处理回滚等）在一个地方实现，并提供了良好的观察进度、控制执行等机制。这正是此 crate 提供的功能。

状态

此 crate 提供了定义和执行 sagas 的可使用接口。

功能

• 执行记录到 saga 日志。消费者可以实现 SecStore 以将此持久化到数据库。可以恢复中间日志状态，这意味着您可以在模拟崩溃后继续执行。
• 操作可以使用任意可序列化类型（不幸的是，动态检查）共享状态。
• 回滚：如果一个操作失败，所有节点都会回滚（基本上，对那些操作已完成的节点的撤销操作将被执行；对于那些可能已运行的节点的操作，会更复杂）
• 向任意节点注入错误
• 细粒度状态报告（每个操作的状态）

有一个示例程序（examples/demo-provision）用于使用类似虚拟机配置的玩具 saga 练习所有这些功能。

有许多注意事项

• 所有实验和测试都使用一个实际上什么也不做的玩具 saga。
• 代码是原型质量（即，一般）。有巨大的清理和改进空间。
• 几乎还没有自动化测试。
• 还有很多重要的问题尚未解决。首先
• 更新和版本控制：saga 代码的打包、更新等；以及代码和状态的版本控制
• 子 saga：saga 操作创建其他 saga 是完全可能的，这对于我们的用例很重要，因为可组合性很重要。但是这样做不是幂等的，并且在失败的情况下不一定会做正确的事情。

主要风险和开放性问题

• 这种抽象是否合理？让我们在oxide-api-prototype中尝试原型设计。
• 故障转移（或“高可用性执行”）

未来功能想法包括

• 控制：暂停/恢复，中止，并发限制，单步，断点
• 金丝雀发布
• 关于没有撤销操作的节点（例如，暂停并通知操作员，然后根据指示恢复saga；仅前向故障转移）的其他策略
• 对于saga，“范围”或“爆炸半径”的概念，以便更大的系统可以以保留整体可用性的方式安排saga
• 更好的编译时类型检查，这样你无法向saga图添加使用其祖先未提供的数据的节点

与分布式saga的分歧

如上所述，此实现非常严重基于分布式saga。上述演讲中没有涵盖一些重要考虑因素

• 操作如何共享状态？（如果早期步骤分配了IP地址，如何让后续步骤使用该IP地址配置网络接口？）
• 如何提供高可用性执行（至少，saga执行协调器（SEC）故障时自动继续执行的执行）？等价地：如何确保两个SEC实例不会同时处理相同的saga？

我们也在几个方面推广了这个想法

• 节点不一定需要有撤销操作（补偿请求）。我们可能会提供策略，导致saga暂停并等待操作员，或者只进行前向故障转移。
• 参见上述内容：金丝雀发布，范围，爆炸半径等。

原始演讲中使用的术语似乎来自微服务和数据库。我们发现其中一些术语很令人困惑，并选择了不同的术语

[cols="1,2,1,2",options="header"] |=== |我们的术语 |这意味着什么 |分布式saga术语 |为什么选择另一个术语

|Action |saga图中节点，或（等价地）当执行器“执行”图中的节点时用户定义的操作 |Request |“请求”暗示RPC或HTTP请求。我们的操作可能涉及这两个中的任何一个，或者可能由多个请求组成。

|Undo action |需要逻辑上撤销的节点的用户定义操作 |Compensating request |参见“Action”以上。我们本可以将其称为“补偿操作”，但“撤销”更能唤起所发生的事情。

|Fail/Failed |未成功执行的操作的结果 |Abort/Aborted |“Abort”可以表示许多事情，比如可能表示一个操作失败了，或者它在运行时被取消，或者它被撤销。这些都是不同的事情，因此我们选择了不同的术语以避免混淆。

|Undo |需要逻辑上撤销的节点所发生的事情。这可能涉及执行撤销操作（如果操作之前已成功），或者更复杂的操作。 |Cancel/Cancelled |“Cancel”可能会让读者认为我们停止了正在进行的操作。这并不是这里的含义。此外，我们避免了尴尬的“canceled”与“cancelled”之争。

|===