Spring Cloud Stream简介

为什么Spring Cloud中要提供一个类似于消息驱动的Spring Cloud Stream。如果通过java历史上的分布式开发机构大家不能发现，对于消息系统，实际上最初的SUN公司是非常看重的，所有在EJB的时代里面专门提供有消息驱动Bean（Message Driven Bean、MDB）利用消息驱动Bean可以进行消息的处理操作。

利用消息驱动bean这种模式可以简化用户的操作复杂度，直接传递一些各类的数据即可实现业务的处理操作。于是在SpringBoot之中为了方便开发者去整合消息组件，也提供了一系列的处理支持，但是如果按照这些方式来在SpringCloud之中进行消息处理，有些人会认为比较麻烦，所以在SpringCloud里面将消息整合的处理操作进行了进一步的抽象操作，实现了更加简化的消息处理。

SpringCloudStream就是实现了MDB的功能，同时可以更加简化方便的整合消息组件。

BinderBinder 是 Spring Cloud Stream 的一个抽象概念，是应用与消息中间件之间的粘合剂。目前 Spring Cloud Stream 实现了 Kafka 和 Rabbit MQ 的binder。通过 binder ，可以很方便的连接中间件，可以动态的改变消息的 destinations（对应于 Kafka 的topic，Rabbit MQ 的 exchanges），这些都可以通过外部配置项来做到。甚至可以任意的改变中间件的类型而不需要修改一行代码。

Publish-Subscribe消息的发布（Publish）和订阅（Subscribe）是事件驱动的经典模式。Spring Cloud Stream 的数据交互也是基于这个思想。生产者把消息通过某个 topic 广播出去（Spring Cloud Stream 中的 destinations）。其他的微服务，通过订阅特定 topic 来获取广播出来的消息来触发业务的进行。这种模式，极大的降低了生产者与消费者之间的耦合。即使有新的应用的引入，也不需要破坏当前系统的整体结构。

Consumer Groups“Group”，如果使用过 Kafka 的童鞋并不会陌生。Spring Cloud Stream 的这个分组概念的意思基本和 Kafka 一致。微服务中动态的缩放同一个应用的数量以此来达到更高的处理能力是非常必须的。对于这种情况，同一个事件防止被重复消费，只要把这些应用放置于同一个 “group” 中，就能够保证消息只会被其中一个应用消费一次。

Durability消息事件的持久化是必不可少的。Spring Cloud Stream 可以动态的选择一个消息队列是持久化，还是 present。

Bindingsbindings 是我们通过配置把应用和spring cloud stream 的 binder 绑定在一起，之后我们只需要修改 binding 的配置来达到动态修改topic、exchange、type等一系列信息而不需要修改一行代码。