消息网关等待回复机制

在 Spring Integration 中，MessageGateway（通过@MessagingGateway接口定义）的等待回复行为取决于网关方法的返回类型，而非直接由通道类型决定。以下是关键机制分析：

非void返回类型：
如果网关方法声明了返回值（如 Object、String 等），网关会自动等待回复，直到：
- 收到下游的回复消息。
- 超过replyTimeout配置的时间（默认 1 秒），抛出MessageTimeoutException。
java
```
@MessagingGateway
public interface MyGateway {
    @Gateway(requestChannel = "requestChannel", replyTimeout = 5000)
    String sendAndWait(String data); // 会阻塞等待回复
}
```
void返回类型：
网关不会等待回复（fire-and-forget 模式），无论下游如何处理。
java
```
@Gateway(requestChannel = "fireAndForgetChannel")
void sendOnly(String data); // 立即返回
```

通道类型影响消息传递的同步性，但不改变网关的等待逻辑（等待由返回类型决定）：

DirectChannel（默认同步通道）：
- 在同一线程中同步执行整个消息流（包括请求和回复）。
- 看似“等待”：实际是线程阻塞直到流程完成。
- 示例：网关 → DirectChannel → 服务激活器（返回回复） → 网关接收回复。
ExecutorChannel/QueueChannel（异步通道）：
- 消息提交到线程池或队列后立即返回，不阻塞发送线程。
- 但若网关需要回复（非void方法）：
  1. 网关内部创建TemporaryReplyChannel。
  2. 发送消息时携带此临时通道。
  3. 网关在临时通道上阻塞等待，直到异步流程返回回复或超时。
- 示例：网关 → ExecutorChannel → 服务激活器（异步处理，返回回复到临时通道） → 网关接收回复。

临时回复通道：
当网关需要等待回复时，会自动创建一个TemporaryReplyChannel，并作为消息头MessageHeaders.REPLY_CHANNEL发送。下游组件需将回复发送到此通道。
同步与异步的统一性：
无论使用何种通道，只要网关方法声明了返回值，最终都会在TemporaryReplyChannel上阻塞等待。异步通道仅解耦了请求发送，但回复仍需通过临时通道同步返回。

总结：

最佳实践：
明确设计网关接口：需要回复时声明返回值；无需回复时用void。
同步处理用DirectChannel；异步处理用ExecutorChannel+线程池，但需注意回复超时配置。

消息网关等待回复机制 ​