Spring Cloud Stream(一)

Spring Cloud Stream

一：介绍

Spring Cloud Stream是构建消息驱动的微服务应用程序的框架。Spring Cloud Stream基于Spring Boot建立独立的生产级Spring应用程序，并使用Spring Integration提供与消息代理的连接。它提供了来自几家供应商的中间件的意见配置，介绍了持久发布订阅语义，消费者组和分区的概念。

将@EnableBinding注释添加到应用程序，以便立即连接到消息代理，并且可以将@StreamListener添加到方法中，以使其接收流处理的事件。

@SpringBootApplication
@EnableBinding(Processor.class)
@Slf4j
public class Demo1Application {

    public static void main(String[] args) {
        SpringApplication.run(Demo1Application.class, args);
    }
    @StreamListener(Processor.OUTPUT)
    @SendTo(Processor.OUTPUT)
    public String  processVote(String str){
        log.info(str);
        return str;
    }
}

@EnableBinding注释需要一个或多个接口作为参数（在这种情况下，该参数是Processor接口）。接口声明输入和输出通道。Spring Cloud Stream提供了接口Source，Sink和Processor; 您还可以定义自己的界面。

以下是Processor接口的定义：

public interface Processor extends Source, Sink {
}

可以看到这个是空接口，只是继承了Source,Sink接口。我们继续点进去：

Source.java

public interface Source {
    String OUTPUT = "output";

    @Output("output")
    MessageChannel output();
}

Sink.java

public interface Sink {
    String INPUT = "input";

    @Input("input")
    SubscribableChannel input();
}

@Input注释标识输入通道，通过该输入通道接收到的消息进入应用程序; @Output注释标识输出通道，发布的消息将通过该通道离开应用程序。

二：主要概念

Spring Cloud Stream提供了一些简化了消息驱动的微服务应用程序编写的抽象和原语。这篇笔记主要概述：

• Spring Cloud Stream的应用模型
• Binder抽象
• 持续的发布 - 订阅支持
• 消费者群体支持
• 分区支持
• 一个可插拔的Binder API

2.1 应用模型

一个Spring Cloud Stream应用程序由一个中间件中立的核心组成。该应用程序通过Spring Cloud Stream注入到其中的输入和输出通道与外界进行通信。渠道通过中间件特定的Binder实现连接到外部实现类。

2.2 fat Jar

Spring Cloud Stream应用程序可以在独立模式下从IDE运行进行测试。要在生产中运行Spring Cloud Stream应用程序，您可以使用为Maven或Gradle提供的标准Spring Boot工具创建可执行文件（或fat）JAR。

2.3 Binder概念

Spring Cloud Stream为Kafka和Rabbit MQ提供Binder实现。Spring Cloud Stream还包括一个TestSupportBinder，它保留了一个未修改的通道，以便测试可以直接和可靠地与通道进行交互。您可以使用可扩展API编写自己的Binder。

Spring Cloud Stream使用Spring Boot进行配置，Binder使得Spring Cloud Stream应用程序可以灵活地连接到中间件。例如，部署者可以在运行时动态地选择通道连接的目的地（例如，Kafka的主题或RabbitMQ的交换器）。可以通过外部配置属性和Spring Boot（包括应用程序参数，环境变量和application.yml）支持的任何形式提供此类配置。

在引入Spring Cloud Stream部分的接收器示例中，将应用程序属性spring.cloud.stream.bindings.input.destination设置为raw-sensor-data将使其从raw-sensor-data Kafka主题或从绑定到raw-sensor-data RabbitMQ交换。

这段话说起来有点深，原文是这么说的：

In the sink example from the Introducing Spring Cloud Stream section, setting the application property spring.cloud.stream.bindings.input.destination to raw-sensor-data will cause it to read from the raw-sensor-data Kafka topic, or from a queue bound to the raw-sensor-data RabbitMQ exchange.

Spring Cloud Stream自动检测并使用类路径中找到的binder。您可以使用相同的代码轻松使用不同类型的中间件：在构建时只包含不同的绑定器。对于更复杂的用例，您还可以在应用程序中打包多个绑定器，并在运行时选择绑定器，甚至是否为不同的通道使用不同的绑定器。

2.4 持续发布-订阅支持

应用间通信遵循发布订阅模式，其中通过共享主题广播数据。这在下图可以看到，他显示一组交互式的Spring Cloud Stream应用程序的典型部署。

传感器向HTTP端点报告的数据将发送到名为raw-sensor-data的公共目标。从目的地，它由微服务应用程序独立处理，该应用程序计算时间窗口平均值，以及另一个将原始数据导入HDFS的微服务应用程序。为了处理数据，两个应用程序在运行时将主题声明为它们的输入。

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

虽然发布订阅消息的概念不是新的，但是Spring Cloud Stream需要额外的步骤才能使其成为其应用模型的一个有意义的选择。通过使用本地中间件支持，Spring Cloud Stream还简化了在不同平台上使用发布订阅模型。

2.5 消费群体

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

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

2.6 Durability(持久性)

符合Spring Cloud Stream的有意义的应用模式，消费者群体订阅是持久的。也就是说，绑定实现确保组预订是持久的，一旦已经创建了一个组的至少一个订阅，即使组中的所有应用程序都被停止，组也将接收消息。

注意：

匿名订阅本质上是不耐用的。对于某些binder实现（例如RabbitMQ），可以具有非持久组的订阅。

通常，当将应用绑定到给定目的地时，最好始终指定消费者组。在扩展Spring Cloud Stream应用程序时，必须为每个输入绑定指定一个使用者组。这样可以防止应用程序的实例收到重复的消息（除非需要这种行为，这是不寻常的）。

2.7 分区支持

Spring Cloud Stream提供对给定应用程序的多个实例之间的分区数据的支持。在分区场景中，物理通信介质（例如，代理主题）被视为被构造成多个分区。一个或多个生产者应用程序实例将数据发送到多个消费者应用程序实例，并确保由共同特征标识的数据由相同的消费者实例处理。

Spring Cloud Stream提供了统一方式实现分区处理用例的通用抽象。因此，无论代理本身是否自然分区（例如Kafka，RabbitMQ），分区可以被使用。

分区是状态处理中的一个关键概念，无论是性能还是一致性原因，它都是批评性的，以确保所有相关数据一起处理。例如，在时间平均计算示例中，重要的是所有给定传感器的所有测量都由相同的应用实例进行处理。

注意：

要设置分区处理方案，则必须同时配置数据生成和数据消耗结束。