java - Spring RESTful服务应用架构

Question

目前我们正在使用 Spring、Hibernate、MySQL 和 tomcat 构建 Web 服务应用程序。我们没有使用真正的应用服务器 - SoA 架构。关于持久层 - 今天我们使用 Hibernate 和 MySQL，但一年后我们可能最终会使用 MongoDB 和 Morphia。

这里的想法是创建系统架构，无论具体的数据库引擎或持久层如何，并获得最大的利益。

让我解释一下 - https://s3.amazonaws.com/creately-published/gtp2dsmt1 。我们这里有两个案例:

场景一: 我们有一个可复制的数据库(一开始没有)和不同的应用程序。每个应用程序都代表一个有其 Controller 、应用程序上下文、servlet xml 的 war 。域和持久层作为 maven lib 导入 - 每个应用程序中都包含一个版本。

优点:

• 易于维护的小型应用程序
• 分布式解决方案 - 例如，每个应用程序都可以移动到它自己的 tomcat 实例或不同的计算机

缺点:

• 使用 hibernate session 及其在不同应用程序之间同步时可能出现的问题。我不知道这种实现方式是否可行。

场景二 - 一个应用程序具有内部逻辑来拆分和组织不同的服务 - 新闻和用户。

优点:

• 一个持久层 - Hibernate 的全部功能
• 更多 j2ee 外观以及扩展至下一个级别的选项 - 集成 EJB 并迁移到应用程序服务器

缺点:

• 一个巨大的 war 应用需要更多的努力来维护
• 不像第一种情况那样分发

我更喜欢第一种情况，但我担心这种情况下的 Hibernate 行为以及我可以从中获得的所有好处。

我将非常感谢您对此案的意见。

干杯

Answer 1

• 使用 hibernate session 及其在不同应用程序之间同步时可能出现的问题。我不知道这种实现是否可行。

<小时/>

有几个解决方案可以解决这个确切问题:

Terracotta

看看Hibernate Distributed Cache Tutorial

还有一个有点旧的幻灯片共享 Scaling Hibernate with Terracotta传达图片中的要点

无限跨度

看看Using Infinispan as JPA-Hibernate Second Level Cache Provider

<小时/>

采用第一个解决方案(分布式)可能是正确的方法。

这完全取决于业务问题是什么

当然分布式很酷并且具有容错能力，而且，..但是 RAM和磁盘变得越来越便宜，所以“扩展”(并且有一个几个热热副本)实际上并不是那么糟糕 => 这些是您描述的“第二种”方法的支持。

但是假设您采用方法#1。如果您这样做，将来您将受益于切换到 NoSQL，因为您现在拥有副本集/分片等，并且实际上有多个节点来支持该概念。

但是.. 100% 一致性是必须具备的吗？ (例如，该产品是否与 money 有关)。您计划发展到多大 => 您准备好维护数百台服务器了吗？您是否有需要运行速度超过十个小时的复杂聚合查询？

除了您对业务的了解之外，这些问题还应该帮助您找到#1 或#2。