您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件开发专栏 > 开发技术 > 正文

服务架构:事件驱动架构

发表于:2023-07-12 作者:赵帅虎 来源:今日头条

事件驱动架构是由生产者和消费者组成,生产者负责生产事件,消费者监听并消费事件。

事件驱动架构

事件分发以近实时的方式进行,所以当事件产生时,消费者可以立即做出应对。

  • 生产者和消费者是解耦的,它不知道有哪些消费者在监听事件
  • 消费者之间也是解耦的,每个消费者都可以读取所有事件。

还有一种模式,多个消费者是竞争的关系,它们从同一个队列消费,不出现错误的情况下每个事件都只被处理一次。

另外,在某些系统中,事件导入的吞吐量要求也很高,比如IoT系统。

事件驱动架构可以通过发布/订阅模型或事件流模型来实现:

  • 发布/订阅模型:消息队列负责追踪订阅者,事件被发布后,消息队列负责发送给订阅者。一旦事件被接收,就不能再重放,新增的订阅者也看不到该事件。
  • 事件流模型:将事件写入日志并持久存储下来,在单个分区里事件严格有序。client端不需要订阅这个事件流,而且能够从任意一个位置开始读取事件。当然,移动偏移量也要靠客户端自己完成。这意味着client可以在任意时间点加入,也支持事件重放。

在事件的消费上,也可以有一些略微不同的方式:

  • 简单模式:事件产生后立刻触发消费者下一步的动作。比如风控、治理等场景下的异常行为检测。
  • 复杂模式:消费者处理一组数据,找到其中的规律,比如基于时间窗口做聚合求sum/count/avg。
  • 纯流式:通过流式平台比如Kafka作为数据中转的工具,接收事件并喂给下游的processor。下游的processor通常做简单的transform之后再写入的kafka。

事件通常来源于外部系统,比如IoT中的物理设备、互联网用户的端上。我们在设计时,必须认真评估总体的数据量和吞吐量,以保证系统能支撑这个量级。

在上面的流程图中,右侧的三个格子表示三种类型的消费者,每种类型的消费者下面有多个实例。在实际场景中,出于容灾的目的,多个消费者实例的情况非常普遍。为了保证事件处理的吞吐量,多个实例也是有必要的。

在处理事件时,一个消费者实例可以创建多个线程。这也能提高处理的吞吐量,不过事件被处理的顺序就乱了,业务上可能无法接受;另外多线程处理也很难保证exactly-once语义。

应用场景

  • 多个子系统都需要处理这些事件
  • 需要实时处理,且延迟越小越好
  • 处理逻辑比较复杂的场景,比如要对事件继续模式匹配或者基于时间窗口的聚合
  • 事件量级非常大,生产的速度也很快

架构优势

  • 生产者和消费者解耦
  • 没有点对点的集成,增加新消费者几乎没有难度
  • 消费者可以即时处理到来的事件
  • 天生分布式、可扩展性非常高
  • 每个下游子系统都可以访问全部事件,且互相独立

有哪些挑战

  • 不丢事件:一些业务场景要求,事件必须发送成功,不能丢。比如金融、电商等涉及钱的场景;
  • 按顺序消费:由于架构的分布式特性,消费者本身就是多实例的,不支持全局有序消费;
  • exactly-once消费:事件消费的每个环节都可能会失败,失败就会重试。重试的话,就需要额外的机制去保障exactly once

补充说明

在设计系统时,我们通常需要考虑单条消息的大小,它对系统的性能和金钱成本影响都非常大。如果走两个极端的话,可以是:

如果将所有需要的信息都放到单个事件里,处理起来会很方便,并且能够避免额外的信息查询。

如果将非常少的信息放到单个事件里,比如ID字段,那么会节省大量传输数据的时间和金钱成本,但其他信息需要访问其他服务才能获取到。

这其中的利益权衡,看自己的业务来定了。