主页
topics
事件驱动的架构
事件驱动的架构是围绕事件的发布、捕获、处理和存储（或持久化）而构建的集成模型。 某个应用或服务执行一项操作或经历另一个应用或服务可能想知道的更改时，就会发布一个事件（也就是对该操作或更改的记录），另一个应用或服务便可以消费和处理该事件，继而执行更多操作。
事件驱动的架构支持在连接的应用和服务之间实现松散耦合，它们可以通过发布和消费事件相互通信，除了事件格式之外，彼此不知道其他任何信息。 与“请求/响应”架构（或集成模型）相比，这种模型具有显著优势，因为在“请求/响应”架构中，应用或服务必须从另一个期望特定请求的特定应用或服务请求特定信息。
事件驱动的架构最大限度发挥了云原生应用的潜力，并支持强大的应用技术，例如实时分析和决策支持。
在事件驱动的架构中，应用充当事件生产者或事件消费者（经常是同时充当这两个角色）。
事件生产者以消息的形式将事件传输到代理或某种其他形式的事件路由器，此时事件的时间顺序相对于其他事件保持不变。 事件消费者会实时（在发生事件时）或在需要的任何其他时间提取消息，并处理消息以触发另一个操作、工作流程或它自己的事件。
举一个简单例子，银行服务可能会传输“存款”事件，银行的另一项服务通过将存款写入客户的对账单来消费和响应该事件。 但事件驱动的集成也可以基于对大量数据的复杂分析触发实时响应，例如，当出现客户在电子商务网站上点击产品的“事件”时，会根据其他客户的购买行为生成实时的产品推荐。
在事件驱动的架构中，有两种基本的事件传输模型。
事件消息传递或发布/订阅
在事件消息传递或发布/订阅模型中，事件消费者订阅由事件生产者发布的一类或多类消息。 当事件生产者发布事件时，消息会直接发送给所有想要消费该事件的订阅者。
通常，消息代理负责处理事件消息在发布者与订阅者之间的传输。 代理接收每个事件消息，必要时对其进行转换，保持其相对于其他消息的顺序，使它们可供订阅者使用，然后在事件消息被消费后将其删除（这样就无法再被消费）。
事件流式方法
在事件流式方法模型中，事件生产者向代理发布事件流。 事件消费者订阅流，而不是在事件发布后接收和消费事件，消费者可以随时进入每个流，并且仅消费他们想要消费的事件。 这里的主要区别在于，即使在消费者收到事件之后，代理也仍会保留这些事件。
Apache Kafka 等数据流平台以非常高的吞吐量（每天数万亿个事件记录，实时，无性能延迟）管理大量事件的日志记录和传输。 流媒体平台提供了某些消息代理所不具备的特性：
- 事件持久性：因为消费者可以在事件发布后的任何时间使用它们，所以事件流记录具有持久性，这些记录将被保留一段时间，具体时长可配置，从几分之一秒到永远。 这使事件流应用能够处理历史数据以及实时数据。
- 复杂事件处理：与事件消息传递一样，事件流可以用于简单的事件处理，其中每个发布的事件触发一个或多个特定消费者的传输和处理操作。 但是，它也可以用于复杂的事件处理，其中事件消费者处理整个系列的事件，并根据结果执行操作。
与“请求/响应”应用架构相比，事件驱动的架构为开发人员和组织带来了多种优势和机会。
强大的实时响应和分析：事件流使应用能够响应不断变化的业务状况，并根据所有可用的当前和历史数据实时做出预测和决策。 这在许多领域都有优势，从处理海量的物联网设备生成的数据，到动态预测和消除安全威胁，再到自动化供应链以实现最高效率。
容错性、可扩展性、简化维护、通用性和松散耦合的其他优势：在事件驱动的架构中，应用和组件不依赖于彼此的可用性；它们可以独立更新、测试和部署，而不会中断服务，当一个组件出现故障时，备份就可以上线。 事件持久性支持“重放”过去的事件，这有助于在事件消费者中断时恢复数据或功能。 组件可以通过网络轻松且彼此独立地扩展，开发人员可以通过添加和删除事件生产者和消费者来修改或扩充应用和系统。
异步消息传递：事件驱动的架构让组件能够异步通信，即生产者按自己的时间表发布事件消息，无需等待消费者接收事件（甚至不知道消费者是否收到了事件）。 除了简化集成之外，这还改善了用户的应用体验。 在一个组件中完成了任务的用户无需等待即可继续执行下一个任务，无论该组件与系统中的其他组件之间是否存在任何下游集成。