如何用Spring Boot+MQ V9替换旧IBM MQ V7批处理Java应用

核心前提：匹配原有批处理调度逻辑 #

你的原有系统是通过Shell脚本调度执行的一次性批处理（启动→执行收发→退出），方案选择首先要对齐这个核心模式，同时兼顾Spring Boot和MQ V9的特性。

1. 优先推荐：封装为带参数的可执行Spring Boot Jar #

如果要完全兼容原有调度逻辑，没必要在REST和@JmsListener里二选一，直接把收发逻辑封装成Spring Boot的CommandLineRunner或ApplicationRunner实现类：

• 发送逻辑对应SendMessageRunner，接收逻辑对应ReceiveMessageRunner
• 启动时通过命令行参数切换模式，比如：

  # 发送消息（替代原sendMessage.ksh）
  java -jar mq-batch-app.jar --app.mode=send
  # 接收消息（替代原receiveMessage.ksh）
  java -jar mq-batch-app.jar --app.mode=receive
  

• 原有调度配置几乎不用修改，只需要替换脚本里的Java调用命令即可，完全继承原有批处理的执行模式

2. 若限定在REST和@JmsListener中二选一 #

消息发送场景

• REST端点：适合需要外部触发发送的场景（比如其他系统调用、手动触发），但如果只是调度触发，会多一层网络依赖（脚本需要用curl/httpie调用接口），不如直接执行Jar简洁高效
• @JmsListener是监听消费的注解，和发送逻辑无关，不适用

消息接收场景

• 不推荐@JmsListener（原有批处理模式下）：@JmsListener是常驻监听消费模式，启动后会一直运行并监听队列，和你原有「启动一次消费一批就退出」的批处理逻辑完全不符。除非你打算把接收逻辑改成持续消费的常驻服务，否则不适用
• REST端点：如果用REST做接收，需要调度脚本调用接口触发一次消费操作，本质上是把批处理逻辑放到接口里执行，虽然可行，但不如直接用可执行Jar高效

3. 若重构为常驻服务模式 #

如果计划放弃原有批处理，改成持续运行的服务：

• 消息接收：@JmsListener是Spring整合IBM MQ的标准最佳实践，支持并发消费、异常重试、事务管理、MQ V9的高级特性（比如共享订阅），稳定性和可维护性远高于手动编写的接收逻辑
• 消息发送：如果发送触发源多样（调度、外部调用、内部事件），REST端点是灵活的选择；如果只是定时发送，用Spring的@Scheduled配合MQ发送逻辑即可，无需REST

决策速查表 #

内容的提问来源于stack exchange，提问作者dreamer