一、定义
事件驱动的架构是围绕事件的发布、捕获、处理和存储（或持久化）而构建的集成模型。 某个应用或服务执行一项操作或经历另一个应用或服务可能想知道的更改时，就会发布一个事件（也就是对该操作或更改的记录），另一个应用或服务便可以获取和处理该事件，继而执行更多操作。
二、基本原理
事件驱动架构以事件作为系统间通信的基本单位，系统中的各个组件通过发布和订阅事件来进行交互。基本原理包括以下几个要素：
1. 事件：事件是发生在系统中的某种动作或状态变化，它可以是用户操作，也可以是其他组件的响应。每个事件都有一个唯一的标识符，用于区别不同的事件类型。
2. 发布-订阅模式：在事件驱动架构中，系统中的某个组件可以发布（发布者）事件，而其他组件可以订阅（订阅者）这些事件。当有事件发布时，所有订阅该事件的组件都会收到通知。
3. 事件处理：事件的处理是事件驱动架构的核心。当一个事件被发布后，订阅该事件的组件会执行相应的事件处理函数。事件处理函数可以是系统内置的默认处理函数，也可以是开发者自定义的处理逻辑。
4. 事件传递：事件的传递是指事件在系统中的传递过程。一个事件可以触发其他事件的发布，从而形成事件链。事件传递可以是同步的，也可以是异步的，取决于具体的业务需求。
三、实现方式
事件驱动架构模式主要包含两种实现方式，分别是中介者拓扑（Mediator Topology），代理者拓扑（Broker Topology）。
3.1 中介者拓扑结构
中介者拓扑结构需要在一个事件通过 Mediator 时精心安排好具体的步骤，适合有多个步骤的事件。(有点工作流的感觉)。比如在交易系统中，每个请求流程必须经过特定的步骤，如验证、订单、配送，以及通知买家等。在这些步骤中，有些步骤是串行，有些可以并行完成。
主要包括 4 个基本组件：
- 事件队列（event queue）：接收事件的入口，存储待处理事件
- 分发器（event mediator）：将不同的事件分发到不同的业务逻辑单元
- 事件通道（event channel）：分发器与处理器之间的联系渠道
- 事件处理器（event processor）：实现业务逻辑，处理完成后会发出事件，触发下一步操作
示例：以一个处理保险流程的例子来说明，如图：
3.2代理者拓扑（Broker Topology）
代理者拓扑主要由 Event Processor 和 Event Channel 构成，事件之间可能彼此是相互关联的。例如，一个 Event Processor 的处理结果是下一个 Event Processor 需要消费的事件，每个 Processor 必须完成自己的工作，其他 Processor 才能开始执行，整个事件处理过程像一条彼此相扣的链条，只有整个流程结束才能形成一个完整的业务逻辑。（类似于职责链或管道模式）。
示例：同样以一个处理保险流程的例子来说明，如图：
四、优点与缺点
事件驱动架构可以实现系统的松耦合，使各个组件之间解耦，具有以下优点：
1. 可扩展性：通过事件驱动架构，可以方便地增加、修改或删除系统中的组件，而不会影响其他组件的正常运行。
2. 灵活性：每个组件可以独立开发和测试，不受其他组件的影响。这样可以更好地适应需求的变化或更新迭代。
3. 可重用性：事件驱动架构可以将特定的功能封装成独立的组件，使其可以在系统中的多个地方进行复用，减少重复开发的工作量。
4. 可测试性：由于各个组件之间解耦，可以更加方便地对单个组件进行单元测试和集成测试，提高系统的可测试性和稳定性。
缺点：
- 一旦环境变化，需要代码调整或增加功能时，通常比较麻烦和费时
- 部署比较麻烦，即使只修改一个小地方，往往需要整个软件重新部署，不容易做持续发布
- 软件升级时，可能需要整个服务暂停
- 扩展性差，用户请求大量增加时，必须依次扩展每一层，由于每一层内部是耦合的，扩展会很困难
参考：
事件驱动的架构 | IBM
事件驱动架构 - 光星の博客 文章来源：https://www.toymoban.com/news/detail-822600.html
13种常见软件体系结构风格定义分析、结构图、优缺点_软件体系结构设计风格-CSDN博客文章来源地址https://www.toymoban.com/news/detail-822600.html
到了这里，关于软件架构之事件驱动架构的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
