【Springcloud篇】学习笔记七（十三章）：Stream消息驱动

第十三章_Stream消息驱动

1.消息驱动Stream介绍

1.1Stream为什么被引入

常见MQ(消息中间件)：

• ActiveMQ
• RabbitMQ
• RocketMQ
• Kafka

有没有一种新的技术诞生，让我们不再关注具体MQ的细节，我们只需要用一种适配绑定的方式，自动的给我们在各种MQ内切换。（类似于Hibernate）

1.2是什么

屏蔽底层消息中间件的差异,降低切换成本，统一消息的编程模型。

官方定义Spring Cloud Stream是一个构建消息驱动微服务的框架。

应用程序通过inputs或者 outputs 来与Spring Cloud Stream中binder对象交互。通过我们配置来binding(绑定)，而Spring Cloud Stream 的binder对象负责与消息中间件交互。所以，我们只需要搞清楚如何与Spring Cloud Stream交互就可以方便使用消息驱动的方式。

通过使用Spring Integration来连接消息代理中间件以实现消息事件驱动。Spring Cloud Stream为一些供应商的消息中间件产品提供了个性化的自动化配置实现，引用了==发布-订阅、消费组、分区==的三个核心概念。

目前仅支持RabbitMQ、 Kafka。

1.3设计思想

（1）标准MQ

• 生产者/消费者之间靠消息媒介传递信息内容
• 消息必须走特定的通道 - 消息通道 Message Channel
• 消息通道里的消息如何被消费呢，谁负责收发处理 - 消息通道MessageChannel的子接口SubscribableChannel，由MessageHandler消息处理器所订阅。

（2）为什么用Cloud Stream

比方说我们用到了RabbitMQ和Kafka，由于这两个消息中间件的架构上的不同，像RabbitMQ有exchange，kafka有Topic和Partitions分区。

我们如果用了两个消息队列的其中一种，后面的业务需求，我想往另外一种消息队列进行迁移，这时候无疑就是一个灾难性的，一大堆东西都要重新推倒重新做，因为它跟我们的系统耦合了，这时候Spring Cloud Stream给我们提供了—种解耦合的方式。

（3）Stream凭什么可以统一底层差异

在没有绑定器这个概念的情况下，我们的SpringBoot应用要直接与消息中间件进行信息交互的时候，由于各消息中间件构建的初衷不同，它们的实现细节上会有较大的差异性。

通过定义绑定器作为中间层，完美地实现了应用程序与消息中间件细节之间的隔离。通过向应用程序暴露统一的Channel通道，使得应用程序不需要再考虑各种不同的消息中间件实现。

一句话：屏蔽底层消息中间件的差异，降低切换成本，统一消息的编程模型。

Stream对消息中间件的进一步封装，可以做到代码层面对中间件的无感知，甚至于动态的切换中间件(rabbitmq切换为kafka)，使得微服务开发的高度解耦，服务可以关注更多自己的业务流程

通过定义绑定器Binder作为中间层，实现了应用程序与消息中间件细节之间的隔离。

（4）Binder

Binder可以生成Binding，Binding用来绑定消息容器的生产者和消费者，它有两种类型

• INPUT对应于消息消费者
• OUTPUT对应于消息生产者

下图为SpringCloud Stream的处理架构

（5）Stream中的消息通信方式遵循发布—订阅模式

在消息中间件系统中，主题（Topic）是一种消息发布和订阅模式，允许发布者将消息发送到一个主题，而订阅者可以选择订阅他们感兴趣的主题，以接收相关消息。RabbitMQ和Apache Kafka都支持主题的概念，但它们在如何理解和实现主题方面有一些不同。

• RabbitMQ：

  RabbitMQ是一个消息队列系统，它使用Exchange来实现主题的概念。在RabbitMQ中，Exchange是消息的分发中心，它接收来自生产者的消息并将其路由到一个或多个队列中。

• Kafka：

  Kafka是一个分布式事件流平台，它使用Topic来实现主题的概念。在Kafka中，一个主题是一个逻辑通道，用于组织和发布消息。Kafka的主题与传统消息队列不同，因为它的主题中的消息通常保留在日志中，供多个消费者进行订阅和消费。

1.4Stream的标准流程套路

• Binder：很方便的连接中间件，屏蔽差异
• Channel：通道，是队列Queue的一种抽象，在消息通讯系统中就是实现存储和转发的媒介，通过Channel对队列进行配置
• Source和Sink：简单的可理解为参照对象是Spring Cloud Stream自身，从Stream发布消息就是输出，接受消息就是输入

1.5编码API和常用注解

2.案例说明

