Spring Cloud微服务笔记九(Stream消息驱动)

本文介绍了Spring Cloud Stream,一个用于构建消息驱动微服务的框架,它通过Binder对象与消息中间件交互,降低了与不同消息中间件的集成成本。内容包括设计思想,如通过MessageChannel进行消息传递,以及Binder的概念,它作为中间层隔离应用程序与消息中间件的细节。此外,还讨论了编码API、常用注解、配置方法,如消息生产者和订阅者的设置,以及消息分组的实现,确保消息的正确处理和消费。
摘要由CSDN通过智能技术生成

概况

官方定义Spring Cloud Stream是一个构建消息驱动微服务的框架。
应用程序通过inputs或者outputs来与Spring Cloud Stream中的binder对象交互。
通过我们配置来binding(绑定),而Spring Cloud Stream的binder对象负责与消息中间件交互,所以,我们只需要搞清楚如何与Spring Cloud Stream交互就可以方便使用消息驱动的方式。
通过使用Spring Intergration来连接消息代理中间件以实现消息事件驱动。Spring Cloud Stream为一些供应商的消息中间件产品提供了个性化的自动化配置实现,引用了发布-订阅、消费组、分区的三个核心概念(RabbitMQ和Kafka)。

目的:屏蔽地城消息中间件的差异,降低切换成本,统一消息的编程类型。

官网:传送门
中文指导手册:传送门

设计思想

标准MQ
在这里插入图片描述
生产者/消费者之间通过消息媒介(Message)传递信息内容
消息必须走特定的通道(MessageChannel)
消息通道MessageChannel的子接口SubscribableChannel,由MessageChannel消息处理器订阅

CloudStream

比方说我们用到了RabbitMQ和Kafka,由于两个消息中间件的架构上的不同,像RabbitMQyouexchange,Kafka有Topic和Partitions分区。
在这里插入图片描述
这些中间件的差异性导致我们实际项目开发给我们造成了一定的困扰,我们如果用了两个消息队列的其中一种,后面的业务需求,我们向往另一种消息队列进行迁移,这时候五一就是一个灾难性的,一大堆东西都重新推到重新做,因为他跟我们的系统耦合了,这时候Spring Cloud Stream给我们提供了一种解耦合的方式。

Binder

在没有绑定器这个概念的情况下,我们的Spring Boot应用要直接与消息中间件信息交互的时候,由于各消息中间件够贱的初衷不同,他们的实现细节上有较大的差异性,通过定义绑定器作为中间层,完美地实现了应用程序与消息中间件细节之间的隔离。通过项应用程序暴露统一的Channel通道,使得应用程序不需要在考虑各种不同的消息中间件实现。
通过定义绑定器Binder作为中间层,实现了应用程序与消息中间件细节之间的隔离。
在这里插入图片描述
INPUT对应消费者
OUTPUT对应生产者

Stream中的消息通信方式遵循了发布-订阅模式,Topic主题进行广播,在RabbitMQ就是Exchange,在Kafka中就是Topic

在这里插入图片描述
**Binder:**很方便的连接中间件,屏蔽差异。
**Channel:**通道,是队列Queue的一种抽象,在消息通讯系统中就是实现存储和转发的媒介,通过Channel对队列进行配置。
**Source和Sink:**简单的可以理解为参照对象是Spring Cloud Stream自信,从Stream发布消息就是输出,接收消息就是输入。

编码API和常用注解

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值