springcloud微服务学习笔记（六十）：Stream的设计思想

springcloud微服务学习笔记目录：
springcloud微服务学习笔记

设计思想
标准MQ

1.生产者/消费者之间靠消息媒介传递信息内容（message）
2.消息必须走特定的通道（消息通道MessageChannel
）
3.消息通道里的消息如何被消费呢，谁负责收发处理（消息通道MessageChannel的子接口SubscribableChannel，由MessageHandler消息处理器所订阅
）

为什么用Cloud Stream
比方说我们用到了RabbitMQ和Kafka，由于这两个消息中间件的架构上的不同，像RabbitMQ有exchange，kafka有Topic和Partitions分区，

这些中间件的差异性导致我们实际项目开发给我们造成了一定的困扰，我们如果用了两个消息队列的其中一种，后面的业务需求，我想往另外一种消息队列进行迁移，这时候无疑就是一个灾难性的，一大堆东西都要重新推倒重新做，因为它跟我们的系统耦合了，这时候springcloud Stream给我们提供了一种解耦合的方式。

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

通过定义绑定器Binder作为中间层，实现了应用程序与消息中间件细节之间的隔离。

Binder
在没有绑定器这个概念的情况下，我们的SpringBoot应用要直接与消息中间件进行信息交互的时候，由于各消息中间件构建的初衷不同，它们的实现细节上会有较大的差异性.通过定义绑定器作为中间层，完美地实现了应用程序与消息中间件细节之间的隔离。Stream对消息中间件的进一步封装，可以做到代码层面对中间件的无感知，甚至于动态的切换中间件(rabbitmq切换为kafka)，使得微服务开发的高度解耦，服务可以关注更多自己的业务流程

通过定义绑定器Binder作为中间层，实现了应用程序与消息中间件细节之间的隔离。

INPUT对应于消费者
OUTPUT对应于生产者

Stream中的消息通信方式遵循了发布-订阅模式
Topic主题进行广播（在RabbitMQ就是Exchange
，在Kakfa中就是Topic）