使用Temporal/Cadence实现发票支付Saga编排的相关问题咨询

Temporal/Cadence完全适配你描述的发票支付Saga编排场景，相比原有基于RabbitMQ的实现，不需要你自行维护消息监听、状态持久化、重试、补偿逻辑，开发和运维成本都更低。以下是各个问题的具体解决方案：

两种实现思路都支持，你提到的第一种思路改造成本最低，优先推荐：

• 方案一（你当前的思路）：所有Activity和InvoicePaymentWorkflow都部署在invoice服务，bank transfer、ledger服务仅提供HTTP/gRPC API即可
  你不需要改造另外两个服务的代码，也不需要在这两个服务中加任何监听器，只需要在Workflow的代码中按业务顺序依次调用BankTransferActivity（内部封装转账服务API调用）、LedgerActivity（内部封装账本服务API调用）即可，整个流程的执行状态、中间结果全由Temporal集群托管，不需要自己做状态存储和消息协调。
• 方案二：Activity按所属服务拆分部署
  如果后续转账、账本服务的能力需要复用到其他业务流程，可以把BankTransferActivity部署在转账服务、LedgerActivity部署在账本服务，三个服务都连接同一个Temporal集群，通过不同的Task Queue区分服务身份。invoice服务的Workflow编排逻辑不需要调整，只需要给不同的Activity指定对应的Task Queue，Temporal就会自动把任务调度到对应服务执行。

Temporal原生支持任意时长的异步任务，完全不需要担心超时问题，可根据你的现有架构选对应方案：

• 如果账本服务是同步API，直接把LedgerActivity的StartToCloseTimeout参数设置为大于最长耗时的值，比如设置为10分钟即可，Temporal会自动跟踪Activity的执行状态，不会因为TCP连接中断、服务重启导致任务中断，也不会出现RPC短超时问题。
• 如果账本服务是异步提交+回调的架构，可以用Temporal的Signal机制：LedgerActivity先提交记账请求，Workflow进入等待状态，直到账本服务回调调用Temporal API发送记账完成的Signal，Workflow再继续执行，等待时长最多可配置到数天级别。
• 高峰削峰场景可以给LedgerActivity对应的Task Queue设置最大并发数，控制Temporal调度到账本服务的请求量，完全替代原有RabbitMQ的缓冲能力。

有两种成熟方案可以实现和原有RabbitMQ单消费者一致的串行效果：

• 推荐用Workflow ID做业务维度的串行控制：比如需要按账户串行的记账任务，固定用ledger-account-[账户ID]作为Workflow ID，Temporal默认保证同一个Workflow ID同一时间只能有一个运行实例，后续提交的同ID任务会自动排队，同时天然支持幂等，重复提交的请求不会被重复执行。
• 如果需要和原有逻辑完全对齐，可以给需要串行的任务分配独立的Task Queue，仅启动一个Worker进程消费该队列的任务，即可实现完全串行的执行效果。

直接在Workflow代码中嵌入Saga补偿逻辑即可：

• 在调用LedgerActivity时捕获执行错误，判断属于银行已转账不可冲正的场景时，直接调用通知类Activity，比如对接内部工单系统、邮件、企业微信API给会计人员发送告警，通知所需的发票ID、转账流水、失败原因等上下文信息都可以直接从Workflow的执行上下文中获取，不需要自行存储。
• 你可以给通知Activity配置自动重试策略，保证通知至少送达一次，也可以在Workflow中加入定时逻辑，若会计人员24小时未处理则自动升级告警。

根据你选择的Activity部署方案调整即可：

• 如果用所有Activity都在invoice服务的方案，直接在Workflow的补偿逻辑中调用转账服务的退款API即可，和调用正向转账API的逻辑完全一致。
• 如果用Activity拆分部署的方案，直接在补偿逻辑中调用转账服务的退款Activity，指定转账服务对应的Task Queue即可，Temporal会保证补偿操作至少执行成功一次，不需要你额外维护补偿队列和监听器。

内容的提问来源于stack exchange，提问作者Timothy