简介
如果系统里同时存在多种MQ，可以使用使用Cloud Stream，只需要和Stream交互就可以进行管理。
一句话，屏蔽底层消息中间件的差异，降低切换成本，统一消息的编程模型
官网：https://spring.io/projects/spring-cloud-stream#overview
中文手册：
官方定义SpringCloud Stream是一个构建消息驱动微服务的框架
应用程序通过inputs 或者 outputs 来与SpringCloud Stream中binder对象交互。通过我们配置来binding（绑定），而SpringCloud Stream的binder对象负责与消息中间件交互，所以，我们只需要搞清楚如何与SpringCloud Stream交互就可以方便使用消息驱动的方式。
通过使用Spring Integration来连接消息代理中间件以实现消息时间驱动
SpringCloud Stream 为一些供应商的消息中间件产品提供了个性化的自动化配置实现，引用了发布-订阅、消费组、分区的三个核心概念。
目前只支持RabbitMQ、Kafka
设计思想介绍
标准的MQ：
生产者/消费者之间靠消息媒介传递信息内容——Message
消息必须走特定的通道——消息通道MessageChannel
消息通道里的消息如何被消费呢，谁负责收发处理——消息通道MessageChannel的子接口SubscribableChannel，由MessageHandler消息处理器所订阅
比方说我们用到了RabbitMQ和Kafka，由于这两个消息中间件的架构上的不同，像RabbitMQ有exchange，Kafka有Topic和Partition分区
这些消息中间件的差异性导致我们实际项目开发给我们造成了一定的困扰，我们如果用了两个消息队列中的一种，后面的业务需求，我们想往另一种消息队列进行迁移，这时候无疑就是灾难性的，一大堆东西都要重新推倒重新做，因为它跟我们的系统耦合了，这时候SpringCloud Stream给我们提供了一种解耦合的方式
如何实现？
在没有绑定器这个概念的情况下，我们的SpringBoot应用要直接与消息中间件进行信息交互的时候，由于各消息中间件构建的初衷不同，它们的实现细节上会有较大的差异性，通过定义绑定器作为中间层，完美的实现了应用程序与消息中间件细节之间的隔离。通过向应用程序暴露统一的channel通道，使得应用程序不需要再考虑各种不同的消息中间件实现。
通过定义绑定器Binder作为中间层，实现了应用程序与消息中间件细节之间的隔离。
Binder：INPUT对应于消费者，OUTPUT对应于生产者
Stream中的消息通信方式遵循了发布-订阅模式，Topic主题进行广播（在RabbitMQ就是Exchange，在Kafka是Topic）
Stream标准流程套路
Binder：很方便的连接中间件，屏蔽差异
Channel：通道，是队列Queue的一种抽象，在消息通讯系统中就是实现存储和转发的媒介，通过Channel对队列进行配置
Source和Sink：简单的可以理解为参照对象是SpringCloud Stream自身，从Stream发布消息就是输出，接收消息就是输入
编码API和常用注解
来源：CSDN
作者：TheNoOne--
链接：https://blog.csdn.net/qq_41211642/article/details/104915177