此文章主要讲解 springcloud 中消息驱动 Stream 的相关知识。
前言
Spring Cloud Stream 中文指导手册: 点我跳转
在实际的企业开发中,消息中间件是至关重要的组件之一。消息中间件主要解决应用解耦、异步消息、流量削峰等问题,实现高性能、高可用、可伸缩和最终一致性的架构。不同的中间件其实现方式,内部结构是不一样的。如常见的 RabbitMQ 和 Kafka,由于这两个消息中间件的架构上的不同,如 RabbitMQ 有 Exchange,Kafka 有 Topic、Partitions,这些中间件的差异性导致我们实际项目开发会给我们造成了一定的困扰,我们如果用了两个消息中间件的其中一种,后面的业务需求,需要往另一种消息中间件迁移,这时候无疑就是一个灾难,一大堆东西需要重新推倒重做,因为它和我们系统耦合了,这时候Spring Cloud Stream
给我们提供了一种解耦合的方式。
概述
一句话就是屏蔽底层消息中间件的差异,降低切换成本,统一消息的编程模型
。
就像 JDBC 形成一种规范,统一不同数据库的接口
。
Spring Cloud Stream 由一个中间件中立的 Core 组成。应用通过 Spring Cloud Stream 的input(相当于消费者consumer,它是从队列中接收消息的)
和output(相当于生产者producer,它是从队列中发送消息的)
通道和外界交流。通道通过指定中间件的 Binder 实现和外部代理连接。业务开发者不再关注具体消息中间件,只需要关注 Binder 对应用程序提供的抽象概念来使用消息中间件实现业务即可。
核心概念
绑定器
绑定器(Binder)是 Spring Cloud Stream 中的一个非常重要的概念。在没有绑定器这个概念的情况下,我们的 SpringBoot 应用要直接和消息中间件进行信息交互的时候,由于各个消息中间件构建的初衷不同,它们的实现细节上会有较大的差异性,这似的我们实现的消息交互逻辑就会非常笨重,因此对具体的中间件实现细节有太重的依赖,当中间件有较大的变动升级、或者更换中间件的时候,我们就需要付出非常大的代价来实施。
通过定义绑定器作为中间层,实现了应用程序和消息中间件细节之间的隔离。通过向应用程序暴露统一的 Channel,使得应用程序不需要再考虑各种不同的消息中间件实现。当需要升级消息中间件或者更换其他的消息中间件产品时,我们需要做的就是更换对应的 Binder 绑定器而不需要修改任何应用逻辑,甚至可以任意的改变中间件的类型而不需要修改一行代码。
Spring Cloud Stream 支持各种 Binder 实现,如下图所示:
- 通过配置把应用和 Spring Cloud Stream 的 binder 绑定在一起,之后我们只需要修改 binder 的配置来达到动态修改 Topic、Exchange、type 等一系列信息而不需要修改一行代码。
发布/订阅模型
在 Spring Cloud Stream 中的消息通信方式遵循了发布--订阅模式
,当一条消息被投递到消息中间件之后,它会通过共享的Topic主题进行广播
,消息消费者在订阅的主题中收到它并触发自身的业务逻辑处理。
这里所提到的 Topic 主题是 Spring Cloud Stream 中的一个抽象概念,用来代表发布共享消息给消费者的地方。在不通过的消息中间件中,Topic 可能对应着不同的概念,如:在RabbitMQ中它对应了Exchange
,在Kafka中对应了Topic
。
标准流程套路
Middleware:
中间件,目前只支持RabbitMQ和Kafka
。Binder:
Binder 是应用和消息中间件之间的封装,目前实现了 Kafka 和 RabbitMQ 的 Binder,通过 Binder 可以很方便的连接中间件
,可以动态的改变消息类型(对应于Kafka的Topic
和RabbitMQ的Exchange
),这些都是可以通过配置文件来实现。@Input:
注解标识输入通道,通过该输入通道接收到的消息进入应用程序。@Output:
注解标识输出通道,发布的消息将通过该通道离开应用程序。@StreamListener:
监听队列,用于消费者的队列的消息接收。@EnableBinding:
将通道 Channel 和 Exchange 绑定在一起。
Binder:
很方便的连接中间件,屏蔽差异。Channel:
通道,是队列 Queue 的一种抽象,在消息通讯系统中就是实现存储和转发的媒介,通过对 Channel 实现对队列进行配置。Source和Sink:
简单可以理解为参照对象就是 Spring Cloud Stream 本身,从 Spring Cloud Stream 发布消息就是输出,从 Spring Cloud Stream 接受消息就是输入。
入门案例
准备工作
RabbitMQ 环境先准备好。
消息生产者
新建模块
cloud-stream-rabbitmq-provider8801
POM 文件
1 |
|
YML 文件
1 | server: |
这里有个坑:
application.yml 使用了 spring.cloud.stream.binders.defaultRabbit.environment.spring.rabbitmq.xx 来配置 rabbitmq 的环境。
如果你是用的其他服务器
上的 rabbitmq,比如我使用的我自己的阿里云服务器然后创建 docker 容器来运行 rabbitmq。
按照上述的配置方式的话,启动时会试图连接两次 rabbitmq 程序。
第一次试图连接访问的就是 application.yml 中配置的地址,此时已经订阅成功了
但是程序还会在之后进行第二次连接,此时访问的地址就是 localhost:5672,在我的环境中,我本地没有 rabbitmq 环境,所以直接报 IOException。
所以,如果是使用的自己的服务器
来配置,则需要修改配置文件,将 rabbitmq 的配置信息移动到 application.yml 中的 spring 节点下
1 | spring: |
主启动类
1 |
|
业务类
此业务类不是以前的 service,而是负责推送消息的服务类
发送消息接口
1 | public interface IMessageProvider { |
接口实现类
1 | package com.itjing.springcloud.service.impl; |
Controller
1 |
|
测试
- 启动 Eureka Server 7001
- 启动 rabbitMQ
- 启动 8801
- 在 rabbitMQ 中查看是否有我们发送的消息!
多次访问:http://localhost:8801/sendMessage
打开 rabbitMQ : http://localhost:15672/ ,可见是成功的。
消息消费者
新建模块
cloud-stream-rabbitmq-consumer8802
POM 文件
1 | <dependencies> |
YML 文件
在 stream 的配置上,output 改成 input
1 | server: |
主启动类
1 |
|
业务逻辑
1 |
|
测试
启动 8802。
发送消息: http://localhost:8801/sendMessage
消息发送者:
消息接收者:
配置分组消费
概述
通常在生产环境中,我们的每个服务都不会以单节点的方式,当同一个服务启动多个实例的时候,这些实例都会绑定到同一个消息通道的目标主题(Topic)上
。默认情况下,当生产者发出一条消息到绑定通道上,这条消息会产生多个副本被每个消费者实例接收和处理
,但是有些业务场景下,我们希望生产者的消息只被一个实例消费
,这个时候我们需要为这些消费者设置消费组
来实现这样的功能。
实操
新建模块 cloud-stream-rabbitmq-consumer8803 ,8803 就是 8802 clone 出来的,只需修改对应的信息就行
。
重复消费
两个消费者都接收到了消息,这属于重复消费。
- 例如:消费者进行订单创建,这样就创建了两份订单,会造成系统错误。
注意在 Stream 中处于同一个 group 中的多个消费者是竞争关系,就能够保证消息只会被其中一个应用消费一次。
不同组是可以全面消费的(重复消费)。
同一组内会发生竞争关系,只有其中一个可以消费。
Stream 默认不同的微服务是不同的组
对于重复消费这种问题,导致的原因是默认每个微服务是不同的group
,组流水号不一样,所以被认为是不同组,两个都可以消费。
解决的办法就是自定义配置分组:
消费者 yml 文件配置:
1 | # 8802 的消费者 |
当两个消费者配置的 group 相同时,就属于同一组,就不会被重复消费。
持久化
加上group配置,就已经实现了消息的持久化。
- 停止 8002 和 8003 ,并去除掉 8802 的分组,保留 8803 的分组
- 8801 先发送几条消息到 rabbitMQ
- 先启动 8802,无分组属性配置,后台没有打印消息
- 在启动 8803,有分组属性配置,后台打印出来了 MQ 上的消息
自定义消息通道
概述
- Spring Cloud Stream 内置类两种接口,分别定义了 binding 为
“input”输入流
和“output”输出流
,而在我们实际使用中,往往需要定义各种输入输出流
。使用方法也很简单。
自定义消息通道
消息生产者
修改配置文件
1 | ...... |
自定义消息通道
1 | package com.itjing.springcloud.channel; |
发送消息接口
1 | public interface IMessageProvider { |
接口实现类
1 | .class) // 这里是自定义的 CustomProcessor (CustomProcessor |
业务逻辑
1 |
|
消息消费者
修改配置文件
1 | ...... |
自定义消息通道
1 | package com.itjing.springcloud.channel; |
业务逻辑
1 |
|
测试即可。
消息分区
有一些场景需要满足,同一特征的数据被同一个实例消费,比如同一个 id 的传感器监测数据必须被同一个实例统计计算分组,否则可能无法获取全部的数据。又比如部分异步任务,首次请求启动 task,二次请求取消 task,此场景就必须保证两次请求到同一个实例。
消息生产者配置
1 | ...... |
消息消费者配置
1 | ...... |
发布时间: 2021-01-20
最后更新: 2024-06-24
本文标题: SpringCloud Alibaba入门到精通(十二)- 消息驱动Stream
本文链接: https://blog-yilia.xiaojingge.com/posts/475d3d2f.html
版权声明: 本作品采用 CC BY-NC-SA 4.0 许可协议进行许可。转载请注明出处!
