软件架构模式之事件驱动架构

事件驱动架构

事件驱动架构（Event Driven Architecture）是一个流行的分布式异步架构模式，可以用来设计规模很大的应用程序。基于这种架构模式应用可大可小。它由高度解耦的，单一目的的事件处理组件组成，可以异步地接收和处理事件。

一个事件驱动系统典型地由事件消费者和事件产生者组成，事件消费者向事件管理器订阅事件，事件产生者向事件管理器发布事件。当事件管理器从事件产生者那接收到一个事件时，事件管理把这个事件转送给相应的事件消费者。如果这个事件消费者是不可用的，事件管理者将保留这个事件，一段间隔之后再次转送该事件消费者。

关键概念解释

事件：系统或组件的状态发生变化时，系统层发出的通知。

解耦方式：每个对象都通过与中间件（Mediator or Broker）实现与外界的沟通，而不是相互依赖（迪米特法则）。

通讯方式：以消息为载体、通过中间件传递通讯。

拓扑结构分类

它包括两个主要的拓扑结构：mediator 和 broker。

mediator拓扑结构

需要你在一个事件通过mediator时精心安排好几个步骤；
broker拓扑结构

无需mediator，而是由你串联起几个事件。

这两种拓扑架构的特征和实现有很大的不同，所以你需要知道哪一个适合你。

Mediator拓扑结构

Mediator拓扑结构适合有多个步骤的事件，需要安排处理层次。

采用Mediator模式的架构中，事件一般是复杂的（包含多个执行单元的合集），而Mediator的责任就是将该复合事件拆解为独立的子事件，然后发送到不同类型的子事件处理系统中，由子系统完成独立子事件的分发和处理。

在结构上，Mediator的EDA架构包括4个组件：

event queues

用于原始事件（分类）存储，并转发给Event Mediator，一般是以MQ的形式存在。

event mediator

用于原始事件的拆解（成为多个独立子事件），并转发给相关的Channel；

event channels

通道（可以理解为细分的Event Queue），按照事件的类型不同作以划分。它可以是一个消息队列，提供给特定的Processor查询，或是消息Topic，发送特定的广播。

event processors

事件处理器，监听特定的Channel，并在捕获事件后进行处理

Mediator的处理过程如下图所示：

客户端发送一个事件到事件队列(event queues)中，它用来将事件传送给event mediator；
Event mediator收到初始的事件后，会发送额外的一些异步事件给event channels来执行处理的每个步骤；
Event channels 既可以是消息队列，也可以是消息topic，大部分是消息topic，这样可以由多个消息处理器(event processor)处理同一个消息。
Event processors监听event channels,接收事件并处理一些业务逻辑。

值得注意的是：

1、在事件驱动架构中有十几个甚至几百个事件队列都很正常。

2、模式本身没有限定事件队列的实现方式，它可能是一个消息队列，一个web service或者其它；

3、消息处理器包含实际的业务逻辑。每个消息处理器都是自包含的，独立的，高度解耦的，执行单一的任务。

Broker拓扑架构

Broker是一种更简洁的事件驱动架构，不同于上面的结构，它没有中心的Mediator。

在结构上，Broker的EDA架构包括3个组件：

Event

事件消息；
Event Channel

消息队列或者是Topic，根据订阅推送（或是转发）消息；消息可能被转发到Event Processor，或是其他的Event Channel中。
Event Processor

获得消息后执行处理。它可能是一个消息的处理终结点，也可能在处理过程中继续下发消息，或生成新的事件，并被再次提交到Event Channel中，继续下一轮的转发和处理。

如图所示，它包含两个组件broker和 event processor。

broker中的event channel可以是消息队列，消息topic或者它们的复合形式。
每个event processor负责处理事件，发布新的事件。

架构考量

事件驱动架构模式实现起来相对复杂，主要是由于它的异步和分布式特性。这可能会带来一些分布式的问题，比如远程处理的可用性，缺乏响应，broker重连等问题。

1、分布式的异步架构

事件处理器之间高度解耦，软件的扩展性好，事件处理器可以独立地加载和卸载，容易部署，同时性能较好，因为事件的异步本质，软件不易产生堵塞。

2、对于单一的逻辑缺乏原子事务

此模式需要将原子事务交给一个事件处理器执行，跨事件处理器的原子事务是很困难的，很难进行回滚操作。同时对于事件处理器的创建，维护和管理比较困难，事件通常有特殊的约定（数据值和格式）。

模式分析

结合上文分析，事件驱动架构设计模式整体分析如下：

总体灵活性：高
发布易用性：高
可测试性：低
性能：高
规模扩展性：高
开发容易度：低

- END -

「技术架构精进」专注架构研究，技术分享

Thanks for reading!