目前，我们正在使用Spring，Hibernate，MySQL和tomcat构建Web服务应用程序。我们没有使用真正的应用服务器 - SoA架构。关于持久层 - 今天我们正在使用Hibernate和MySQL，但是一年后我们可能最终得到MongoDB和Morphia。
这里的想法是创建系统的体系结构，无论具体的数据库引擎或持久层如何，都能获得最大的好处。
让我解释一下 - https://s3.amazonaws.com/creately-published/gtp2dsmt1。我们在这里有两个案例：
情景一： 我们有一个复制的数据库（在开头没有）和不同的应用程序。每个应用程序代表战争，它有一个控制器，应用程序上下文，servlet xml。域和持久层作为maven lib导入 - 每个应用程序中都包含一个版本。
优点：
缺点：
场景二 - 一个具有内部逻辑的应用程序，用于拆分和组织不同的服务 - 新闻和用户。
优点：
缺点：
我更喜欢第一种情况，但我担心Hibernate在这种情况下的行为以及我可以从中获得的所有好处。
我非常感谢你对这个案子的意见。
干杯
答案 0 :(得分：1)
有几种解决方案可以解决完全问题：
查看Hibernate Distributed Cache Tutorial
还有一个较旧的幻灯片共享Scaling Hibernate with Terracotta可以提供图片中的点
查看Using Infinispan as JPA-Hibernate Second Level Cache Provider
使用第一个解决方案（分布式）可能是正确的方法。
这完全取决于业务问题
当然distributed很酷且容错，而且，但 RAM和磁盘越来越便宜，所以“扩大规模”（并且有一些热的热复制品）实际上并不是那么糟糕=＆gt;这些是你所描述的“第二种”方法的道具。
但是，让我们说你采用方法＃1。如果你这样做，你将来将从切换到NoSQL中受益，因为你现在有副本集/分片等等。实际上有几个节点支持这个概念。
但是......必须具有100％的一致性吗？ （例如，产品是否与money有关）。你有多大计划成为=＆gt;你准备好维护数百台服务器吗？您是否需要运行速度超过十二小时的复杂聚合查询？
除了您对业务的理解之外，这些问题还应该帮助您降落在＃1或＃2上。
答案 1 :(得分：0)
所以，这是非常晚的答案，但最后我准备好回答。我将在此处提供有关进一步开发REST服务应用程序的一些细节。
最后，我从tolitius的优秀答案中获得了解决方案＃1，并选择在后期阶段迁移到解决方案＃2。
这是应用程序架构 - 我稍后会添加图形。
持久性图层 - 这包含域模型，所有数据库操作。使用Spring Roo从数据库模型生成，生成存储库和服务层，以便以后轻松迁移。
商家图层 - 此处列出了操作所需的所有业务逻辑。此图层取决于持久性图层。
演示文稿图层验证，控制器调用商家图层。
所有这些都是在没有应用程序服务器附加功能的Tomcat上运行的。在以后的阶段，可以将其移动到应用程序服务器并完全实现服务定位器模式。
基础设施 - 具有地理负载均衡器的地理位置服务器，所有这些服务器之间的MySQL复制环以及一个备用服务器和一个备用服务器（如果发生故障）。
我的想法是制作更现代的系统架构，但根据我对Java技术的经验，这是一种“正常风险”的情况。
拥有更多经验 - 更美丽的解决方案:)期待这一点！