本文为Spring Cloud Stream文档的中文翻译，原文地址：
https://cloud.spring.io/spring-cloud-static/spring-cloud-stream/3.0.3.RELEASE/reference/html/spring-cloud-stream.html
另外，Spring Cloud 版本：Hoxton.SR3，支持的 Spring Boot 版本：2.2.5.RELEASE
Spring Cloud Stream提供了许多抽象和术语，简化了微服务应用消息驱动的编写。本节概述内容如下：
-
Spring Cloud Stream 模型
-
Binder 抽象
-
持久化发布-订阅支持
-
消费者组支持
-
分区支持
-
可插拔的Binder SPI
应用模型
Spring Cloud Stream 应用由与中间件无关的核心组成。该应用程序通过在外部代理暴露的目的地（destinations）和代码里 input/output 参数建立绑定，与外部通信。建立绑定所需的特定代理的详细信息由特定于中间件的 Binder 实现处理。
可执行JAR
可以从你的 IDE 以独立模式运行 Spring Cloud Stream 应用来进行测试。要在生产环境中运行 Spring Cloud Stream 应用，你可以使用为 Maven 或 Gradle 提供的标准 Spring Boot 工具来创建可执行（“fat”）JAR。有关更多详细信息，请查看 Spring Boot Reference Guide。
Binder 抽象
Spring Cloud Stream 为 Kafka 和 RabbitMQ 提供了 Binder 实现。该框架还包括一个测试 Binder，用于对Spring Cloud Stream 应用进行集成测试。有关更多详细信息，请参见 Testing 部分。
Binder 抽象也是框架的扩展点之一，这意味着你可以在 Spring Cloud Stream 之上实现自己的 Binder。在 如何从头开始创建一个 Spring Cloud Stream Binder 中，详细发布了社区成员文档，并附带示例，其中包含了实现自定义 Binder 所需的一些步骤。在 Implementing Custom Binders 部分中重点介绍了这些步骤。
Spring Cloud Stream 使用 Spring Boot 进行配置，而 Binder 抽象使Spring Cloud Stream应用程序可以灵活地连接到中间件。例如，部署者可以在运行时动态选择外部目标（例如 Kafka topics 或 RabbitMQ exchanges）与消息处理器的输入和输出（例如函数的输入参数及其返回参数）之间的映射。可以通过外部配置属性以及Spring Boot支持的任何形式（包括应用程序参数，环境变量和application.yml或application.properties文件）提供此类配置。在 介绍 Spring Cloud Stream 部分的接收器示例中，将应用属性spring.cloud.stream.bindings.input.destination设置为raw-sensor-data，使它从Kafka主题raw-sensor-data或绑定到raw-sensor-dataRabbitMQ交换的队列中读取。
Spring Cloud Stream 自动检测并使用在类路径上找到的 Binder。你可以用相同代码使用不同类型的中间件。因此，在构建时可以包含一个不同的 Binder。对于更复杂的情形，你还可以在应用程序中打包多个 Binder，并在运行时选择 Binder（甚至选择对不同的绑定使用不同的 Binder）。
持久化发布-订阅支持
应用程序之间的通信遵循发布-订阅模型，其中数据通过共享主题进行广播。在下图中可以看到，该图显示了一组交互的Spring Cloud Stream应用程序的典型部署。
传感器报告给HTTP端点的数据将发送到名为的公共目标raw-sensor-data。从目的地，它由微服务应用程序独立处理，一个应用程序计算时间窗口平均值，另一个微服务应用程序将原始数据导入HDFS（Hadoop分布式文件系统）。为了处理数据，两个应用程序在运行时将主题声明为它们的输入。
发布-订阅通信模型降低了生产者和消费者的复杂性，并允许在不中断现有流程的情况下将新应用添加到拓扑中。例如，在平均计算应用程序的下游，你可以添加一个应用程序，该应用程序计算用于显示和监视的最高温度值。然后，你可以添加另一个解释相同平均值流以进行故障检测的应用程序。通过共享主题而不是点对点队列进行所有通信可以减少微服务之间的耦合。
尽管发布-订阅消息传递的概念并不新鲜，但 Spring Cloud Stream 采取了额外的步骤，明智的选择其成为 Spring Cloud Stream 的应用程序模型。通过使用本机中间件支持，Spring Cloud Stream 还简化了跨不同平台的发布-订阅模型的使用。
消费者组
虽然发布-订阅模型使得通过共享主题连接应用程序变得容易，但通过创建给定应用程序的多个实例进行扩展的能力同样重要。这样做时，会将应用程序的不同实例置于竞争的消费者关系中，在该消费者关系中，仅其中一个实例可以处理给定消息。
Spring Cloud Stream 通过消费者组的概念对这种行为进行建模。（Spring Cloud Stream 消费者组与 Kafka 消费者组相似并受其启发）每个消费者绑定都可以使用spring.cloud.stream.bindings.<bindingName>.group属性指定组名。对于下图所示的消费者，此属性将设置为spring.cloud.stream.bindings.<bindingName>.group=hdfsWrite或spring.cloud.stream.bindings.<bindingName>.group=average。
订阅给定目标的所有组都将收到已发布数据的副本，但是每个组中只有一个成员从该目标接收给定消息。默认情况下，当未指定组时，Spring Cloud Stream会将应用程序分配一个匿名且独立的单成员消费者组，和其他消费者组一样，单成员消费者组也具有发布-订阅关系。
消费者类型
支持两种类型的消费者：
-
消息驱动（有时称为异步）
-
轮询（有时称为同步）
在2.0版之前，仅支持异步使用者。消息一旦可用，就会被传递，并且有线程可以处理它。
当你希望控制消息的处理速率时，可能需要使用同步使用者。
持久性
与 Spring Cloud Stream 公认的应用程序模型一致，消费者组订阅是持久的。也就是说，binder 实现可确保组订阅是持久的，并且一旦创建了至少一个组订阅，该组将接收消息，即使还在发送消息，且组中的所有应用程序都停止了。
匿名订阅本质上是非持久的。对于某些 Binder 实现（例如RabbitMQ），可能具有非持久的组订阅。
通常，在将应用程序绑定到给定目标时，最好始终指定消费者组。扩展 Spring Cloud Stream 应用程序时，必须为其每个输入绑定指定消费者组。这样做可以防止应用程序的实例接收重复的消息（除非需要这种行为，这是不常见的）。
分区支持
Spring Cloud Stream 支持在给定应用程序的多个实例之间对数据进行分区。在分区的场景下，物理通信媒介（例如代理主题）被视为结构化的多个分区。一个或多个生产者应用程序实例将数据发送到多个消费者应用程序实例，并确保有共同特征标识的数据由同一消费者实例处理。
Spring Cloud Stream 提供了用于以统一方式实现分区处理用例的通用抽象。因此，无论代理本身是自然分区（例如 Kafka）还是非自然分区（例如 RabbitMQ），都可以使用分区。
分区是有状态处理中的关键概念（出于性能或一致性方面的考虑），它确保所有相关数据都一起处理。例如，在带时间窗的平均计算示例中，重要的是，来自任何给定传感器的所有测量都应由同一应用实例处理。
在设置分区处理的情景，必须同时配置数据产生端和数据消费端。
我的最新文章会先发到公众号【读钓的YY】上，欢迎关注！
