美文网首页
SpringCloud之Stream-3.发布订阅模型详解

SpringCloud之Stream-3.发布订阅模型详解

作者: 那钱有着落吗 | 来源:发表于2021-09-26 15:35 被阅读0次

首先举个例子来说发布订阅模型:

image.png
  • 出版社 也就是我们常说的Producer,它既生产消息也是消息的搬运工,专门负责发布事件(或者可以说发布消息)到消息中间件。它可以指定事件的Topic,不同的Topic代表不同事件
  • 书报亭 这里就是我们的消息中间件,不管是使用RabbitMQ、RocketMQ还是Kafka,它们的作用都是一样的,那就是接收来自生产者的消息,并把消息丢到对应的Queue里面,等待消费。通常情况下中间件为每个Topic创建一个对应的Queue(后面的小节会讲到消息组的概念,一个Topic会对应多个Queue)
  • 消费者 也就是我们常说的Consumer,它主要做两件事情订阅消息 订阅一个消息,然后紧盯着中间件里对应的Queue,看有没有新的消息进来
  • 消息消费 当有新消息来到Queue中以后,这个消息会被投递到所有监听当前Queue的消费者

业务模型解耦

发布订阅模型还有一个主要的用途就是子系统解耦,每个子系统可以用“松耦合”的方式与上游系统集成,我们用一个例子来解释“松耦合”的含义。
假如我们的订单系统需要做一个下单通知的内容,以往的做法是这样的:

image.png

在下单完成后,我们要在订单系统中分别集成不同的通知渠道,对于订单系统来说,下游系统的业务逻辑将传播到上游系统。比如短信通知需要对接SMS系统,这压根就不是订单业务所关心的,但是又不得不去做。如果以后又引入了一种新的渠道,比如钉钉通知,那订单接口又要去对接钉钉SDK了,这显然不符合软件设计的职责隔离和模块化设计。
这种场景最适合应用发布订阅模型了,我们再来看如何来重构业务流程,达到松耦合的目的。

image.png

在上面的模式中,订单接口只用在用户下单后发送一条“下单完成”的消息到MQ组件中就结束任务了,每个通知渠道去MQ里订阅对应的Topic,在消息送达的时候执行自己的业务逻辑就可以了。这样一来,即便以后需要添加一个新的通知渠道,也不用更改上游订单系统的业务逻辑,这就是“松耦合”的业务设计原则。

相关文章

网友评论

      本文标题:SpringCloud之Stream-3.发布订阅模型详解

      本文链接:https://www.haomeiwen.com/subject/ifezgltx.html