1. 消息驱动概述 1.1 是什么
在实际应用中有很多消息中间件，比如现在企业里常用的有ActiveMQ、RabbitMQ、RocketMQ、Kafka等，学习所有这些消息中间件无疑需要大量时间经历成本，那有没有一种技术，使我们不再需要关注具体的消息中间件的细节，而只需要用一种适配绑定的方式，自动的在各种消息中间件内切换呢？消息驱动就是这样的技术，它能 屏蔽底层消息中间件的差异，降低切换成本，统一消息的编程模型。
SpringCloud Stream是一个构件消息驱动微服务的框架。应用程序通过inputs和outputs来与SpringCloud Stream中的绑定器（binder）对象交互，通过配置来绑定，而SpringCloud Stream的绑定器对象负责与消息中间件交互，所以，我们只需要搞清楚如何与SpringCloud Stream交互就可以方便使用消息驱动的方式。但是 截至到目前 SpringCloud Stream仅支持RabbitMQ和Kafka。
1.2 设计思想标准MQ模型
生产者 / 消费者之间靠消息媒介传递信息内容 - Messag
消息必须走特定的通道 - Message Channel
消息通道里的消息如何被消费呢？谁负责处理？ - 消息通道 MessageChannel 的子接口 SubscribableChannel，由 MessageHandler 消息处理器所订阅
为什么使用Cloud Stream
比如说我们用到了RabbitMQ和Kafka，由于这两个消息中间件的架构上的不同，像RabbitMQ有exchange，Kafka有Topic和Partitions分区，这些中间件的差异性导致实际项目开发给我们造成了一定的困扰，我们如果用了两个消息队列的其中一种，后面的业务需求如果又要往另外一种消息队列进行迁移，这无疑是一个灾难，一大堆东西都要重新推到重做，因为它跟我们的系统耦合了，这时候SpringCloud Stream给我们提供了一种解耦合的方式。
stream凭什么可以统一底层差异
在没有绑定器这个概念的情况下，我们的SpringBoot应用要直接与消息中间件进行信息交互的时候，由于各消息中间件构建的初衷不同，它们的实现细节上会有较大的差异性。
通过定义绑定器作为中间层，完美的实现了 应用程序与消息中间件细节之间的隔离。Stream对消息中间件的进一步封装（通过向应用程序暴露统一的Channel通道，使得应用程序不需要再考虑各种不同的消息中间件实现），可以做到代码层面对中间件的无感知，甚至于动态的切换中间件（如RabbitMQ切换为Kafka），使得微服务开发的高度解耦，服务可以更多的关注自己的业务流程。
在消息绑定器中，INPUT对应于消费者，OUTPUT对应于生产者。
Stream中的消息通信方式遵循了 发布-订阅模式，用Topic（主题）进行广播（RabbitMQ中对应于Exchange交换机，Kafka中就是Topic）。
1.3 SpringCloud Stream标准流程套路Binder 很方便的连接中间件，屏蔽差异
Channel 通道，是队列Queue的一种抽象，在消息通讯系统中就是实现了存储和转发的媒介，通过Channel对队列进行配置
Source 和 Sink 简单的可以理解为参照对象是SpringCloud Stream自身，从Stream发布消息就是输出，接受消息就是输入
Middleware 中间件，目前只支持RabbitMQ和Kafka
Binder Binder是应用与消息中间件之间的封装，目前实行了RabbitMQ和Kafka的Binder，通过Binder可以很方便的连接中间件，可以动态的改变消息类型（对应于Kafka的topic，RabbitMQ的exchange），这些都可以通过配置文件来实现
@Input 注解标识输入通道，通过该输入通道接收到的消息进入应用程序
@Output 注解标识输出通道，发布的消息将通过该通道离开应用程序
@StreamListner 监听队列，用于消费者的队列的消息接收
@EnableBinding 使信道Channel和交换机/主题（Exchange/Topic）绑定在一起
2. Spring Cloud Stream 案例