主要概念

• 1: 应用模型
• 2: binder抽象
• 3: 持久化pub-sub支持
• 4: consumer group
• 5: 分区

1 - 应用模型

官方文档的描述

内容摘录自官方文档 Application Model 一节

Spring Cloud Stream 应用程序由一个中间件中立的核心组成。应用程序通过在外部 broker 暴露的目的地和你代码中的输入/输出参数之间建立 binding (绑定) 来与外部世界进行通信。建立 binding 所需的特定 broker 细节由特定于中间件的 Binder 实现来处理。

2 - binder抽象

官方文档的描述

内容摘录自官方文档 The Binder Abstraction 一节

Spring Cloud Stream 为 Kafka 和 Rabbit MQ 提供了 Binder 的实现。该框架还包括一个测试 binder ，用于将你的应用程序作为 spring-cloud-stream 应用程序进行集成测试。

Binder 抽象也是该框架的扩展点之一，这意味着你可以在 Spring Cloud Stream 之上实现自己的 binder。

Spring Cloud Stream 使用 Spring Boot 进行配置，Binder 抽象使 Spring Cloud Stream 应用程序能够灵活地连接到中间件。例如，部署者可以在运行时动态地选择外部目的地（如Kafka topic 或RabbitMQ exchange）与消息处理程序的输入和输出（如函数的输入参数及其返回参数）之间的映射。这种配置可以通过外部配置属性和 Spring Boot 支持的任何形式提供（包括应用程序参数、环境变量和application.yml 或 application.properties 文件）。在介绍Spring Cloud Stream部分的 sink 示例中，将 spring.cloud.stream.bindings.input.destination 应用属性设置为 raw-sensor-data 会导致它从 raw-sensor-data Kafka topic 或从绑定到 raw-sensor-data RabbitMQ exchange 的队列中读取。

Spring Cloud Stream 会自动检测并使用在 classpath上 找到的 binder。你可以在相同的代码中使用不同类型的中间件。要做到这一点，在构建时包括一个不同的 binder。对于更复杂的用例，你也可以将多个 binder 与你的应用程序打包，让它在运行时选择 binder（甚至是是否为不同的 binding 使用不同的 binder）。

3 - 持久化pub-sub支持

官方文档的描述

内容摘录自官方文档 Persistent Publish-Subscribe Support 一节

应用程序之间的通信遵循 发布-订阅 （publish-subscribe model）模型，数据通过共享主题进行广播。这可以从下图中看出，该图显示了一组相互交流的 Spring Cloud Stream 应用程序的典型部署。

由传感器报告给HTTP端点的数据被发送到一个名为 raw-sensor-data 的共同目的地。从目的地开始，它被一个计算时间窗口平均数的微服务应用程序和另一个将原始数据摄入HDFS（Hadoop分布式文件系统）的微服务应用程序独立处理。为了处理数据，这两个应用程序都在运行时声明该主题为其输入。

发布-订阅通信模型降低了生产者和消费者的复杂性，并让新的应用程序被添加到拓扑结构中，而不会破坏现有的流程。例如，在平均计算应用程序的下游，你可以添加一个计算最高温度值的应用程序，用于显示和监控。然后，你可以添加另一个应用程序，解释相同的平均数流以进行故障检测。通过共享主题而不是点对点队列进行所有通信，可以减少微服务之间的耦合。

虽然发布-订阅消息的概念并不新鲜，但Spring Cloud Stream采取了额外的措施，使之成为其应用模型的意见选择。通过使用原生中间件支持，Spring Cloud Stream还简化了发布-订阅模型在不同平台上的使用。

4 - consumer group

官方文档的描述

内容摘录自官方文档 Consumer Groups 一节

虽然发布-订阅模型使得通过共享主题连接应用程序变得容易，但通过创建特定应用程序的多个实例来扩大规模的能力同样重要。当这样做时，应用程序的不同实例被置于竞争的消费者关系中，其中只有一个实例被期望处理一个给定的消息。

Spring Cloud Stream 通过 consumer group （消费者组）的概念来模拟这种行为。(Spring Cloud Stream consumer group 与Kafka consumer group 相似，并受其启发。) 每个消费者 binding 可以使用 spring.cloud.stream.bindings.<bindingName>.group 属性来指定一个组名。对于下图所示的消费者，这个属性将被设置为 spring.cloud.stream.bindings.<bindingName>.group=hdfsWrite 或 spring.cloud.stream.bindings.<bindingName>.group=average。

所有订阅给定目的地的组都会收到一份已发布数据的副本，但每个组中只有一个成员收到来自该目的地的给定消息。默认情况下，当没有指定组时，Spring Cloud Stream 会将应用程序分配给一个匿名的、独立的单成员 consumer group，该组与所有其他 consumer group 都是发布-订阅关系。

消费者类型

支持两种类型的消费者:

• 消息驱动（有时称为异步）

• 轮询（有时称为同步）。

在2.0版本之前，只支持异步的消费者。只要有消息，并且有线程可以处理，消息就会被传递。

当你想控制消息的处理速度时，你可能想使用一个同步消费者。

持久性

与 Spring Cloud Stream 的 opinionated (翻译为 有主见的？) 应用模型一致，消费者组的订阅是持久的。也就是说，binder 的实现可以确保组的订阅是持久的，而且一旦为一个组创建了至少一个订阅，该组就会收到消息，即使这些消息是在该组的所有应用都停止时发送的。

匿名订阅在本质上是不可持久的。对于一些 binder 的实现（如RabbitMQ），可以有非持久性的组订阅。

一般来说，当把应用程序绑定到一个特定的目的地时，最好总是指定 consumer group。当扩展 Spring Cloud Stream 应用程序时，你必须为其每个输入 binding 指定 consumer group。这样做可以防止应用程序的实例收到重复的消息（除非需要这种行为，这是不正常的）。

5 - 分区

官方文档的描述

内容摘录自官方文档 Partitioning Support 一节

Spring Cloud Stream 提供了对特定应用程序的多个实例之间的数据分区的支持。在分区方案中，物理通信介质（如 broker topic）被视为被结构化为多个分区。一个或多个生产者应用实例向多个消费者应用实例发送数据，并确保由共同特征识别的数据由同一个消费者实例处理。

Spring Cloud Stream 为以统一方式实现分区处理用例提供了一个通用抽象。因此，无论 broker 本身是自然分区（例如Kafka）还是不分区（例如RabbitMQ），都可以使用分区。!

SCSt-partitioning

分区是有状态处理中的一个关键概念，在有状态处理中，确保所有相关数据被一起处理是非常关键的（出于性能或一致性的原因）。例如，在时间窗口平均计算的例子中，重要的是来自任何给定传感器的所有测量都由同一个应用实例处理。

​ 要搭建分区处理方案，必须配置数据生产端和数据消费端。