Spring RESTful服务应用程序架构

时间:2011-10-13 02:53:47

标签: java spring java-ee soa saas

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

这里的想法是创建系统的体系结构,无论具体的数据库引擎或持久层如何,都能获得最大的好处。

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

情景一: 我们有一个复制的数据库(在开头没有)和不同的应用程序。每个应用程序代表战争,它有一个控制器,应用程序上下文,servlet xml。域和持久层作为maven lib导入 - 每个应用程序中都包含一个版本。

优点:

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

缺点:

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

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

优点:

  • 一个持久层 - 全功能的hibernate
  • 更多j2ee看起来有扩展到下一级别的选项 - 集成EJB并移动到应用服务器

缺点:

  • 一个巨大的战争应用程序更多努力维护
  • 不按第一种情况分发

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

我非常感谢你对这个案子的意见。

干杯

2 个答案:

答案 0 :(得分:1)

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

有几种解决方案可以解决完全问题:

陶土

查看Hibernate Distributed Cache Tutorial

还有一个较旧的幻灯片共享Scaling Hibernate with Terracotta可以提供图片中的点

的Infinispan

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


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

这完全取决于业务问题

当然distributed很酷且容错,而且, RAM和磁盘越来越便宜,所以“扩大规模”(并且有一些热的热复制品)实际上并不是那么糟糕=>这些是你所描述的“第二种”方法的道具。

但是,让我们说你采用方法#1。如果你这样做,你将来将从切换到NoSQL中受益,因为你现在有副本集/分片等等。实际上有几个节点支持这个概念。

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

除了您对业务的理解之外,这些问题还应该帮助您降落在#1或#2上。

答案 1 :(得分:0)

所以,这是非常晚的答案,但最后我准备好回答。我将在此处提供有关进一步开发REST服务应用程序的一些细节。

最后,我从tolitius的优秀答案中获得了解决方案#1,并选择在后期阶段迁移到解决方案#2。

这是应用程序架构 - 我稍后会添加图形。

持久性图层 - 这包含域模型,所有数据库操作。使用Spring Roo从数据库模型生成,生成存储库和服务层,以便以后轻松迁移。

商家图层 - 此处列出了操作所需的所有业务逻辑。此图层取决于持久性图层。

演示文稿图层验证,控制器调用商家图层。

所有这些都是在没有应用程序服务器附加功能的Tomcat上运行的。在以后的阶段,可以将其移动到应用程序服务器并完全实现服务定位器模式。

基础设施 - 具有地理负载均衡器的地理位置服务器,所有这些服务器之间的MySQL复制环以及一个备用服务器和一个备用服务器(如果发生故障)。

我的想法是制作更现代的系统架构,但根据我对Java技术的经验,这是一种“正常风险”的情况。

拥有更多经验 - 更美丽的解决方案:)期待这一点!

相关问题