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

Question

我对在Cadence中实施活动的“最佳实践”有疑问。当工作流的活动跨越不同的服务时，活动通常是作为服务本身的一部分实施的吗？还是将活动分开并依靠服务API与服务进行交互是更常见的做法？

Answer 1

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

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

在某些情况下无法嵌入：

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