首先举个例子来说发布订阅模型：
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，在消息送达的时候执行自己的业务逻辑就可以了。这样一来，即便以后需要添加一个新的通知渠道，也不用更改上游订单系统的业务逻辑，这就是“松耦合”的业务设计原则。
网友评论