事件驱动体系结构事件驱动体系结构(Event Driven Architecture )是一种通用的分布式异步体系结构模型，可用于设计大型APP应用。 基于该架构模型的APP应用具有较小的cmdfy。 这包括高度解耦的单目的事件处理组件，能够异步接收和处理事件。
事件驱动系统典型地由事件消费者和事件发生器组成，事件消费者向事件管理器订阅事件，事件发生器向事件管理器发布事件。 当事件管理器从事件发生者接收到事件时，事件管理器将该事件转发给适当的事件消费者。 如果此事件消费者不可用，事件管理员将暂挂此事件，然后以一定的间隔再次转发给事件消费者。
重要概念说明事件：当系统或组件的状态发生变化时，在系统级别发出的通知。
解耦方式：各客体不是相互依存的，而是通过中间件(Mediator or Broker )实现与外部的交流(brdwn定律)。
通信方式：以消息为载体，通过中间件传递通信。
有两个主要拓扑：拓扑分类mediator和broker。
编辑器拓扑
一个事件通过mediator时需要仔细安排几个步骤
中介拓扑
不是mediator，而是你来合并几个事件。
这两种拓扑的特点和实现有很大的不同，所以你需要知道哪个更适合你。
Mediator拓扑Mediator拓扑适用于具有多个步骤的事件，并且需要设置处理级别。
在采用Mediator模式的体系结构中，事件通常很复杂。 包含多个执行单元的集合。 Mediator的责任是将复合事件分解为独立的子事件，发送到不同类型的子事件处理系统，由子系统完成独立子事件的分发和处理。
在结构上，Mediator的EDA体系结构具有以下四个组件：
事件队列
它用于原始事件(分类)存储，并转发到事件编辑器。 一般以MQ的形式存在。
事件编辑器
它用于分解原始事件，成为多个独立的子事件，并转发到相关的信道；
事件信道
通道(可以理解为细分事件队列)按事件类型进行划分。 它可以提供给特定的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服务或其他；
3、消息处理器包括实际的业务逻辑。 每个消息处理器都是自包含的、独立的、高度解耦的，并且执行单个任务。
Broker拓扑体系结构Broker是一种更为简洁的事件驱动体系结构，与上述结构不同，它没有中央编辑器。
在结构上，Broker的EDA体系结构包括以下三个组件：
事件
事件新闻；
事件通道
根据消息队列或Topic或订阅推送(或转发)消息可能会转发到事件处理器或其他事件通道。
事件处理器
在获取消息后执行处理。 这可能是消息的处理端点，或者在处理过程中继续发送消息或生成新事件，然后重新提交到Event Channel以继续进行下一次传输和处理。
如图所示，它包括两个组件： broker和event processor。
broker的事件信道可以是消息队列、消息主题或它们的复合格式。
每个event processor负责处理事件和发布新事件。
体系结构考虑事项事件驱动体系结构模型的实现主要是由于其异步性和分布式特性。 这可能会导致远程处理可用性、响应不足、broker重新连接等分布式问题。
1、分布式异步体系结构
事件处理器之间的高级解耦、软件可扩展性、独立加载和卸载，易于部署，性能高。 由于事件的异步本质，软件很难出现堵塞。
2、相对于单一逻辑，原子事务不足
在此模式中，必须将原子事务传递给单个事件处理器来执行。 事件处理器之间的原子事务很困难，回滚操作很困难。 此外，创建事件处理程序很难维护和管理，而且事件通常有特殊的规则(数据值和格式)。
模式分析结合上述分析，对事件驱动架构设计模式的整体分析如下。
整体灵活性：高
释放易用性：高度
可测试性：低
性能：高
可扩展性：高
易开发性：低
- END -
“技术框架精益求精”专注于框架研究，共享技术
Thanks for reading！