Akka. 我应该将所有服务/DAO实现为actor吗？

Question

在Java世界中，使用三层架构（表示层、服务层和DAO层）设计应用程序被认为是最佳实践。但我的当前应用程序使用Scala和Akka。在我的一个actor中，在收到一些消息后，我需要从数据库中检索国家列表。如果我使用Java，最有可能创建CountryService接口及其实现，以及相应的CountryDao和实现。但是，Akka的处理方式是什么呢？我应该通过actor包装CountryService吗？我认为这是个坏主意，因为在这种情况下，我的actor在收到某些消息后需要发送另一个消息来检索所有国家，并在回应原始发送者之后响应。

- WelcomeTo

---

Akka与您的N层架构没有直接关系。在Akka中，您的演员应该自己处理他们需要完成的工作。顺便说一下，似乎您并不理解Akka所涵盖的用例。 - Luiggi Mendoza

@LuiggiMendoza 那我应该将序数服务与Actor混合使用吗？也就是说，我应该按照Java的方式创建CountryService并将其注入到我的Actor中以供进一步使用（而不是使用另一个Actor支持CountryService）？ - WelcomeTo

Answer 1

这仅基于我在Akka上的经验，其他人可能会持不同意见。

如果你的国家Actor没有状态，那就不要将其作为Actor。只需简单地使用Scala的Future API并将其返回到调用它的Actor中。这样，数据库调用可以在与您的Actors完全不同的执行上下文中运行（您不应在Actors内部进行阻塞调用）。如果你正在考虑缓存，那么我的观点是缓存仍然不是真正的状态，并且使用Guava Cache是线程安全且很方便。

因此，它将看起来像这样：

class MyActor(countryService: CountryService) extends Actor {
  // ...
  val result: Future[Countries] = countryService.getCountries
  result.pipeTo(self)
  // ...
  def recieve = {
    case Countries(c) => // use c
  }
  // ...
}

有时候您可能希望将其封装为单独的CountryActor，但这些情况比较特殊：例如，您严重依赖Actor路径并希望访问特定路径上的服务Actor，想要特别处理错误、具有一些重试逻辑等。

- Akos Krivachy

Answer 2

演员的数量与层数/服务数量无关。您可以在每个服务中有数千个演员，也可以没有。这取决于该上下文中演员是否有用。

使用演员对许多事情都很有用：隐藏状态、负载平衡和将工作分配给子代、使用“让它崩溃”模型实现容错：将危险的工作委派给子代并选择监督策略。

创建和使用演员非常便宜，发送消息也是如此。但当然，并非所有情况都需要它们。问问自己：演员在这里带来了什么优势？

- Quizzie