架构模式的深刻研究——事件总线模式

通过对多个有关事件总线模式的文档介绍的阅读，对事件总线模式有了必定的了解，并做出以下总结：

1、 事件总线模式主要是处理事件，包括4个主要组件：事件源、事件监听器、通道和事件总线。消息源将消息发布到事件总线上的特定通道上。侦听器订阅特定的通道。侦听器会被通知消息，这些消息被发布到它们以前订阅的一个通道上。

使用场景：安卓开发、通知服务

优势：新的发布者、订阅者和链接能够很容易地添加。对高度分布式的应用程序有效。

缺点：可伸缩性多是一个问题，由于全部消息都是经过同一事件总线进行的。

2、基于事件驱动的分布式异步架构模式多用于构建高可伸缩的反应式应用程序，适用于各类从简单到复杂的应用场景。它的核心思想是去耦合，将消息的发送和接收分开，实现异步处理消息事件。

事件总线是实现基于事件驱动模式的方式之一，或者能够将其称为“Broker Topology”。事件发送者将事件消息发送到一个中心 broker 上，事件订阅者向中心 broker 订阅和接收事件，而后再处理接收到的事件。固然，订阅者不只能够接收和消费事件，它们自己也能够建立事件，并将它们发送到事件总线上。下面列出了 4 种事件总线的实现方式，并对它们的优缺点进行了总结。

 

1. 向全部的订阅者发送事件

事件总线直接将输入事件（红色箭头）发送给订阅者（蓝色方块）

参与者

事件总线、订阅者（事件处理器）、事件建立者

实现

事件建立者向事件总线发送事件，事件总线将收到的事件发送给全部的订阅者。订阅者既能够处理接收到的事件，也能够建立新事件，而后把它们发送给事件总线。事件总线不关心订阅者是否成功接收到消息。

功能需求

通知、订阅、退订。

优点

实现起来很简单。

不足

事件总线须要将每个事件消息复制一份给订阅者，也就是说，若是有1000个订阅者，每个事件都会有1000份拷贝，这样会占用大量的内存。

事件总线不保证消息传递的可靠性，它会尝试给订阅者发送消息，并且只会尝试一次，若是出现错误，好比网络链接错误，订阅者可能就会收不到消息。 
另外，事件总线不负责过滤消息，因此订阅者须要本身实现过滤逻辑。

 

2. 向全部订阅者发送事件影子

事件总线和事件存储及事件观察者

参与者

事件总线、事件建立者、订阅者、事件存储（Event Store）、事件观察者（Event Watcher）

实现

事件总线在收到事件建立者发送过来的事件后，把事件保存到事件存储里，而后将事件影子（Event Shadow，也就是对原始事件的引用）发送给全部的订阅者。订阅者根据事件影子从事件存储里获取事件数据，再对数据进行处理。

事件总线为每个事件建立一个事件观察者，观察者持有订阅者列表，当全部的订阅者都接收到消息后，观察者负责把事件从事件存储里删除。

事件总线仍然不保证订阅者必定会收到全部事件影子。若是有订阅者接收消息失败，相应的观察者就会被标记为“skipped”。

功能需求

通知、订阅、退订、保存/删除/获取、标记完成/跳过

优点

由于事件消息被保存在事件存储里，发送给订阅者的只是事件引用，因此占用内存会小不少。

不足

订阅者须要调用额外的方法，好比在收到事件影子以后要调用方法去获取事件数据，在处理完事件后还要调用方法通知事件总线已完成处理，或者通知事件总线跳过某个事件。另外，在事件总线端还要实现事件存储和事件观察者。这个对事件存储的实现要求比较高，若是订阅者数量不少，事件存储的读负载会很重，并且在写入事件时是阻塞式的。

这种实现方式仍然不会为订阅者过滤事件，因此订阅者仍是须要本身实现事件过滤。

3. 向通过过滤的订阅者发送事件影子

第三种实现方式与第二种是同样的，只不过不是将事件影子发送给全部订阅者，而是发送给通过过滤的订阅者，也就是说只发送给其中的一部分订阅者。事件总线须要记录订阅者感兴趣的主题，在这里可使用正则过滤器为订阅者过滤主题。

这种方式的优点与不足和第二种也是同样的，只是多了事件过滤功能。

4. 按顺序传递

为了保证顺序传递，能够对事件进行分区。关于如何经过分区来保证顺序传递，能够参考Kafka的论文，基本原理是让消费者消费属于本身的分区。

不足

动态增长分区或减小分区会变得很困难，并且须要本身实现分区器，消费者的实现也很复杂。