服务架构：事件驱动架构

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

创新互联专业为企业提供隆昌网站建设、隆昌做网站、隆昌网站设计、隆昌网站制作等企业网站建设、网页设计与制作、隆昌企业网站模板建站服务，十年隆昌做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。

事件驱动架构

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

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

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

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

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

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

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

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

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

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

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

应用场景

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

架构优势

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

有哪些挑战

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

补充说明

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

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

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

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

文章名称：服务架构：事件驱动架构
当前地址：http://www.csdahua.cn/qtweb/news27/67477.html

网站建设、网络推广公司-快上网，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 快上网