TaskFlow/最佳实践

修订于： 2015年1月19日，David K

为什么

由于 taskflow 创造了一种通往稳定、可恢复和可跟踪工作流的途径，因此拥有一小套推荐的最佳实践是有帮助的，以确保您（作为 taskflow 库的用户）能够最大程度地受益于使用 taskflow。以下将列出一些常见的模式和最佳实践，以说明“什么”、“为什么”和“如何”，以便您可以最大限度地提升 taskflow 体验，并最大限度地减少理解 taskflow 关键原语相关的一些痛苦。

注意： 随着 taskflow 新用例的出现（以及 taskflow 中引入新功能），此列表可能会继续增长，请随时在下方添加您自己的内容。

技巧与窍门

• 创建可重用的任务，在它们的 execute 方法中做好一件事；如果该任务有副作用，请在 revert 方法中撤销这些副作用。
• 创建幂等的任务，考虑故障发生时会发生什么，并设计您的任务时考虑到恢复（这可能意味着将一个大型任务分解成更小的部分，以便执行引擎可以为您在更细粒度的单元处恢复）。
• 清晰地定义任务 provides（提供）的内容，以便未来的（可能尚未创建的）任务可以依赖于这些输出。
• 清晰地定义任务 requires（需要）的内容，以便 engine/s（引擎）可以推断出运行任务的正确顺序。
• 如果您的任务具有相同名称的要求，但您想要接受不同的输入，请使用重映射/重绑定功能。
• 通过声明任务需要什么来使用共享输入是理想的，但要小心不要与多个接收任务共享任务的输出（尤其是在输出可能不是线程安全的的情况下）（如果这样，则更喜欢不可变性）。
  • 小心，因为将引擎从 serial（串行）切换到 parallel（并行）非常容易（这是一个特性，而不是错误）。
  • 如果这仍然是一个问题，请使用基于 eventlet 的执行器来避免同步问题，同时仍然以并行方式运行（但不使用线程）。
• 将做好一件事的任务与提供的模式链接起来，以创建能够很好地协同工作的流程。
• 对于分层工作流，更喜欢模式组合（带有子流程的流程...）而不是过多的手动链接。
• 更喜欢自动顺序推断而不是手动顺序推断，因为前者更能抵抗未来的更改，而后者则不能。
• 非常小心 RPC 边界，并一丝不苟地关注这些边界如何影响您的流程、任务和应用程序。
• 始终将 (主要版本，次要版本) 与您的任务关联，以便在软件升级时，先前（可能部分）完成的任务可以迁移和恢复/撤销。
• 从任务返回可序列化对象，而不是资源（或其他不可序列化对象）；期望所有返回的对象都可以无限期地持久化。
• 善后，日志应最终过期，并且基础数据应被删除；定期执行此操作。
  • TODO： 以下 蓝图 应该使其可编程且不那么手动。
• 使用相关名称清晰地命名您的任务；名称是重新启动的流程如何与先前（可能部分）完成的任务重新关联以进行恢复或撤销的方式，因此请谨慎选择。
• 引发有意义的异常以触发任务和流程撤销；触发流程撤销的异常可能会被持久化存储（并且以后可以参考），请确保它尽可能有用和有意义。
• 小心条件，因为当前流程中的所有任务都将运行（无条件）；提前理解并设计好这一点。
  • TODO： 目前正在进行 设计工作 来解决这个问题（欢迎反馈）。