![]()
我是架构精进之路，点击上方“关注”，坚持每天为你分享技术干货，私信我回复“01”，送你一份程序员成长进阶大礼包。
![]()
事件驱动架构
事件驱动架构（Event Driven Architecture）是一个流行的分布式异步架构模式，可以用来设计规模很大的应用程序。基于这种架构模式应用可大可小。它由高度解耦的，单一目的的事件处理组件组成，可以异步地接收和处理事件。
一个事件驱动系统典型地由事件消费者和事件产生者组成，事件消费者向事件管理器订阅事件，事件产生者向事件管理器发布事件。当事件管理器从事件产生者那接收到一个事件时，事件管理把这个事件转送给相应的事件消费者。如果这个事件消费者是不可用的，事件管理者将保留这个事件，一段间隔之后再次转送该事件消费者。
关键概念解释
事件：系统或组件的状态发生变化时，系统层发出的通知。
解耦方式：每个对象都通过与中间件（Mediator or Broker）实现与外界的沟通，而不是相互依赖（迪米特法则）。
通讯方式：以消息为载体、通过中间件传递通讯。
拓扑结构分类
它包括两个主要的拓扑结构：mediator 和 broker。
这两种拓扑架构的特征和实现有很大的不同，所以你需要知道哪一个适合你。
Mediator拓扑结构
Mediator拓扑结构适合有多个步骤的事件，需要安排处理层次。
采用Mediator模式的架构中，事件一般是复杂的（包含多个执行单元的合集），而Mediator的责任就是将该复合事件拆解为独立的子事件，然后发送到不同类型的子事件处理系统中，由子系统完成独立子事件的分发和处理。
在结构上，Mediator的EDA架构包括4个组件：
用于原始事件（分类）存储，并转发给Event Mediator，一般是以MQ的形式存在。
用于原始事件的拆解（成为多个独立子事件），并转发给相关的Channel；
通道（可以理解为细分的Event Queue），按照事件的类型不同作以划分。它可以是一个消息队列，提供给特定的Processor查询，或是消息Topic，发送特定的广播。
事件处理器，监听特定的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个组件：
![]()
如图所示，它包含两个组件broker和 event processor。
架构考量
事件驱动架构模式实现起来相对复杂，主要是由于它的异步和分布式特性。这可能会带来一些分布式的问题，比如远程处理的可用性，缺乏响应，broker重连等问题。
1、分布式的异步架构
事件处理器之间高度解耦，软件的扩展性好，事件处理器可以独立地加载和卸载，容易部署，同时性能较好，因为事件的异步本质，软件不易产生堵塞。
2、对于单一的逻辑缺乏原子事务
此模式需要将原子事务交给一个事件处理器执行，跨事件处理器的原子事务是很困难的，很难进行回滚操作。同时对于事件处理器的创建，维护和管理比较困难，事件通常有特殊的约定（数据值和格式）。
模式分析
结合上文分析，事件驱动架构设计模式整体分析如下：
-
总体灵活性： 高
-
发布易用性： 高
-
可测试性： 低
-
性能： 高
-
规模扩展性： 高
-
开发容易度： 低
- END -
作者：架构精进之路，专注软件架构研究，技术学习与个人成长，关注并私信我回复“01”，送你一份程序员成长进阶大礼包。
往期热文推荐：
![]()
「技术架构精进」专注架构研究，技术分享
Thanks for reading!
