Spring Cloud Stream 2.0中@InboundChannelAdapter与MessageChannel发消息差异

嘿，在Spring Cloud Stream 2.0 RC3里，你用到的这两种消息发送方式，核心差异主要在触发逻辑、适用场景和控制粒度上，我给你拆解清楚：

1. MessageChannel 主动发送模式 #

这种方式是最直接的业务驱动型发送，完全由你的代码掌控发送时机。你给出的代码示例：

public interface Chan { 
    @Output 
    MessageChannel sender(); 
} 

@SpringBootApplication 
@EnableBinding(Chan.class) 
public class TestApplication { 
    @Autowired 
    private Chan chan; 
    public void sendMessage() { 
        chan.sender().send(MessageBuilder.withPayload(obj).build()); 
    } 
}

• 只有当你在业务逻辑里显式调用sendMessage()时，消息才会被发送——比如用户下单完成后、数据更新成功后触发，完全贴合业务流程。
• 你可以通过MessageBuilder灵活定制每一条消息的细节：比如给消息加自定义headers（业务标识、优先级）、动态调整payload内容，控制粒度非常精细。
• 这种方式和业务代码耦合度较高，适合需要精准响应业务事件的场景。

2. @InboundChannelAdapter 自动调度发送模式 #

这是一种框架托管的自动发送模式，底层依赖Spring Integration的调度能力，不需要你手动触发发送。你的代码示例：

@Bean 
@InboundChannelAdapter(channel="sender") 
public MessageSource<Object> sendMessage(...) {
    return () -> MessageBuilder.withPayload(yourData).build();
}

• 你只需要实现MessageSource的receive()方法生成消息，框架会自动按照配置的规则（默认1秒轮询一次，也可以通过poller属性设置Cron表达式、固定延迟）调用这个方法，拿到消息后自动发送到指定通道。
• 完全不需要业务代码干预，适合周期性、定时性的消息生产场景——比如定时从数据库拉取待同步数据、定时采集系统监控指标上报。
• 消息生成逻辑封装在独立的Bean中，和业务代码解耦，符合关注点分离的设计原则。

核心差异总结 #

额外补充：其实@InboundChannelAdapter底层也是基于MessageChannel实现发送的，它相当于在基础的消息通道之上，封装了一层调度触发的逻辑，让你不用关心"什么时候发"，只需要专注于"发什么"。

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