1.场景描述
当我们的分布式系统建设到一定程度了，或者服务间是通过异步请求来通讯的，那么我们避免不了使用MQ来解决问题。
假如公司内部进行了业务合并或者整合，需要服务A和服务B通过MQ的方式进行消息传递，而服务A用的是RabbitMQ，服务B用的是Kafka，那么我要在服务里同时使用两个消息组件吗？
有没有一种技术让我们不再关注具体MQ的细节，只需要用一种适配绑定的方式呢？
当然有，cloud Stream就解决了这个问题。
2.什么是SpingCloud Stream？
官网地址：https://spring.io/projects/spring-cloud-stream
官方定义SpringCloud Stream是一个构建消息驱动微服务的框架。
应用程序通过inputs或者outputs来与SpringCloud Stream中的binder对象交互。
通过我们配置来binding(绑定)，而SpringCloud Stream的binder对象负责与消息中间件交互。
所以，我们只需要搞清楚如何与SpringCloud Stream交互就可以方便使用消息驱动的方式。
而通过Spring Interation来连接消息代理中间件以实现消息事件驱动。
SpringCloud Stream为一些供应商的消息中间件产品提供了个性化的自动化配置实现，引用了发布-订阅、消费组、分区的三个核心概念。
但是目前仅支持RabbitMQ、Kafka
3.设计理念
3.1引入Stream之前
- 生产者/消费者之间靠消息媒介Message传递信息内容
- 消息必须走特定的消息通道MessageChannel
- 消息通道里的消息，消费和收发都是靠消息通道的子接口SubscribableChannel，由MessageHandler消息处理器所订阅。
3.2Binder
在没有绑定器这个概念的情况下，我们的SpringBoot应用
要直接与消息中间件进行信息交互的时候，由于各消息中间件构建的初衷不同，它们的实现细节上会有较大的差异性。
通过定义绑定器作为中间层，完美地实现了应用程序与消息中间件细节之间的隔离。
通过向应用程序暴漏统一的Channel通道，使得应用程序不需要再考虑各种不同的消息中间件实现。
通过定义绑定器Binder作为中间层，实现了应用程序与消息中间件细节之间的隔离
3.3引入Stream之后
Binder：很方便的连接中间件，屏蔽差异
Channel：通道，是队列Queue的一种抽象，在消息通讯系统中就是实现存储和转发的媒介，通过Channel对队列进行配置。
Source和Sink：简单的可理解为参照对象是SpringCloud Stream自身，从Stream发布消息就是输出，接受消息就是输入。
4.Stream流程以及常用API
| 比较项目 | Topic模式 |
|---|---|
| Middleware | 中间件，目前只支持RabbitMQ和Kafka |
| Binder | 是应用与消息中间件之间的封装，目前实现了Kafka和RabbitMQ的Binder，通过Binder可以很方便的连接中间件，可以动态的改变消息类型(对应于Kafka的topic，RabbitMQ的exchange)，这些都可以通过配置文件来实现 |
| @Input | 注解标识输入通道，通过该输入通道接收的消息进入应用程序 |
| @Output | 注解标识输出通道，发布的消息将通过该通道离开应用程序 |
| @StreamListener | 监听队列，用于消费者的队列的消息接收 |
| @EnableBinding | 指信道channel和exchange绑定在一起 |
喜欢的朋友记得点赞、收藏、关注哦！！！
