我建议的可能听起来很奇怪,但我有我的理由.

很长一段时间,我们已经有了这个基于Spring的API,它起源于CRUD功能的一组抽象REST服务.然而,随着时间的推移,我们开始构建业务和表示层,直到我们达到死胡同状态.不要误解我的意思,Spring / Hibernate是很棒的框架,构建在JVM之上有其明显的优势,包括性能优于其他Web技术,如PHP.与PHP相比,它为我们提供了更深入的控制方式,如事务处理,多线程处理,处理字节数据,控制本机C应用程序,使用JNI等.

堆栈明显碰到硬墙的地方,是需求最常变化的地方,即业务层和表示层.将应用程序转变为现代的,以用户为中心的社交应用程序,我们经历了职业生涯中最严峻的挑战. Java EE演示技术难以使用.此外,由于构建测试和部署大型Java应用程序的传统障碍,改变业务需求变得非常漫长.

它也感觉在很大程度上,我们正试图重新发明轮子.在PHP世界中,已经存在许多项目,它们为您提供了一个完整的管理系统,与任何类型的后端系统无关(映射挂钩到REST / SOAP端点).他们中的许多人已准备好所有这些功能,允许管理员友好地改变各种各样的情况,规则,模板等.另外,基于PHP意味着绝对没有时间浪费在构建和部署上.写下变更,测试,确认它有效,并切换.

我们现在的想法是找到一种方法来在这种基于PHP的前端服务器应用程序中移动业务和表示层,并将纯后端内容留给Spring / Hibernate.我们有一些担忧,来自我们对Spring的相对缺乏经验.

>如果我们使用PHP方法实现业务方法,我们如何保持事务安全性？我的意思是,如果一个业务方法必须向JAVA发出三个单独的HTTP请求,那么我们怎样才能保证它们都将在同一个事务中执行,DB-wise？
>有没有办法在两个系统之间使用代理或承诺对象？例如,如果PHP业务方法需要调用Spring搜索方法从数据库中获取对象的集合,然后将其传递给另一个spring方法,这将意味着必须来回传送整个集合.也许,人们可以将它存储在JAVA端的会话对象中,并简单地将一个空代理发送回前端,前端可以将其反馈回另一个jav方法.
>我们很多基于Spring的功能都依赖于使用Spring事件的插件结构.我们如何才能使我们的前端服务器在每个发生的ackend事件上得到通知.
我在这里有两个想法：一个后处理过滤器,它只是使用一些命名约定向前端服务器上的控制器发出POST请求.
或者…使用某种消息队列,例如JMS或RabbitMQ,或者为什么甚至不能像Reddis那样可以观察数据的变化

谁曾经这样做过？总的来说这是个好主意吗？有任何建议如何解决上述问题？