分类:  Azure云架构师入门    ◆ 标签:  #Azure   #基础   #Azure Cloud Architecting   ◆ 发布于: 2023-06-05 11:44:29

对于事件驱动的架构，很多用户第一时间就会想起消息队列的使用，目前市面上的所有的消息队列的产品确实是可以应用于事件的架构，但是基于事件的架构并非是完全基于消息队列的驱动，大型分布式系统确实会比较依赖消息队列，小型系统则未必。

事件驱动架构中主要的两类角色包括事件的生产者以及事件的消费者，结构图如下所示：

事件的最大特性就是实时，因此生产者可以立即送出事件产生的消息，订阅该事件的应用也会根据事件迅速的做出反馈，同时订阅者之间也是相互解耦，不存在依赖关系，而且每个订阅者都能看到该事件的发生，并且仅仅对每个事件仅仅处理一次。

同时需要注意的是事件架构中，可以有两种模式，一种是发布/订阅模式，另外一种是事件流模式。发布/订阅模式容易理解，事件流模式需要注意的是产生的事件流会写入日志，并且该日志是经过严格的排序，使用者可以容易的对整个事件流进行定位，重放。

在事件的消费者端，有一些常见的变化：

• 简单事件处理。 事件会立即触发使用者中的某项操作。 例如，可以将 Azure Functions 与服务总线触发器配合使用，每当消息发布到服务总线主题后，函数便开始执行。
• 复杂的事件处理。 使用者使用 Azure 流分析或 Apache Storm 之类的技术处理一系列事件，寻找事件数据中的模式。 例如，如果移动平均超过特定阈值，便可聚合在某个时间范围内从嵌入式设备读取的信息，并生成通知。
• 事件流处理。 使用 Azure IoT 中心或 Apache Kafka 等数据流平台作为管道引入事件并将其馈送到流处理器。 此流处理器可处理或转换流。 不同应用程序子系统可能有多种流处理器。 此方法非常适合 IoT 工作负荷。

另外事件可能来源于系统之外，例如 IoT 解决方案中的物理设备。 在这种情况下，系统必须能够以数据源需要的容量和吞吐量来引入数据。

什么时候使用事件驱动模型

• 多个子系统必须处理相同的事件。
• 延迟时间最短的实时处理。
• 复杂事件处理，如模式匹配或时间范围内的聚合。
• 大量且快速的数据，如 IoT。

事件驱动架构的优点

• 生成者和使用者相脱离。
• 无点到点集成。 容易向系统添加新使用者。
• 使用者在事件发生时便可立即响应。
• 具有高缩放性，分布广泛。
• 子系统具有独立的事件流视图。

可能会遇到的问题

• 保证消息的不会被丢失。 在某些系统中，尤其是在 IoT 方案中，尤其重要。
• 按顺序传递消息。

其他注意事项

要包括在事件中的数据量可能是影响性能和成本的重要考虑因素。 在事件本身中放置处理所需的所有相关信息可以简化处理代码并保存更多查找。 将最小数量的信息放在事件中（如只是几个标识符）将会缩短传输时间和成本，但需要处理代码才能查找它所需的任何其他信息。