我想标题已经说得很清楚了。我不是可伸缩性专家。我即将创建一个web应用程序，它需要扩展到大型数据集，并且可能有许多(这里不会夸张，假设有数千)并发用户。
MongoDB是数据存储库，我在写一个简单的Play! web应用程序与MongoDB对话，而Play!应用程序与一个REST服务应用程序(在Scala中)对话之间挣扎，后者完成了所有业务逻辑和持久性的繁重工作。
我认为将业务逻辑包装为服务是未来的证明，并且允许在多个节点中部署web应用程序(可扩展)。我来自Java EE stack and Play!是Java web框架中的叛逆者。这种方法可以让我远离Play!如果需要。
我的一部分也认为Play!app + Scala服务app是额外的复杂性，从长远来看可能不会有成果。
欢迎提出任何建议。
注意:我是Scala, MongoDB和Play的新手。如果我的问题很愚蠢，请原谅。
可伸缩性是一门工程艺术。这意味着你有很多参数，并将你的经验应用于这些参数的特定值，以得到一个解决方案。所以，如果没有关于你的问题的更具体的数据，一般的建议是很难的。
话虽如此，从经验来看，一些一般建议:
- 保持你的应用程序尽可能的干净和简单。这让你有更多的选择余地。在你的情况下，从一个简单的Play应用程序开始。专注于干净的代码，这样你就可以轻松地将你拥有的东西重新制作成不同的架构模型(使用干净的代码，这比你想象的要简单:-))测量，而不是猜测，瓶颈在哪里。向服务器发送大量请求非常简单。使用分析、内存转储等方法来精确定位可伸缩性的瓶颈。
只有这样，有了一个可用的应用程序(你可以提前发布)和关于你的扩展瓶颈在哪里的数据，你才能决定把什么分成(水平扩展的)服务。
一开始，服务看起来很好且可扩展，但它们通常会让您陷入早期的混乱—服务需要相互通信，因此您开始引入消息传递等。保持简单，衡量，优化。
这个问题看起来并不傻。对我来说，将数据访问封装在rest层之后并不能直接提高应用程序的可伸缩性。(当然，重要的是，服务器可以执行HTTP缓存和处理请求队列等。(但从您的描述来看，您的应用程序看起来足够小)。您可以在没有Rest层的情况下实现类似的可伸缩性。但话虽如此，服务层可能会产生间接影响。
首先，它使您的应用程序更干净。(UI与db对话是混乱的。)它有助于使应用程序易于维护。(多折叠)。Rest层可以为您提供应用程序中可能需要的中间层。另外，正确设计的Rest层必须是资源驱动的。根据我的经验，资源驱动架构是介于易于实现和高度可伸缩设计之间的一个很好的中间地带。
所以我强烈建议你使用服务层(Rest是最好的方式:))，但是可伸缩性本身并不能证明这个决定是正确的。
将服务放在UI和数据源之间封装了数据源，因此UI不需要知道数据如何持久化的细节。它还可以防止UI直接访问数据源。这允许服务根据需要进行身份验证、授权、验证、绑定和执行业务逻辑。
缺点是应用程序的速度略有下降。
我想说，增加这项服务的成本很小，但好处很大。我会投赞成票的
和往常一样，答案是。视情况而定。如果涉及到一些繁重的工作和一些业务逻辑:是的，最好把它放在自己的层中，如果你向它添加一个RESTful接口，你可以为任何你想要的前端技术提供服务。
现在，人们通常不需要一个单独的web应用程序层，而是通过AJAX直接向客户端提供数据。
如果您需要维护大量用户会话状态或有机会在表示层上缓存数据，则可以考虑添加一个层。为什么需要一个表示层还有更多的原因，例如，为不同的设备/客户端提供不同的表示。
不要为了复杂而添加图层。
我可能会补充说，你应该尝试使用HATEOAS原则。