简介

现在有 2 个服务，Service A 和 Service B，通过 REST 接口通信；Service A 在某个业务场景下调用 Service B 的接口完成一个计算密集型任务，假设接口为 http://service_b/api/v1/domain；该任务运行时间很长，但 Service A 不想一直阻塞在接口调用上。为了满足 Service A 的要求，通常有 2 种方案：

  1. Service A 隔一段时间调用一次 Service B 的接口，如果任务还没完成，就返回 HTTP Status 102 Processing；如果已完成，则返回 HTTP Status 200 Ok。

方案 1 须要轮询接口，轮询太频繁会导致资源浪费，间隔太长又会导致任务完成后 Service A 无法及时感知。显然，方案 2 更加高效，因此也被广泛应用。

方案 2 用到的思想就是本文要介绍的观察者模式（Observer Pattern），GoF 对它的定义如下：

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

我们将观察者称为 Observer，被观察者（或主体）称为 Subject，那么 Subject 和 Observer 是一对多的关系，当 Subject 状态变更时，所有的 Observer 都会被通知到。

UML 结构

场景上下文

在 简单的分布式应用系统（示例代码工程）中，应用之间通过 network 模块来通信，其中通信模型采用观察者模式：

从上图可知，App 直接依赖 http 模块，而 http 模块底层则依赖 socket 模块：

App2request handlerApp1request handlerpacket handlerApp 1socket packetApp 2App 2packet handlerpacket handlerApp 2request handler

在上述 socket - http - app 三层模型 中，对 socket 和 http，socket 是 Subject，http 是 Observer；对 http 和 app，http 是 Subject，app 是 Observer。

代码实现

因为在观察者模式的实现上，socket 模块和 http 模块类似，所以，下面只给出 socket 模块的实现：

总结实现观察者模式的几个关键点：

SocketListenerHandlePacketsocketImplSocketlistenersAddListenerReceive

扩展

发布-订阅模式

与观察者模式相近的，是发布-订阅模式（Pub-Sub Pattern），很多人会把两者等同，但它们之间还是有些差异。

从前文的观察者模式实现中，我们发现 Subject 持有 Observer 的引用，当状态变更时，Subject 直接调用 Observer 的更新处理方法完成通知。也就是，Subject 知道有哪些 Observer，也知道 Observer 的数量：

在发布-订阅模式中，我们将发布方称为 Publisher，订阅方称为 Subscriber，不同于观察者模式，Publisher 并不直接持有 Subscriber 引用，它们之间通常通过 Broker 来完成解耦。也即，Publisher 不知道有哪些 Subscriber，也不知道 Subscriber 的数量：

发布-订阅模式被广泛应用在消息中间件的实现上，比如 Apache Kafka 基于 Topic 实现了发布-订阅模式，发布方称为 Producer，订阅方称为 Consumer。

下面，我们通过 简单的分布式应用系统（示例代码工程）中的 mq 模块，展示一个简单的发布-订阅模式实现，在该实现中，我们将 Publisher 的 produce 方法和 Subscriber 的 consume 方法都合并到 Broker 中：

memoryMqProduceConsume

总结实现发布-订阅模式的几个关键点：

MessagememoryMqqueuesProduceConsume

Push 模式 VS Pull 模式

实现观察者模式和发布-订阅模式时，都会涉及到 Push 模式或 Pull 模式的选取。所谓 Push 模式，指的是 Subject/Publisher 直接将消息推送给 Observer/Subscriber；所谓 Pull 模式，指的是 Observer/Subscriber 主动向 Subject/Publisher 拉取消息：

Push 模式和 Pull 模式的选择，取决于通信双方处理消息的速率大小。

如果 Subject/Publisher 方生产消息的速率要比 Observer/Subscriber 方处理消息的速率小，可以选择 Push 模式，以求得更高效、及时的消息传递；相反，如果 Subject/Publisher 方产生消息的速率要大，就要选择 Pull 模式，由 Observer/Subscriber 方决定消息的消费速率，否则可能导致 Observer/Subscriber 崩溃。

Pull 模式有个缺点，如果当前无消息可处理，将导致 Observer/Subscriber 空轮询，可以采用类似 Kafka 的解决方案：让 Observer/Subscriber 阻塞一定时长，让出 CPU，避免长期无效的 CPU 空转。

典型应用场景

  • 需要监听某个状态的变更，且在状态变更时，通知到监听者。
  • web 框架。很多 web 框架都用了观察者模式，用户注册请求 handler 到框架，框架收到相应请求后，调用 handler 完成处理逻辑。
  • 消息中间件。如 Kafka、RocketMQ 等。

优缺点

优点

  • 消息通信双方解耦。观察者模式通过依赖接口达到松耦合；发布-订阅模式则通过 Broker 达到解耦目的。
  • 支持广播通信。
  • 可基于 topic 来达到指定消费某一类型消息的目的。

缺点

  • 通知 Observer/Subscriber 的顺序是不确定的，应用程序不应该依赖通知顺序来保证业务逻辑的正确性。
  • 广播通信场景，需要 Observer/Subscriber 自己去判断是否需要处理该消息，否则容易导致 unexpected update。

与其他模式的关联

观察者模式和发布-订阅模式中的 Subject 和 Broker，通常都会使用 单例模式 来确保它们全局唯一。

文章配图

可以在 用Keynote画出手绘风格的配图 中找到文章的绘图方法。