Spring Integration & MQ 中设计超时处理

Question

我正在开发一个正在重组为一致异步的应用程序。它过去是，现在仍然是基于 Spring Integrations。作为支付网关，我可以参考ISO 20022标准，但这里我会为观众简化一下。

收到 PACS8（宣布收到付款的传入消息，为了简单起见）后，我们必须验证请求并在特定 SLA 内回复 PACS2（确认，肯定或否定）。一般来说，当超时发生时，我们可能会执行很多主动操作。调用 REST 或 JPA 调用时通常会发生超时。将远程端点视为余额检查、客户验证等。

带有同步代码的旧流程

使用同步 Spring Integration 流（不一定使用 Reactive），我们可以在 JPA 事务和 REST 客户端周围设置超时，以便异常导致消息转变为将被重定向到生成出站负 PACS2 的流的状态并通过 MQ 发送。

MQ 取代 REST 的新流程

现在，我们被要求将一些调用转换到 MQ（即 Red Hat Artemis），以便通过向远程服务（例如，检查客户帐户是否打开的服务）发送请求来中断流程

• PACS8已收到
• 生成一条新的 MQ 消息，其中包含一些在后续步骤中有用的标头
• 它被发送到远程（例如 IBAN 检查）服务
• ...（流程结束）
• 当收到新的MQ消息时，根据其状态，生成PACS2。标头用于恢复正确的

  Payment

但是我们这里缺少超时。如果远程服务在一定时间内没有响应，我们必须发送否定的 PACS2。

限制

在 PAAS 上运行的云就绪应用程序，所有实例一起运行的多个实例

问题，以及我的考虑

我可以在 MQ/JMS 中使用什么来处理异步请求/响应调用的超时，以便在发生超时时以云方式和简洁的设计执行操作？

我不会对远程服务使用

@Gateway

模式，因为它会阻塞线程。一般来说，当我们发送消息时，我需要结束流程。

我无法使用响应式框架，它是非阻塞的，但需要将 500 多个组件重写为新范例。并在整个调用期间将对象保留在 Pod 上的 RAM 中。

我目前可以想到一个基于数据库表的解决方案，其中超时表由 Spring Integration 轮询。这将是第二个选择，因为我不喜欢在高可用性系统上进行主动轮询（我的客户不会喜欢它......）。另外，通过下面的选项，我保证不处理并发和锁。

我想问一下，使用 Spring Integration、JMS 和 Artemis MQ 是否可以将消息发送到队列，并保证在一定时间之前不会被任何 JMS 侦听器处理。 我可以使用 Spring

.delay()

，从某种意义上说，当超时开始时，我们立即向

pub/sub

流发送消息并立即延迟*，但我并不完全喜欢这个解决方案，因为我更喜欢负载平衡跨 Pod 超时

有什么有用的想法吗？

[*] 当消息最终处理时，子流程将检查付款是否已验证

Answer 1

我只能考虑聚合器及其

groupTimeout

功能：https://docs.spring.io/spring-integration/reference/aggregator.html#agg-and-group-to。

因此，在您的情况下，您将请求发送到 MQ 以及聚合器，其逻辑是将组与回复或超时关联起来。该聚合器可以配置一个共享数据库来存储这些消息，并在发生超时时从其他节点获取回复。