Spring RESTful服务应用架构
目前我们正在使用 Spring、Hibernate、MySQL 和 tomcat 构建 Web 服务应用程序。我们没有使用真正的应用服务器 - SoA 架构。关于持久层——今天我们使用 Hibernate 和 MySQL，但一年后我们可能最终会使用 MongoDB 和 Morphia。
这里的想法是创建系统架构，无论具体的数据库引擎或持久层如何，并获得最大的利益。
让我解释一下 - https://s3.amazonaws.com/creately-published/gtp2dsmt1 。我们这里有两种情况：
情况一： 我们有一个可复制的数据库（一开始没有）和不同的应用程序。每个应用程序都代表一个有其控制器、应用程序上下文、servlet xml 的战争。域和持久层作为 maven lib 导入 - 每个应用程序中都包含一个版本。
优点：
- 易于维护的小型应用程序
- 分布式解决方案 - 例如，每个应用程序都可以移动到它自己的 tomcat 实例或不同的计算机
缺点：
- 使用休眠会话并在不同应用程序之间同步它时可能会出现问题。我不知道这种实现方式是否可行。
场景二 - 一个应用程序具有内部逻辑来拆分和组织不同的服务 - 新闻和用户。
优点：
- 一个持久层 - 具有 hibernate 的全部功能
- 更多 j2ee 外观以及扩展至下一个级别的选项 - 集成 EJB 并转移到应用程序服务器
缺点：
- 一个巨大的战争应用程序需要更多的维护工作
- 不像第一个场景那样分发
我更喜欢第一个 场景但我担心在这种情况下 Hibernate 的行为以及我可以从中获得的所有好处。
我将非常感谢您对此案的意见。
干杯
Currently we are building web services applications with Spring, Hibernate, MySQL and tomcat. We are not using real application server- SoA architecture. Regarding the persistence layer - today we are using Hibernate with MySQL but after one year we may end up with MongoDB and Morphia.
The idea here is to create architecture of the system regardless concrete database engine or persistence layer and get maximum benefits.
Let me explain - https://s3.amazonaws.com/creately-published/gtp2dsmt1. We have two cases here:
Scenario one:
We have one database that is replicated (in the beginning no) and different applications. Each application represents on war that has it's one controllers, application context, servlet xml. Domain and persistence layer is imported as maven lib - there is one version for it that is included in each application.
Pros:
- Small applications that are easy to maintain
- Distributed solution - each application can be moved to it's own tomcat instance or different machine for example
Cons:
- Possible problems when using hibernate session and sync of it between different applications. I don't know that is possible at all with that implementation.
Scenario two - one application that has internal logic to split and organize different services - News and User.
Pros:
- One persistence layer - full featured of hibernate
- More j2ee look with options to extend to next level- integrate EJB and move to application server
Cons:
- One huge war application more efforts to maintain
- Not distribute as in the first scenario
I like more the first scenario but I'm worried about Hibernate behavior in that case and all benefits that I can get from it.
I'll be very thankful for your opinion on that case.
Cheers
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
有几个解决方案可以解决这个确切问题：
Terracotta
看看 Hibernate 分布式缓存教程
另外还有一个有点旧的幻灯片分享使用 Terracotta 扩展 Hibernate，在图片中传达要点
Infinispan
看看 < a href="https://docs.jboss.org/author/display/ISPN/Using+Infinispan+as+JPA-Hibernate+Second+Level+Cache+Provider" rel="nofollow noreferrer">使用 Infinispan 作为 JPA-Hibernate 二级缓存提供程序
采用第一个解决方案（分布式）可能是正确的方法。
这一切都取决于业务问题是什么
当然
分布式很酷并且具有容错能力，并且，..但是 RAM和磁盘正在变得越来越多越来越便宜，所以“扩展”（并拥有几个热副本）实际上并不是那么糟糕=>这些是您描述的“第二种”方法的支撑。但假设您采用方法#1。如果您这样做，将来您将受益于切换到 NoSQL，因为您现在拥有副本集/分片等，并且实际上有多个节点来支持该概念。
但是.. 100% 一致性是必须具备的吗？ （例如，该产品是否与金钱有关）。你打算变得多大=>您准备好维护数百台服务器了吗？您是否有需要运行速度超过十个小时的复杂聚合查询？
除了您对业务的了解之外，这些问题还应该帮助您找到#1 或#2。
There are a couple of solutions that solve this exact problem:
Terracotta
Take a look at Hibernate Distributed Cache Tutorial
Also there is a bit older slide share Scaling Hibernate with Terracotta that delivers the point in pictures
Infinispan
Take a look at Using Infinispan as JPA-Hibernate Second Level Cache Provider
Going with the first solution (distributed) may be the right way to go.
It all depends on what the business problem is
Of course
distributedis cool and fault tolerant and, and,.. but RAM and disks are getting cheaper and cheaper, so "scaling up" (and having a couple hot hot replicas) is actually NOT all that bad => these are props to the the "second" approach you described.But let's say you go with the approach #1. If you do that, you would benefit from switching to NoSQL in the future, since you now have replica sets / sharding, etc.. and actually several nodes to support the concept.
But.. is 100% consistency something that a must have? ( e.g. does the product has to do with money ). How big are you planning to become => are you ready to maintain hundreds of servers? Do you have complex aggregate queries that need to run faster than xteen hours?
These are the questions that, in addition to your understanding of the business, should help you land on #1 or #2.
所以，这是一个很晚的答案，但我终于准备好回答了。我将在此处提供有关进一步开发 REST 服务应用程序的一些详细信息。
最后，我从 tolitius 的出色答案中找到了解决方案#1，并可以选择在稍后阶段迁移到解决方案#2。
这是应用程序架构 - 我稍后会添加图形。
持久层 - 该层保存域模型、所有数据库操作。使用 Spring Roo 从数据库模型生成，生成存储库和服务层，以便以后轻松迁移。
业务层 - 这里位于操作所需的所有业务逻辑。该层依赖于持久性层。
表示层验证，控制器调用业务层。
所有这些都在 Tomcat 上运行，无需额外的应用程序服务器。在后期阶段，可以将其移至应用程序服务器并完全实现服务定位器模式。
基础设施 - 具有地理负载平衡器的地理定位服务器、所有服务器之间的 MySQL 复制环以及一台备份服务器和一台备份服务器以防发生故障。
我的想法是制作更现代的系统架构，但根据我使用 Java 技术的经验，这是一种“正常风险”情况。
有了更多的经验 - 更漂亮的解决方案:) 期待这一点！
So, this is very late answer for this but finally I'm ready to answer. I'll put some details here about further developing of the REST service application.
Finally I landed on solution #1 from tolitius's great answer with option to migrate to solution #2 on later stage.
This is the application architecture - I'll add graphics later.
Persistence layer - this holds domain model, all database operations. Generated from database model with Spring Roo, generated repository and service layer for easy migration later.
Business layer - here is located all the business logic necessary for the oprations. This layer depends on Persistence layer.
Presentation layer validation, controllers calling Business layer.
All of this is run on Tomcat without Application server extras. On later phase this can be moved to Application server and implement Service locator pattern fully.
Infrastructure - geo located servers with geo load balancer, MySQL replication ring between all of them and one backup server and one backup server in case of fail.
My idea was to make more modern system architecture but from my experience with Java technology this is a "normal risk" situation.
With more experience - more beautiful solutions :) Looking forward for this!