3

我知道这对很多人来说似乎很明显，但我的客户正在使用一种我不太方便的模式。

案例是，他们的客户发送存款或取款，通过 nservicebus 发送到第三方系统。第三方系统需要处理该交易，但可能需要数天，甚至数周才能完成交易。

今天的解决方案是创建一个 saga，它首先发送一条消息，将交易交给第三方系统。完成后，sagas 下一步是检查完成更新。如果事务未完成，则会发送 requesttimeout，“就像等待”。当达到超时时，再次执行相同的检查并发送新的 requesttimeout ......等等。这是一个永恒的循环。它所做的其他事情就是一遍又一遍地用相同的 SagaTimeout 完全填充 ServiceInsight。

我一直在研究单反，但似乎人手不足。我只需要对特定消息而不是所有消息进行多次重试。

另外，第三方系统无法发送交易已完成的事件，这意味着我们需要轮询完成更新。

另一个，我认为更好的解决方案是保存交易状态，将交易发送给第三方并完成这个特定的传奇。然后有一个使用时间间隔检查完成更新的传奇。

以这种方式使用 sagatimeouts 是一种常见的模式吗？而且，让 saga/handler 只检查完成更新是不是更好的解决方案？

4

2 回答 2

3

据我所知，您正在按照应有的方式进行操作。当然，您可以启动一个单独的 saga 来处理超时，但我认为没有任何好的理由这样做。

由于您不知道第三方系统上的事务/流程何时完成，因此对于最终用户而言，它对时间不是很敏感，因此您不需要经常请求超时。您甚至可以计算 saga 数据中的超时次数并增加下一次超时的时间跨度，从而最大限度地减少超时次数。您还可以检查 saga 运行了多长时间，并在第三方系统“太长时间”完成交易时提醒某人（您或客户等）。这是 NSB sagas 真正闪耀的地方，它在处理这些情况时非常灵活。

当然不要将 SLR 用于此类事情，它仅用于在发生间歇性错误时重试处理程序。

于 2015-11-04T08:56:43.513 回答
0

IMO 听起来您的传奇将技术问题（轮询外部服务，等待某事发生）与域问题（希望在发生该事情时得到通知）混合在一起。

我的经验是，您通常可以从将您的领域内容与技术内容隔离开来受益，在这种情况下，这可能意味着您应该将轮询放在某个地方的集成服务中，然后当事情发生时它会发出适当的事件。

这样，saga 可能会在整个过程中超时（例如，检查过程是否在四个星期内完成，或者您认为它必须在任何人之前花费的最长时间）并且只需TransactionCompleted从集成服务订阅事件.

于 2015-11-05T07:20:37.340 回答