Question

我有多个用例，需要根据某些用户操作触发预定义事件。

e.g。假设在应用程序中创建NewUser时，它必须异步调用CreateUserInWorkflowSystem和FireEmailToTheUser。还有许多此类业务案例，其中事件将基于用例预定义。我可以使用Promises / Futures对这些事件进行建模，如下所示

if 'NewUser' then 
    call `CreateUserInWorkflowSystem` (which will be Future based API)
    call `FireEmailToTheUser` (which will be Future based API)
if 'FileImport' then
   call `API3` (which will be Future based call)
   call `API4` (which will be Future based call)

所有这些Future调用都必须在某处记录失败，以便重试失败的呼叫等。注意NewUser调用不会等待那些Futures（每个事件的事件）到完整。

那是使用普通的Futures/Promises API。不过我认为Akka Persistence适合此处，阻止调用仍然会遇到Futures。随着Akka持久性，处理失败将很容易，因为它提供了开箱即用等。我理解Akka持久性仍处于实验阶段，但这似乎并不是一个大问题，因为类型安全通常在推广之前将这些新框架保持为实验状态进入未来发布等（Macros也是如此）。鉴于这些要求，您认为Futures/Promises或Akka持久性更适合这里吗？

Answer 1

这是一个基于意见的问题 - 不是要求SO的最佳类型。无论如何，试图回答。

这实际上取决于您对要求的舒适度以及要求的含义。您是否需要在单个JVM 之后扩展系统 - 使用Akka。你想保持更多简单 - 使用Futures。

如果使用Futures，您可以存储要在作业队列/ db中执行的所有状态和操作。这很合理。

如果你使用Akka Persistence，那么显然它会帮助你持久化。 Akka将有助于执行 supervison ，恢复和重试更轻松。如果您的CreateUserInWorkflowSystem操作失败，结果将传播给监督演员，该演员可能重新启动失败的演员并使其重试N次。如果您的监督演员失败，那么他的主管将做正确的事情，或者最终整个应用程序将崩溃，这是好的。使用Futures，您必须自己实现此机制，并确保应用程序在需要时可能崩溃。

如果您完全独立行动，那么期货和演员的声音大致相同。如果你必须连锁行动和撰写它们，那么使用期货将是一件更自然的事情： for comprehensions 等。在Akka你必须等待消息并基于消息类型执行下一个操作。

尝试使用两者来模拟一个简单的实现，并根据您的特定应用程序要求比较您喜欢/不喜欢的内容。总的来说，这两个选择都很好，但在这种情况下，我略微倾向于演员。

基于事件的设计 - 期货，承诺与Akka持久性

1 个答案: