scala - Akka Actors 可以替代服务层吗？

Question

这更像是一个设计和最佳实践问题。我正在转换一个应用程序以使用 Actors 和 Futures。目前这些是层(在 Akka 混合之前)。

Play Controller -> Service layer -> (Slick) DAOs

现在想要像

Play Controller -> Actors ->Services (Now they'll return Futures) ->DAO

在这样做时，我发现由于原始服务层具有所需业务逻辑的所有方法，Actors 层看起来就像一个中介。想知道现在一切都将通过 Actors 来摆脱服务层是否可以(从设计的角度来看)？

Play controller->Actors (with business methods) -> business methods calling into DAO (which Service methods were doing before)

还是继续使用现有的服务层并仅使用 Akka Actors 中的那些方法？保持服务层原样的风险是，所有服务方法都将保持公开状态并且可以从其他任何地方自由调用(打破模式~如果有人直接在 Controller 中调用服务方法(通过传递 Actor )或其他东西)。

Answer 1

基于actor的系统设计有两种方法:

Actors 只是一个多线程抽象，例如TaskExecutor s

Actor 是商业建模的基础，例如GhostActor在吃 bean 人游戏中。

您需要问问自己，在重构中您希望遵循哪一个。 为什么。

您提到的第一个选项(Actors 通过 Futures 与服务对话)是多线程抽象。当您刚刚遇到主要的性能瓶颈时，您想这样做。可能 Actor 可以提供帮助，但还有许多其他工具可以做到这一点。

您提到的第二个选项(参与者替换服务)使用参与者进行业务域建模。 它非常强大。 你把你的逻辑放在 Actor 身上， Actor 由较小的 Actor 组成，由较小的 Actor 组成，依此类推。它们中的每一个都代表了您业务领域的一小部分。 Actor 越小越好。使用这种方法有很多优点:

这些参与者中的每一个都可以在内部使用不同的策略来获取和存储信息。其中一些可能通过 Futures 使用 HTTP 服务，其中一些可能使用 actor 通信，其中一些可能是事件源的。

您有一个声明式且易于理解的抽象，可以在整个系统中使用: Actor .您只需要将您的大脑从考虑技术障碍转向考虑业务障碍。

当您遵循一些简单的技术规则时，您的系统内建了可扩展性，而无需过多考虑。一段时间后，这些规则成为第二天性。

当然，也有一些缺点:

有些业务领域无法轻松地与参与者建模。

您正在使您的系统完全依赖于一个工具包。

我希望这能以某种方式帮助你。如果你想跟进某件事，只需大声喊出来。谢谢!