我没有遇到很多将Play与akka-cluster后端和像Cassandra这样的NoSql商店结合起来的例子，所以我在实现这样一个系统时有一些不确定性。
为了具体而不是抽象地描述设置，我提出了一个例子，它代表了戏剧和akka可以发挥作用的一整类问题：
考虑： 数据库支持（让我们使用Cassandra集群）公路旅行应用程序，在旅行时，它建议兴趣点。用户拥有帐户，输入设置和一些首选项。这是一个旅行仪表板视图，包括旅行历史等。计划是使用Play和Angular作为Web应用程序，大多数Web应用程序是从数据库中提取用户数据和POI数据以及模板化，更新视图的简单案例。然而，在该区域中计算和排列POI的算法使得akka-cluster和actor模型成为引人注目的解决方案。它需要用户数据（每日更新）和POI数据（按位置更新）作为输入，然后根据该数据运行算法。
要点： - 提供请求的播放前端，并调用由数据库支持的服务以满足请求（获取用户数据，模板等） - akka集群后端，其从前端（或客户端）获得基于用户数据（即偏好，年龄，历史）对该区域中的兴趣点进行排名的请求。这也需要通过actor访问数据库。
部分讨论可能必然包括所选数据存储的最佳选择，但这里是高级解决方案：
将所有数据访问职责委托给akka集群，Play只转发“获取一些数据”请求以及“根据数据x，y和z做一些计算”请求到后端。这消除了多租户混淆
保留所有基本请求，以在播放端使用数据存储区数据填充模板，并仅将群集用于cpu密集型计算。播放前端转发计算请求。这意味着他们都可以访问cassandra集群（可怕吗？）
播放应用程序完成所有计算，Akka-http公开客户端的计算Api（角度，两个微服务都可以访问相同的cassandra集群
使用Akka-http和angular
很抱歉，如果这个问题太高级了。有什么想法吗？
答案 0 :(得分：1)
正如你所说，这是一个高级别的问题，但我认为你是在正确的轨道上，即你正在考虑不同的选择。另一个有用的事情是考虑每个选项的权衡。
更具体地说，我建议如下。基本上将责任分配给架构中的每个层（或环）。您应该能够独立部署和扩展每个层。
将所有数据访问和计算分配给Akka。这将允许您的Akka群集独立扩展。这也意味着您的用户界面层不了解您的数据存储。说明天你从Cassandra搬到HBase你的前端影响很小。
将所有与HTTP和用户界面相关的内容分配给Play。确保你没有在Play中保持任何状态。将所有状态推送到Akka或您的数据库。这将允许您水平缩放Play图层。
使用Spray REST服务为您的Akka群集提供数据端点。您可以在其间添加缓存层以加快访问速度。
我不建议删除Play，因为它提供的不仅仅是REST端点。
最后，根据我的经验，这不是“正确”的架构。它真的可以归结为您的特定需求和要求。