Spring Boot应用混合使用Spring AMQP与Spring Cloud Stream RabbitMQ的问题排查

我最近在迁移一个Spring Boot微服务时遇到了Spring AMQP和Spring Cloud Stream混用的坑，在这里分享下我的问题场景和解决过程：

业务场景 #

我的服务原本是通过Spring AMQP从服务器A的3个RabbitMQ队列消费数据，存入Redis后，再把消息发送到服务器B的RabbitMQ交换机供其他服务消费，整个流程运行正常。我原本想把整个流程都迁移到Spring Cloud Stream，计划配置两个绑定器：一个连服务器A做消费者，另一个连服务器B做生产者，把代码改成Processor模式，但最后放弃了这个方案——原因有两个：一是多绑定器场景下暂时没法设置连接名称；二是要消费服务器A的多个队列，bindingRoutingKey属性不支持多值（虽然知道可以用编程方式实现，但不想额外改太多代码）。

所以最终我决定只重构生产者部分：保留原有的Spring AMQP代码从服务器A消费，用Spring Cloud Stream来实现向服务器B发送消息。

遇到的核心问题 #

一开始启动服务就报错，抛出NonUniqueBeanDefinitionException，提示存在两个org.springframework.messaging.handler.annotation.support.MessageHandlerMethodFactory类型的Bean，名称分别是handlerMethodFactory和integrationMessageHandlerMethodFactory，分别由Spring AMQP和Spring Cloud Stream创建。

我一开始尝试自己定义一个加了@Primary注解的MessageHandlerMethodFactory Bean来解决启动问题，但新的问题又来了：Spring Cloud Stream并没有使用我配置的服务器B连接，反而用了Spring AMQP的服务器A连接去创建输出通道，完全不符合预期。

最终解决步骤 #

后来我一步步排查，终于解决了所有问题：

• 连接问题：通过配置多绑定器属性，让Spring Cloud Stream正确使用服务器B的连接（虽然目前多绑定器还不支持设置连接名称，但暂时不影响业务）
• Bean冲突问题：发现之前的NonUniqueBeanDefinitionException根源是我自定义的ConditionalGenericConverter导致的，把它换成MessageConverter之后，就不再需要那个加了@Primary的Bean了，Bean冲突和连接错误的问题都彻底解决了。

使用的版本信息 #

• Spring AMQP：2.1.8-RELEASE（基于Spring Boot 2.1.7）
• Spring Cloud Stream：2.1.3.RELEASE（Greenwich.SR2）

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