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之前

image.png

• 生产者/消费者之间靠消息媒介Message传递信息内容
• 消息必须走特定的消息通道MessageChannel
• 消息通道里的消息，消费和收发都是靠消息通道的子接口SubscribableChannel，由MessageHandler消息处理器所订阅。

3.2Binder

在没有绑定器这个概念的情况下，我们的SpringBoot应用
要直接与消息中间件进行信息交互的时候，由于各消息中间件构建的初衷不同，它们的实现细节上会有较大的差异性。
通过定义绑定器作为中间层，完美地实现了应用程序与消息中间件细节之间的隔离。
通过向应用程序暴漏统一的Channel通道，使得应用程序不需要再考虑各种不同的消息中间件实现。
通过定义绑定器Binder作为中间层，实现了应用程序与消息中间件细节之间的隔离

image.png

3.3引入Stream之后

image.png

Binder：很方便的连接中间件，屏蔽差异
Channel：通道，是队列Queue的一种抽象，在消息通讯系统中就是实现存储和转发的媒介，通过Channel对队列进行配置。
Source和Sink：简单的可理解为参照对象是SpringCloud Stream自身，从Stream发布消息就是输出，接受消息就是输入。

4.Stream流程以及常用API

image.png