解决痛点 ：屏蔽底层消息中间件的差异，降低切换成本，统一消息的编程模型
SpringCloud Stream 是一个构件消息驱动微服务的框架。
应用程序通过 消息的发送者和消费者（ inputs 或者 outputs ）来与 springcloud stream 中 绑定器（binder）对象交互。
通过我们配置来binding（绑定），而springcloud stream 的binder 对象负责与消息中间件交互。
所以我们只需要搞清楚如何与Springcloud Stream 交互就可以方便实用消息驱动的方式。
通过使用Spring Integration来连接消息代理中间件以实现消息事件驱动。
Springcloud Stream 为一些供应商的消息中间件产品提供了个性化的自动化配置实现，引用了发布-订阅、消费组、分区的三个核心概念。
标准 MQ
（1）生产者/消费者之间靠消息媒介传递消息内容
--- Message
（2）消息必须走特定的通道
--- 消息通道 MessageChannel
（3）消息通道里的消息如何被消费呢，谁负责收发处理
--- 消息通道MessageChannel里面的子接口 SubscribableChannel ，由于MessageHandler消息处理器所订阅 收发
那为什么要用Stream呢
就RabbitMQ 和 Kafka来讲，由于两个消息中间件的架构上不同，RabbitMQ有 exchange，kafka有 Topic 和 Partitions分区，此时就需要一个Destination Binder（目的地绑定器）；通过定义绑定器 Binder 作为中间层， 完美地实现了应用程序与消息中间件细节之间的隔离。通过向应用程序暴露统一的Channel通道，使得应用程序不需要再考虑各种不同的消息中间件实现。
Binder （Input 对于消费者 ，Output 对于生产者）
而Stream中的消息通信方式遵循了发布-订阅模式 ————Topic主题进行广播（RabbitMQ是exchange，Kafka是Topic）
Stream 标准流程及常用注解
消息生产者 ——业务逻辑——> Springcloud Stream (source、channel、binder) ——MQ组件（RabbitMQ/Kafka)——>
——MQ组件（RabbitMQ/Kafka)——> Springcloud Stream(Sink、channel、Binder) ——> 消息消费者
Binder 绑定器
连接中间件，屏蔽差异性
Channel，频道
通道，是队列Queue的一种抽象，在消息通讯系统中就是实现存储和转发的媒介，通过Channel对队列进行配置
Source 和Sink
简单的可以理解为参照对象是SpringCloud Stream自身，从Stream发布消息就是输出，接收消息就是输入。
相关注释，@Input、@Output、@StreamListener、@EnableBinding
@Input
注解标识输入通道，通过该输入通道接收到消息进入应用程序
@Output
注解标识输出赛道，发布的消息将通过该通道离开应用程序
@StreamListener
监听队列，用于消费者的队列的消息接收
@EnableBinding
指频道Channel和exchange/topic 绑定在一起
以@EnableBinding定义Source.class 作为消息的频道，再通过MessageChannel中的send方法，传递一个MessageBuilder.withPayload().build(); ---- 生产者
用@EnableBinding定义Sink.class作为消息的通道，再用@StreamListener给Sink.input做一个监听，获得到相应的MessageChannel ---- 消费者