spring 6 移除了已废弃的 amqp remoting 模块，推荐使用 rabbittemplate 的 sendandreceive 方法配合 @rabbitlistener 实现轻量、可控的 rpc 调用。
spring 6 移除了已废弃的 amqp remoting 模块，推荐使用 rabbittemplate 的 sendandreceive 方法配合 @rabbitlistener 实现轻量、可控的 rpc 调用。
在 Spring AMQP 6.x 中，原生的 AMQP remoting（如 AmqpInvokerServiceExporter 和 AmqpInvokerProxyFactoryBean）已被彻底移除，因其设计耦合度高、抽象层级过重，且与现代消息驱动架构理念不符。官方明确建议转向更底层、更灵活的原语式通信模式：基于请求-响应语义的手动消息收发。
核心替代方案如下：
✅ 客户端（调用方）：使用 RabbitTemplate.sendAndReceive() 发送请求并同步等待带 reply-to 头的响应消息；
✅ 服务端（被调用方）：通过 @RabbitListener 监听请求队列，处理后手动构造响应并发送回 replyToAddress 指定的临时或固定响应队列。
示例代码：
// 客户端：发起 RPC 调用
@Service
public class OrderClient {
private final RabbitTemplate rabbitTemplate;
public OrderClient(RabbitTemplate rabbitTemplate) {
this.rabbitTemplate = rabbitTemplate;
// 启用自动回复队列（默认启用，确保 reply-to 可用）
rabbitTemplate.setReplyTimeout(10_000);
rabbitTemplate.setReceiveTimeout(10_000);
}
public String createOrder(String orderJson) {
Message request = MessageBuilder.withBody(orderJson.getBytes())
.setContentType(MessageProperties.CONTENT_TYPE_JSON)
.build();
Message response = rabbitTemplate.sendAndReceive("order.requests", request);
return new String(Objects.requireNonNull(response).getBody());
}
}// 服务端：处理 RPC 请求并响应
@Component
public class OrderService {
@RabbitListener(queues = "order.requests")
public Message handleOrderRequest(Message request) {
String payload = new String(request.getBody());
// 执行业务逻辑（如创建订单）
String result = "{\"status\":\"success\",\"orderId\":\"ORD-2024-789\"}";
// 构造响应消息，自动复用 replyTo 地址
return MessageBuilder.withBody(result.getBytes())
.setContentType(MessageProperties.CONTENT_TYPE_JSON)
.build();
}
}⚠️ 注意事项：
- sendAndReceive 默认依赖 RabbitMQ 的 reply-to 机制（自动创建临时响应队列），需确保 broker 支持且客户端/服务端均未禁用；
- 若需自定义响应队列（如持久化、重试），可显式设置 MessageProperties.setReplyTo(...) 并手动监听该队列；
- 响应超时、消息丢失、序列化不一致等问题需自行增强容错（如添加重试、熔断、JSON Schema 校验）；
- 避免在高并发场景下滥用同步 RPC；对异步解耦要求高的场景，建议直接采用事件驱动（Event Sourcing / CQRS）而非模拟远程方法调用。
总结：Spring AMQP 的“去 Remoting”并非功能倒退，而是回归消息中间件本质——以显式、可观测、可调试的消息交互替代黑盒式远程调用。掌握 sendAndReceive + @RabbitListener 组合，不仅能平滑升级至 Spring 6+，更能构建更健壮、更符合云原生演进方向的分布式通信层。
