事件驱动的体系结构由生成事件流的事件生产者和监听事件的事件消费者组成。
事件是近实时交付的，因此消费者可以在事件发生时立即响应。生产者与消费者脱钩，生产者不知道消费者在听什么。消费者也相互脱钩，每个消费者都能看到所有的事件。这与竞争的消费者模式不同，消费者从队列中提取消息，消息只处理一次（假设没有错误）。
在一些系统中，例如物联网，事件必须以非常大的容量被接收。事件驱动架构可以使用pub/sub模型或事件流模型。
pub/sub：消息传递基础结构跟踪订阅。当一个事件发布时，它会将该事件发送给每个订阅服务器。接收到事件后，无法重播该事件，新订阅服务器看不到该事件。
事件流：事件被写入日志。事件是严格有序的（在分区内）并且是持久的。客户端不订阅流，而是可以从流的任何部分读取。客户端负责推进其在流程中的位置。这意味着客户端可以随时加入，并且可以重播事件。
在消费者方面，有一些常见的变化：
- 简单的事件处理。事件会立即触发使用者中的操作。例如，可以将函数与服务总线触发器一起使用，以便每当消息发布到服务总线主题时，函数都会执行。
- 复杂事件处理。消费者使用诸如流分析或Apache Storm之类的技术处理一系列事件，在事件数据中寻找模式。例如，可以在一个时间窗口内汇总来自嵌入式设备的读数，并在移动平均值超过某个阈值时生成通知。
- 事件流处理。使用数据流平台（如Apache Kafka）作为管道，以接收事件并将其提供给流处理器。流处理器处理或转换流。应用程序的不同子系统可能有多个流处理器。这种方法非常适合物联网工作负载。
事件源可能是系统外部的，例如物联网解决方案中的物理设备。在这种情况下，系统必须能够以数据源所需的容量和吞吐量接收数据。
在实践中，拥有一个使用者的多个实例是很常见的，以避免让使用者成为系统中的单一故障点。可能还需要多个实例来处理事件的数量和并发。此外，单个使用者可能会在多个线程上处理事件。如果事件必须按顺序处理，或者只需要一次语义，可能会有问题。
架构使用场景
- 多个子系统必须处理相同的事件。
- 具有最小延时的实时处理。
- 复杂的事件处理，如随时间窗的模式匹配或聚合。
- 数据量大、速度快，如物联网。
优点
- 生产者和消费者是脱钩的。
- 没有点对点集成。
- 向系统中添加新的消费者很容易。消费者可以在到达时立即响应事件。
- 高度可扩展和分布。
- 子系统具有独立的事件流视图。
缺点
- 在某些系统中，特别是在物联网场景中，确保事件交付至关重要。
- 按顺序或只处理一次事件。每个使用者类型通常在多个实例中运行，以实现弹性和可伸缩性。如果事件必须按顺序处理（在使用者类型中），或者处理逻辑不是等幂的，就会有数据乱序覆盖的问题。
