Temporal / Cadence编排概念
Temporal / Cadence orchestration concept
在当前的应用中，我们有三个服务：
- 发票
- 银行转帐：调用外部 API，这可能需要一分钟左右，具体取决于队列
- ledger：创建借贷分类账的内部微服务
为了交流，我们有一个编排传奇。流程基本上使用发票作为协调器：
- 发票服务向 rabbitmq 发布消息，要求为发票 X 付款
- 银行转账服务收听消息，获取发票 X
- 银行转账服务处理转账（调用银行的API）。支付成功后，发布消息到rabbitmq 'Invoice X paid'
- 发票服务监听消息'Invoice X paid'
- 发票服务发布消息'Create ledger for invoice X'并发布到rabbitmq
- 分类帐服务从 rabbitmq 监听消息 'Create ledger for invoice X'
- 分类帐服务创建适当的分类帐日记帐借方/贷方，然后发布 'ledger created for invoice X'
- 发票服务侦听消息 'ledger created for invoice X'，然后完成（关闭）交易
问题 1
如果我使用 Temporal 或 cadence（只是在寻找它），它们并不像上面那样依赖 pub-sub 模式。那么如何实现呢？
我在想 (CMIIW) :
- 创建
InvoiceActivity
- 创建
BankTransferActivity
- 创建
LedgerActivity
- 创建
InvoicePaymentWorkflow
所有这些 Workflow 和 Activity 都是发票服务应用程序的一部分。但是 银行转账服务 和 分类帐服务 现在提供 API 来处理转账（根据银行转账，它实际上是 API 到外部银行调用的代理）， 分类帐服务 提供 API 创建 debit/credit 日志。
CMIIW，在这种情况下，我们不再需要在 bank transfer service 和 ledger service 上创建监听器（或 cadence / temporal activity） , 我们需要提供 API.
或者我想错了？ 银行转账服务和账本服务上应该有一些activity？但如果是这样，发票服务如何触发和安排工作流？
问题 2
但是现在调用是异步的。日志分类帐的创建实际上有一些验证，有时负载很重，因此取决于队列中的消息，从消息进入 rabbitmq 到日志实际创建可能需要 5 分钟。在 API 调用中，这将超时。
问题 3
那么竞争条件呢？一些日记帐按顺序创建。使用 rabbitmq，我们可以通过某些技术实现这一点（队列上的单个消费者，类似于 kafka 主题）。
问题 4
另外，如何处理补偿交易？如果分类账失败了，我们必须做点什么。在我们的案例中，我们必须通知会计人员，因为银行转账已经处理并且无法撤销。
问题 5
对于一些子公司，当分类帐失败时，我们仍然有控制权，因此我们可以补偿/提取发票金额，并将金额return退还给母公司。假设我们在 银行转账服务 上有一个监听器，我们如何触发补偿 API?
In cadence / Temporal，这个用例合适吗？如果是，如何处理上述问题？
谢谢
TLDR；此用例非常适合 Temporal，因为它极大地简化了您的代码和操作。
问题一
我建议在他们的相应服务中举办活动。因此 InvoiceActivity 应由发票服务托管，BankTransferActivity 应由银行转帐服务托管。这消除了创建同步 API 的需要，并确保工作流和 activity 实现之间的流控制。请参阅 this post 对此进行了更详细的解释。
只有在这种情况下，发票服务应用才会承载工作流代码。
问题二
在相应的服务中托管 activity 解决了这个问题。 Temporal 支持无限期的活动。请注意，建议对长运行 活动使用检测信号，以确保及时检测到故障。
问题3
具体的解决方案取决于具体的要求。在大多数情况下，需要特定排序的日记条目应该从单个工作流中编排。
问题4
通过确保工作流代码最终完成的临时性使得支持补偿操作变得微不足道。这是一个SAGA example from Java SDK Samples repository.
问题5
只需将此补偿逻辑作为同一工作流程的一部分即可。
在当前的应用中，我们有三个服务：
- 发票
- 银行转帐：调用外部 API，这可能需要一分钟左右，具体取决于队列
- ledger：创建借贷分类账的内部微服务
为了交流，我们有一个编排传奇。流程基本上使用发票作为协调器：
- 发票服务向 rabbitmq 发布消息，要求为发票 X 付款
- 银行转账服务收听消息，获取发票 X
- 银行转账服务处理转账（调用银行的API）。支付成功后，发布消息到rabbitmq 'Invoice X paid'
- 发票服务监听消息'Invoice X paid'
- 发票服务发布消息'Create ledger for invoice X'并发布到rabbitmq
- 分类帐服务从 rabbitmq 监听消息 'Create ledger for invoice X'
- 分类帐服务创建适当的分类帐日记帐借方/贷方，然后发布 'ledger created for invoice X'
- 发票服务侦听消息 'ledger created for invoice X'，然后完成（关闭）交易
问题 1 如果我使用 Temporal 或 cadence（只是在寻找它），它们并不像上面那样依赖 pub-sub 模式。那么如何实现呢？
我在想 (CMIIW) :
- 创建
InvoiceActivity - 创建
BankTransferActivity - 创建
LedgerActivity - 创建
InvoicePaymentWorkflow
所有这些 Workflow 和 Activity 都是发票服务应用程序的一部分。但是 银行转账服务 和 分类帐服务 现在提供 API 来处理转账（根据银行转账，它实际上是 API 到外部银行调用的代理）， 分类帐服务 提供 API 创建 debit/credit 日志。
CMIIW，在这种情况下，我们不再需要在 bank transfer service 和 ledger service 上创建监听器（或 cadence / temporal activity） , 我们需要提供 API.
或者我想错了？ 银行转账服务和账本服务上应该有一些activity？但如果是这样，发票服务如何触发和安排工作流？
问题 2 但是现在调用是异步的。日志分类帐的创建实际上有一些验证，有时负载很重，因此取决于队列中的消息，从消息进入 rabbitmq 到日志实际创建可能需要 5 分钟。在 API 调用中，这将超时。
问题 3 那么竞争条件呢？一些日记帐按顺序创建。使用 rabbitmq，我们可以通过某些技术实现这一点（队列上的单个消费者，类似于 kafka 主题）。
问题 4 另外，如何处理补偿交易？如果分类账失败了，我们必须做点什么。在我们的案例中，我们必须通知会计人员，因为银行转账已经处理并且无法撤销。
问题 5 对于一些子公司，当分类帐失败时，我们仍然有控制权，因此我们可以补偿/提取发票金额，并将金额return退还给母公司。假设我们在 银行转账服务 上有一个监听器，我们如何触发补偿 API?
In cadence / Temporal，这个用例合适吗？如果是，如何处理上述问题？
谢谢
TLDR；此用例非常适合 Temporal，因为它极大地简化了您的代码和操作。
问题一
我建议在他们的相应服务中举办活动。因此 InvoiceActivity 应由发票服务托管，BankTransferActivity 应由银行转帐服务托管。这消除了创建同步 API 的需要，并确保工作流和 activity 实现之间的流控制。请参阅 this post 对此进行了更详细的解释。
只有在这种情况下，发票服务应用才会承载工作流代码。
问题二
在相应的服务中托管 activity 解决了这个问题。 Temporal 支持无限期的活动。请注意，建议对长运行 活动使用检测信号，以确保及时检测到故障。
问题3
具体的解决方案取决于具体的要求。在大多数情况下，需要特定排序的日记条目应该从单个工作流中编排。
问题4
通过确保工作流代码最终完成的临时性使得支持补偿操作变得微不足道。这是一个SAGA example from Java SDK Samples repository.
问题5
只需将此补偿逻辑作为同一工作流程的一部分即可。