用于请求-响应模式的 JMS

Question

我们计划使用 Java 实施我们的新系统。由于系统的性质，它需要与各种 intr.net/extr.net/inte.net 系统进行交互，并与各种外部系统共享相同的逻辑（稍作调整），我们计划将业务逻辑移出前端，做成服务，计划用JMS打通表现层和业务逻辑层。 表示层发送请求，业务逻辑层发送处理结果的响应。

在做了一个小型的 POC 系统之后，我们发现这种方式非常有前途。 但是 Oracle 的人（我们计划将 weblogic 用于 ap 服务器和 JMS 服务器）说总会有性能问题，因为消息队列的本质不是请求-响应模式。

Oracle小哥的意见有什么建议吗？ 我们对 Java 世界相当陌生（完全没有关于 java 的经验，必须在内部实施这个系统，没有外包选项），尽管我们以每秒大约 300 次请求响应测试了我们的 POC（这似乎足以满足我们的需求）系统），我们还不确定系统上线后是否一定会出现性能下降...

Answer 1

绝对不是这样的性能问题。

由于 JMS 的事务性质，您会损失一点。 来自表示层的消息必须在业务层开始处理之前记录在日志中，类似地必须在表示层开始处理回复之前记录回复。

然而，这个小缺点被在重负载期间并行处理的能力以及在极端负载下安全排队请求的能力所弥补。 （在这些情况下，RPC 应用程序就会死掉，JMS 只会变慢）。

主要问题是处理异步环境中的错误。 如果您的表示层发送请求，在假设业务服务器端出现问题之前，它应该合理地等待回复多长时间？ 如果表示层炸毁了您应该如何处理回复消息，尤其是当它是某种更新时？ 所有这些问题都可以解决，但是，您需要考虑如何处理。