14. Stream消息驱动概述
1. Spring Cloud Stream概述
1.1 Spring Cloud Stream是什么？
Spring Cloud Stream官网：SpringCloud Stream官网
Spring Cloud Stream是构建消息驱动的微服务应用程序的框架。Spring Cloud Stream基于Spring Boot建立独立的生产级Spring应用程序，并使用Spring Integration提供与消息代理的连接。SpringCloud Stream 为一些供应商的消息中间件产品提供了个性化的自动化配置实现，引用了发布-订阅、消费组、分区的三个核心概念。
1.2 Spring Cloud Stream可以帮我们解决什么？
当分布式系统越来越复杂，以及调用的系统之间可能采用不同的中间件处理时，都会面临中间件技术切换、维护、开发等等复杂的工作。例如RabbitMQ 和 Kafka 两个消息中间件在架构上不同。例如 RabbitMQ 有 exchange，Kafka 有 Topic 和 Partitions分区，所以二者不能够直接互通。
而Spring Cloud Stream通过定义绑定器 Binder 作为中间层，向应用程序暴露统一的 channel通道实现了应用程序与消息中间件细节之间的隔离。屏蔽了各种MQ的底层差异而达到对MQ的统一管理，让我们不再关注具体的MQ的细节，只需要通过交互SpringCloud Stream，就能操作各种MQ，降低切换、维护、开发工作。
小结：Spring Cloud Stream可以帮我们屏蔽底层消息中间件的差异，降低切换维护成本，统一消息的编程模型（声明和绑定频道），另外同Spring Cloud Bus一样Stream目前仅支持RabbitMQ、Kafka。
1.3 Spring Cloud Stream标准流程
- Source/Sink：Source 输入消息，Sink 输出消息
- Channel：通道，是队列 Queue 的一种抽象，在消息通讯系统中就是实现存储和转发的媒介，通过Channel 对队列进行配置；
- Binder：很方便的 连接中间件，屏蔽 MQ 之间的差异
2. 主要概念
Spring Cloud Stream提供了一些简化了消息驱动的微服务应用程序编写的抽象和原语：
- Spring Cloud Stream的应用模型
- Binder抽象
- 持续的发布 - 订阅支持
- 消费者群体支持
- 分区支持
- 一个可插拔的Binder API
2.1 Spring Cloud Stream的应用模型
一个Spring Cloud Stream应用程序由一个中间件中立的核心组成。该应用程序通过Spring Cloud Stream注入到其中的输入和输出通道与外界进行通信。应用程序通过 inputs 或者 outputs 来与 SpringCloud Stream 中的 binder（绑定器） 对象交互。通过我们配置来 binding（绑定），而SpringCloud Stream 的 binder 对象负责与消息中间件交互。 
| 应用模型各组成 | 应用模型中各组成说明 |
|---|---|
| Middleware | 中间件，目前只支持 RabbitMQ 和 Kafka |
| Binder | Binder 是应用于消息中间件之间的封装，可以动态的改变消息类型 |
| @Input | 注解标识输入通道，通过改输入通道接收到的消息进入应用程序 |
| @Output | 注解标识输出通道，发布的消息通过该通道离开应用程序 |
| @StreamListener | 监听队列，用于消费者队列的消息接收 |
| @EnableBinding | 指信道 channel 和 exchange 绑定在一起 |
2.2 Binder抽象
Binder 是应用于消息中间件之间的封装，目前实现了 RabbitMQ 和 Kafka 的Binder。
Spring Cloud Stream使用Spring Boot进行配置，Binder抽象使得Spring Cloud Stream应用程序可以灵活地连接到中间件。例如，部署者可以在运行时动态地选择通道连接的目的地（例如，Kafka主题或RabbitMQ交换）。可以通过外部配置属性和Spring Boot（包括应用程序参数，环境变量和application.yml或application.properties文件）支持的任何形式提供此类配置。
Spring Cloud Stream自动检测并使用类路径中找到的binder。您可以使用相同的代码轻松使用不同类型的中间件：在构建时只包含不同的绑定器。对于更复杂的用例，您还可以在应用程序中打包多个绑定器，并在运行时选择绑定器，甚至是否为不同的通道使用不同的绑定器。
2.3 持续的发布 - 订阅支持
应用之间的通信遵循发布订阅模式，其中通过共享主题广播数据。
发布订阅通信模型降低了生产者和消费者的复杂性，并允许将新应用程序添加到拓扑中，而不会中断现有流。例如，在平均计算应用程序的下游，您可以添加一个计算显示和监视的最高温度值的应用程序。然后，您可以添加另一个解释相同的故障检测平均流程的应用程序。通过共享主题而不是点对点队列进行所有通信可以减少微服务之间的耦合。 
2.4 消费者群体支持(消费者组)
Spring Cloud Stream消费者组与Kafka消费者组相似： 每个消费者绑定可以使用spring.cloud.stream.bindings..group属性来指定组名称。对于下图所示的消费者，此属性将设置为spring.cloud.stream.bindings..group=hdfsWrite或spring.cloud.stream.bindings..group=average。 
订阅给定目标的所有组都会收到已发布数据的副本，但每个组中只有一个成员从该目的地接收给定的消息。默认情况下，当未指定组时，Spring Cloud Stream将应用程序分配给与所有其他消费者组发布 - 订阅关系的匿名独立单个成员消费者组。
持久化:符合Spring Cloud Stream的有意义的应用模式，消费者群体订阅是持久的。也就是说，绑定实现确保组预订是持久的，一旦已经创建了一个组的至少一个订阅，即使组中的所有应用程序都被停止，组也将接收消息。
通常，当将应用绑定到给定目的地时，最好始终指定消费者组。在扩展Spring Cloud Stream应用程序时，必须为每个输入绑定指定一个使用者组。这样可以防止应用程序的实例收到重复的消息。
匿名订阅本质上是不耐用的。对于某些binder实现（例如RabbitMQ），可以具有非持久组的订阅。
2.5 分区支持
Spring Cloud Stream提供对给定应用程序的多个实例之间的分区数据的支持。在分区场景中，物理通信介质（例如，代理主题）被视为被构造成多个分区。一个或多个生产者应用程序实例将数据发送到多个消费者应用程序实例，并确保由共同特征标识的数据由相同的消费者实例处理。
Spring Cloud Stream提供了统一方式实现分区处理用例的通用抽象。因此，无论代理本身是否自然分区（例如Kafka）（例如RabbitMQ），分区可以被使用。
2.6 编程模型
Spring Cloud Stream提供了许多预定义的注释，用于声明绑定的输入和输出通道，以及如何收听频道。
- 自定义频道名称 使用@Input和@Output注释，您可以指定频道的自定义频道名称
- 预定义接口： 为了方便寻址最常见的用例，涉及输入通道，输出通道或两者，Spring Cloud Stream提供了开箱即用的三个预定义接口：Source（出站通道），Sink（入站通道）和Processor
简单理解从Stream发布消息就是输出，接受消息就是输入。
3. 项目集成
项目集成详情参看：Spring Cloud Stream消息驱动项目集成