哪个可扩展？简单的CRUD Webapp与Webapp通信与REST服务

Question

我认为标题清楚地表明了这一点。我不是可扩展性的大师。我即将创建一个Web应用程序，该应用程序需要扩展到大型数据集，并且可能需要很多（不会夸大这里，数千个）并发用户。

MongoDB是数据存储库，我在写一个简单的Play! webapp与MongoDB和Play!应用程序交谈与REST服务应用程序（在Scala中）之间徘徊不定这可以解决所有业务逻辑和持久性问题。

我的一部分认为将业务逻辑包装为服务是未来的证明，并允许在多个节点中部署webapp（扩展）。我来自Java EE堆栈和Play！是java web框架中的反叛者。这种方法向我保证我可以远离Play！如果需要的话。

我的一部分也认为玩！ app + Scala服务应用程序是一个额外的复杂性，从长远来看可能不会有成效。

任何建议都表示赞赏。

注意：我是Scala，MongoDB和Play的新手！请原谅我，如果我的问题很愚蠢。

Answer 1

可扩展性是一种工程艺术。这意味着您拥有大量参数并将您的经验应用于这些参数的特定值以获得解决方案。因此，如果没有关于您的问题的更具体数据，一般建议很难。

根据经验，提出了一些一般性建议：

• 让您的应用程序尽可能简洁明了。这允许您保持选项打开。在您的情况下，从一个简单的Play应用程序开始。专注于干净的代码，这样您就可以轻松地将所拥有的内容重新编写到不同的架构模型中（使用干净的代码，这比您想象的更简单： - ））
• 测量，而不是猜测，瓶颈在哪里。它足够简单，可以使服务器充满请求。使用分析，内存转储等来确定可伸缩性的瓶颈。

只有这样，有了手头的工作应用程序（您可以提前启动）和有关缩放瓶颈的数据，您就可以决定分割（水平可扩展）服务的内容。

一开始，服务看起来很好，可扩展，但它们经常让你陷入困境 - 服务需要彼此沟通，所以你开始介绍消息传递等等。保持简单，衡量和优化。

Answer 2

这个问题似乎并不愚蠢。对我来说，将数据访问封装在其余层后面并没有直接提高应用程序的可伸缩性。（显然，当然，有服务器可以执行http缓存并处理请求队列等等。但是根据你的描述，你的应用程序看起来很像够小的）。没有Rest层，您可以实现类似的可伸缩性。但话说回来，服务层可能会产生间接影响。

首先它使您的应用程序更清洁。 （UI与数据库交谈很麻烦。）它有助于使应用程序可维护。 （多重折叠）。 Rest层可以为您提供应用程序中可能需要的中间层。正确设计的Rest Layer也必须是资源驱动的。根据我的经验，资源驱动架构是易于实施和高度可扩展设计之间的良好中间环节。

所以我强烈建议您使用服务层（Rest是可行的方法:)），但可扩展性本身无法证明决策的合理性。

Answer 3

在UI和数据源之间放置服务会封装数据源，因此UI无需知道数据持久性的详细信息。它还可以防止UI直接进入数据源。这允许服务根据需要进行身份验证，授权，验证，绑定和执行业务逻辑。

缺点是应用程序略有减速。

我认为添加服务的成本很低，而且上涨空间很大。我会为此投票。

Answer 4

答案就像往常一样。这取决于。 如果涉及到一些繁重的工作和一些业务逻辑：Yup，最好放入自己的层，如果你添加一个RESTful接口，你可以将它提供给你想要的任何前端技术。

如今，人们通常不会因为拥有单独的网络应用层而烦恼，而是通过AJAX直接向客户提供数据。

如果您需要维护大量用户会话状态或有机会在表示层上缓存数据，则可以考虑添加图层。您需要表示层的原因有很多，例如，为不同的设备/客户端提供不同的演示文稿。

不过，不要只为复杂性添加图层。

我可以补充一点，你应该尝试采用HATEOAS原则。在扩展解决方案时，这将显着减轻事情。