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)

或者继续使用现有的Service层并仅使用Akka Actors中的那些方法？保持服务层原样的风险是,所有服务方法都将保持公开,并且可以从其他任何地方自由调用(如果有人直接在控制器中调用Service方法(通过传递Actors)或其他东西,则打破模式).

Answer 1

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

• Actor只是一个多线程抽象,例如TaskExecutors
• 演员是商业建模的基础,例如GhostActor在吃豆人游戏中.

您需要问自己,您希望在重构时遵循哪一个.为什么呢.

您提到的第一个选项(Actors通过Futures与服务交谈)是一个多线程抽象.当你遇到一个主要的性能瓶颈时,你想要做到这一点.可能演员可以提供帮助,但还有许多其他工具可以做到这一点.

您提到的第二个选项(Actors replace Services)使用actor进行业务域建模.它非常强大.你把你的逻辑放在演员中,演员由较小的演员组成,演员由较小的演员组成,依此类推.它们中的每一个都代表了您的业务领域的一小部分.演员越小越好.使用此方法有许多优点:

• 每个参与者都可以在内部使用不同的策略来获取和存储信息.其中一些可能通过Futures使用HTTP服务,其中一些可能使用actor通信,其中一些可能是事件源.
• 您可以在整个系统中使用声明性和人类可理解的抽象:Actor.你只需要把你的大脑从思考技术障碍转向考虑业务障碍.
• 当您遵循一些简单的技术规则时,您的系统内置了可扩展性,而不会过多地考虑它.经过一段时间后,这些规则成为第二种性质.

当然,还有一些缺点:

• 有些业务领域无法轻松地与演员建模.
• 您正在使您的系统完全依赖于一个工具包.

我希望这能以某种方式帮助你.如果你想对某些事情采取后续行动,那就大声说出来吧.谢谢!