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

EN

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

running ：在

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

在某些情况下，嵌入是不可能的：

• Calling外部服务：通常，工作流必须依赖于无法嵌入Cadence活动的现有服务。在这种情况下，调用外部服务的活动是唯一的选择。对于流控制，请确保在执行活动时指定指数重试策略(包括不可重试错误的列表)。对于长时间运行的操作，将调用建模为两个活动。第一个调用start，第二个在activity函数内的循环中轮询结果。PollForResult活动应该心跳回Cadence服务，以确保如果托管它的工作者使用down.
• Unsupported编程语言：如果您必须在一种仍然没有对应的Cadence客户端库的语言中实现一个活动，那么频繁地将此函数作为服务公开是最简单的选择。