RabbitMQ环境已经OK，工程中新建三个子模块

• cloud-stream-rabbitmq-provider8801，作为生产者进行发消息模块
• cloud-stream-rabbitmq-consumer8802，作为消息接收模块
• cloud-stream-rabbitmq-consumer8803 作为消息接收模块

2.1消息生产者provider8801

（1）pom

<dependencies>
        
        <dependency>
            <groupId>org.springframework.cloudgroupId>
            <artifactId>spring-cloud-starter-stream-rabbitartifactId>
        dependency>
 
        
        <dependency>
            <groupId>org.springframework.cloudgroupId>
            <artifactId>spring-cloud-starter-netflix-eureka-clientartifactId>
        dependency>
        <dependency>
            <groupId>org.springframework.bootgroupId>
            <artifactId>spring-boot-starter-webartifactId>
        dependency>
        <dependency>
            <groupId>org.springframework.bootgroupId>
            <artifactId>spring-boot-starter-actuatorartifactId>
        dependency>
        <dependency>
            <groupId>org.springframework.bootgroupId>
            <artifactId>spring-boot-devtoolsartifactId>
            <scope>runtimescope>
            <optional>trueoptional>
        dependency>
        <dependency>
            <groupId>org.projectlombokgroupId>
            <artifactId>lombokartifactId>
            <optional>trueoptional>
        dependency>
        <dependency>
            <groupId>org.springframework.bootgroupId>
            <artifactId>spring-boot-starter-testartifactId>
            <scope>testscope>
        dependency>
        <dependency>
            <groupId>springcloudgroupId>
            <artifactId>cloud-api-commonsartifactId>
            <version>${project.version}version>
        dependency>
    dependencies>

（2）yml

（3）主启动

（4）业务类

• service层

• controller层

（5）测试

• 启动Eureka7001
• 再启动8801
• 登录rabbit 15672，查看发送消息的主题名称

2.2消息消费者consumer8802

cloud-stream-rabbitmq-consumer8802

（1）pom

<dependencies>
        
        <dependency>
            <groupId>org.springframework.cloudgroupId>
            <artifactId>spring-cloud-starter-stream-rabbitartifactId>
        dependency>
 
        <dependency>
            <groupId>org.springframework.cloudgroupId>
            <artifactId>spring-cloud-starter-netflix-eureka-clientartifactId>
        dependency>
        <dependency>
            <groupId>org.springframework.bootgroupId>
            <artifactId>spring-boot-starter-webartifactId>
        dependency>
        <dependency>
            <groupId>org.springframework.bootgroupId>
            <artifactId>spring-boot-starter-actuatorartifactId>
        dependency>
        <dependency>
            <groupId>org.springframework.bootgroupId>
            <artifactId>spring-boot-devtoolsartifactId>
            <scope>runtimescope>
            <optional>trueoptional>
        dependency>
        <dependency>
            <groupId>org.projectlombokgroupId>
            <artifactId>lombokartifactId>
            <optional>trueoptional>
        dependency>
        <dependency>
            <groupId>org.springframework.bootgroupId>
            <artifactId>spring-boot-starter-testartifactId>
            <scope>testscope>
        dependency>
        <dependency>
            <groupId>springcloudgroupId>
            <artifactId>cloud-api-commonsartifactId>
            <version>${project.version}version>
        dependency>
    dependencies>

（2）yml

（3）主启动类

（4）controller层

（5）测试

• 发送消息

• 8801后台

• 8802后台

2.3分组消费与持久化

依照8802，clone出来一份运行8803

启动

• 分组消费RabbitMQ
• 7001：服务注册
• 8801：消息生产
• 8802：消息消费
• 8803：消息消费

运行后有两个问题：

• 有重复消费问题
• 消息持久化问题，即消息消费方不能接收未曾被接收的消息

（1）消息重复消费

8001发送一条消息，发结果8802/8803同时都收到了，存在重复消费问题

生产实际案例：

比如在如下场景中，订单系统我们做集群部署，都会从RabbitMQ中获取订单信息，那如果一个订单同时被两个服务获取到，那么就会造成数据错误，我们得避免这种情况。这时我们就可以使用Stream中的消息分组来解决

（2）解决消息重复消费

原理：

微服务应用放置于同一个group中，就能够保证消息只会被其中一个应用消费一次。

不同组是可以全面消费的(重复消费)，同一组内会发生竞争关系，只有其中一个可以消费。

分组

8002，8003添加到同一分组即可

application.yml中添加分组groupPeng

• 测试

（3）解决消息持久化

通过分组可以实现，消息消费方重启的时候，可以接收，其在宕机的时候，消息发送方发送的消息。