akka - 何时使用 Actors 与 Futures？

Question

我目前正在制作一个 Play!具有以下架构的项目:

Controller -> 服务(参与者)-> 模型(常规案例类)

对于每个传入的请求，我们将调用服务层，如下所示:

Service ? DoSomething(request, context)

我们在应用程序初始化期间创建的 akka 路由器后面有一定数量的这些服务参与者，并且可以按需扩展。

在服务中，我们主要进行适度的数据操作或数据库调用:

receive = {
    case DoSomething(x, y) => {
           ...
           Model.doSometing(...)
           sender ! result
    }
}

我正在重新考虑我们是否应该将 Actor 用于我们的服务或仅使用 future 。

我们没有任何需要在服务参与者中修改的内部状态，无论收到什么消息都会进入一个函数并吐出结果。这不就是 Actor 模特的大实力吗？

我们正在做很多任务，这些任务似乎从 Actor 模型中带走了很多

我们没有进行繁重的计算，并且远程处理没有意义，因为大部分工作都是针对数据库的，并且不需要往返到远程参与者以进行一些数据库调用

我们确实使用了响应式mongo，因此每个数据库调用都是非阻塞的。我们可以打很多这样的电话

在我看来，删除 akka 并只使用 Futures 让我们的生活变得更轻松，而且我们并没有真正失去任何东西。

Answer 1

关于什么应该和不应该成为 Actor 的话题当然不乏意见。比如这两个帖子:

http://noelwelsh.com/programming/2013/03/04/why-i-dont-like-akka-actors/

http://www.chrisstucchio.com/blog/2013/actors_vs_futures.html

我不认为你会找到这个问题的绝对答案，除了它是情境的，它真的取决于你的喜好和你的问题。我能为您做的是提供基于我们实现 Akka 大约 2 年的意见。

对我来说，我喜欢将 Akka 真正视为一个平台。我们为 Actor 模型而来，但我们为平台提供的所有其他优点而停留，例如集群/远程处理、FSM、路由、断路器、节流等。我们正在尝试构建一个类似于 SOA 的架构，其中我们的参与者充当服务。我们正在跨集群部署这些服务，因此我们正在利用诸如位置透明度和路由之类的东西来为服务使用者(它本身可能是另一个服务)提供查找和使用服务的能力，无论它部署在哪里，并以高度可用的方式。 Akka 基于他们提供的平台工具使整个过程变得非常简单。

在我们的系统中，我们有我称之为基础服务的概念。这些是非常简单的服务(例如特定实体的基本查找/管理服务)。这些服务通常不调用任何其他服务，并且在某些情况下，只是执行数据库查找。这些服务是池化的(路由器)，通常没有任何状态。它们与您描述的某些服务非常相似。然后我们开始在这些基础服务之上构建越来越复杂的服务。这些服务中的大多数都是短暂的(避免询问)，有时基于 FSM，它们从基础服务收集数据，然后紧缩并因此做一些事情。尽管这些基础服务本身非常简单，有些人会说不需要 Actor ，但我喜欢这种灵 active ，当我将它们组合成更高级别的服务时，我可以查找它们并且它们可以在任何地方(位置透明) 在我的集群中，可以使用任意数量的实例(路由)。

所以对我们来说，将参与者作为一种类似微服务的基线实际上是一个设计决策，无论该服务多么简单，它都可以在我们的集群中供任何其他服务使用。我喜欢通过粗粒度的接口(interface)以异步方式与这些服务进行通信，无论它们在哪里。许多这些原则是构建良好 SOA 的各个方面。如果这是您的目标，那么我认为 Akka 对实现该目标非常有帮助。如果您不想做这样的事情，那么您质疑使用 Akka 为您的服务的决定也许是正确的。就像我之前所说的，从架构的角度来弄清楚你想要做什么，然后设计你的服务层来实现这些目标真的取决于你。