cadence-workflow - Uber Cadence 活动是否应该成为服务实施的一部分？

Question

我有一个关于在 Cadence 中实施活动的“最佳实践”的问题。当工作流的活动跨越不同的服务时，活动通常是作为服务本身的一部分实现的，还是更常见的是保持活动分开并依赖服务 API：s 与服务交互？

Answer 1

将活动直接嵌入到单独的服务中的原因：

• 长时间运行的操作：在 RPC 服务中实现长时间运行的操作没有标准和干净的方法。如果一个活动可能需要几分钟或更长时间才能运行，它通常会发出心跳以确保及时超时。Cadence 客户端库直接支持心跳。
• 流控制：Cadence worker 配置指定了最大消耗率和同时处理的最大活动数。Cadence worker 本质上是一个队列消费者，只有当它有能力根据配置处理它们时才会接收新的活动任务。当活动调用远程服务时，此流控制将丢失。重载时，远程服务只能使请求失败。在这种情况下，Cadence 活动确实支持指数重试，但依靠失败和重试进行流量控制显然是一种较差的解决方案。

存在无法嵌入的情况：

• 调用外部服务：工作流通常必须依赖于无法嵌入 Cadence 活动的现有服务。在这种情况下，调用外部服务的活动是唯一的选择。对于流控制，请确保在执行活动时指定指数重试策略（包括不可重试错误列表）。对于长时间运行的操作，将调用建模为两个活动。第一个调用start 不管API，第二个在活动函数内循环轮询结果。PollForResult活动应该向 Cadence 服务发送心跳，以确保在托管它的工作人员出现故障时重试它。
• 不受支持的编程语言：如果您必须使用仍然没有相应的 Cadence 客户端库的语言来实现活动，那么经常将此功能公开为服务是最简单的选择。