返回 导航

SpringBoot / Cloud

hangge.com

消息驱动微服务框架Spring Cloud Stream使用详解1(基本介绍)

作者:hangge | 2020-11-02 08:10

一、基本介绍

1,什么是 Spring Cloud Stream?

  • Spring Cloud Stream 是一个用来为微服务应用构建消息驱动能力的框架。它为一些供应商的消息中间件产品提供了个性化的自动化配置实现,并且引入了发布-订阅、消费组以及分区这三个核心概念。
  • Spirng Cloud Stream 本质上就是整合了 Spring BootSpring Integration,实现一套轻量级的消息驱动的微服务框架。通过使用 Spring Cloud Stream 可以有效简化开发人员对消息中间件的使用复杂度,让系统开发人员可以有更多的精力关注于核心业务逻辑的处理。
  • Spring Cloud Stream 基于 Spring Boot 实现,所以它秉承了 Spring Boot 的优点,自动化配置功能可以帮助我们快速上手使用。不过 Spring Cloud Stream 目前只支持 RabbitMQ Kafka 这两个消息中间件的自动化配置。

2,Spring Cloud Stream 解决了什么问题?

(1)在实际开发过程中,服务与服务之间通信经常会使用到消息中间件,如果我们一开始选择使用某个中间件比如:RabbitMQ,那么该中间件和系统的耦合性就会非常高。后续如果我们再要替换为 Kafka 那么代码变动会比较大。
(2)Spring Cloud Stream 解决了开发人员无感知的使用消息中间件的问题,因为 Spring Cloud Stream 对消息中间件的进一步封装,可以做到代码层面对中间件的无感知,甚至于动态的切换中间件(RabbitMQ 切换为 Kafka),降低系统和中间件的耦合性,让应用程序可以关注更多自己的业务流程。

3,Spring Cloud Stream 核心概念

(1)下面是官方文档中的 Spring Cloud Stream 应用模型的结构图,而 Spring Cloud Stream 中消息的发布和消费,涉及四个组件:SourceChannelBinder Sink

(2)消息通道 Channel:对于每一个 Spring Cloud Stream 的应用程序来说,它不要知晓消息中间件的通信细节,它只需知道 Binder 对应程序提供的抽象概念来使用消息中间件来实现业务逻辑即可,而这个抽象概念就是消息通道(Channel
    上面的结构图中,样例应用程序和 Binder 之间定义了两条输入通道和三条输出通道来传递信息,而绑定器则是作为这些通道和消息中间件之间的桥梁进行通信。当需要升级消息中间件,或者更换其他消息中间件产品时,我们要做的就是更换它们对应的 Binder 绑定器而不需要修改任何 Spring Boot 的应用逻辑。

(3)绑定器 BinderSpring Cloud Stream 构建的应用程序与消息中间件之间是通过绑定器 Binder 相关联的,绑定器对于程序而言起到了隔离作用,它使得不同消息中间件的实现细节对应用程序来说是透明的。
    由于 RabbitMQ Kafka 自身的实现结构有所不同,因此 RabbitMQ Kafka 的绑定器分别使用消息中间件中不同概念来实现消息的生产与消费:
  • RabbitMQ 绑定器:在 RabbitMQ 中,通过 Exchange 交换器来实现 Spring Cloud Stream 的主题概念,所以消息通道的输入输出目标映射了一个具体的 Exchange 交换器。而对于每个消费组,则会为对应的 Exchange 交换器绑定一个 Queue 队列进行消息收发。
  • Kafka 绑定器:由于 Kafka 自身就有 Topic 概念,所以 Spring Cloud Stream 的主题直接采用了 Kafka Topic 主题概念,每个消费组的通道目标都会直接连接 Kafka 的主题进行消息收发。 

(4)Source Sink:当一个服务准备发布消息时,它将使用一个 Source 发布消息,它接受普通的 Java 对象,该对象代表发布的消息,Source Java对象序列化并将消息发布到 Channel。而服务会通过 Sink 从队列中接受消息,将消息反序列化为 POJO 对象。

附:消息中间件几个常见的应用场景

    碰到下面的几种情况的时候,我们就要考虑使用消息队列。如果碰巧使用的是 RabbitMQ 或者 Kafka,而且同样也是在使用 Spring Cloud ,那可以考虑下用 Spring Cloud Stream

1,异步处理

    比如用户在电商网站下单,下单完成后会给用户推送短信或邮件,发短信和邮件的过程就可以异步完成。因为下单付款是核心业务,发邮件和短信并不属于核心功能,并且可能耗时较长,所以针对这种业务场景可以选择先放到消息队列中,有其他服务来异步处理。

2,应用解耦

    假设公司有几个不同的系统,各系统在某些业务有联动关系,比如 A 系统完成了某些操作,需要触发 B 系统及 C 系统。如果 A 系统完成操作,主动调用 B 系统的接口或 C 系统的接口,可以完成功能,但是各个系统之间就产生了耦合。用消息中间件就可以完成解耦,当 A 系统完成操作将数据放进消息队列,B C 系统去订阅消息就可以了。这样各系统只要约定好消息的格式就好了。

3,流量削峰

    比如秒杀活动,一下子进来好多请求,有的服务可能承受不住瞬时高并发而崩溃,所以针对这种瞬时高并发的场景,在中间加一层消息队列,把请求先入队列,然后再把队列中的请求平滑的推送给服务,或者让服务去队列拉取。

4,日志处理

Kafka 最开始就是专门为了处理日志产生的。
评论

全部评论(0)

回到顶部