当前位置：主页 > 关注 >

服务架构：事件驱动架构

发布时间： 2023-07-12 09:29:59 来源：今日头条

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

【资料图】

事件驱动架构

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

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

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

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

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

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

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

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

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

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

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

应用场景多个子系统都需要处理这些事件需要实时处理，且延迟越小越好处理逻辑比较复杂的场景，比如要对事件继续模式匹配或者基于时间窗口的聚合事件量级非常大，生产的速度也很快架构优势生产者和消费者解耦没有点对点的集成，增加新消费者几乎没有难度消费者可以即时处理到来的事件天生分布式、可扩展性非常高每个下游子系统都可以访问全部事件，且互相独立有哪些挑战不丢事件：一些业务场景要求，事件必须发送成功，不能丢。比如金融、电商等涉及钱的场景；按顺序消费：由于架构的分布式特性，消费者本身就是多实例的，不支持全局有序消费；exactly-once消费：事件消费的每个环节都可能会失败，失败就会重试。重试的话，就需要额外的机制去保障exactly once补充说明

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

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

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

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

标签：

服务架构：事件驱动架构

广告

广告

服务架构：事件驱动架构

为您推荐

广告

广告