软件架构模式之事件驱动架构

简介: 事件驱动架构(Event Driven Architecture)是一个流行的分布式异步架构模式,可以用来设计规模很大的应用程序。基于这种架构模式应用可大可小。它由高度解耦的,单一目的的事件处理组件组成,可以异步地接收和处理事件。

微信图片_20220608111124.jpg

事件驱动架构


事件驱动架构(Event Driven Architecture)是一个流行的分布式异步架构模式,可以用来设计规模很大的应用程序。基于这种架构模式应用可大可小。它由高度解耦的,单一目的的事件处理组件组成,可以异步地接收和处理事件。


一个事件驱动系统典型地由事件消费者和事件产生者组成,事件消费者向事件管理器订阅事件,事件产生者向事件管理器发布事件。当事件管理器从事件产生者那接收到一个事件时,事件管理把这个事件转送给相应的事件消费者。如果这个事件消费者是不可用的,事件管理者将保留这个事件,一段间隔之后再次转送该事件消费者。


关键概念解释


事件:系统或组件的状态发生变化时,系统层发出的通知。


解耦方式:每个对象都通过与中间件(Mediator or Broker)实现与外界的沟通,而不是相互依赖(迪米特法则)。


通讯方式:以消息为载体、通过中间件传递通讯。


拓扑结构分类


它包括两个主要的拓扑结构:mediator 和 broker。


  • mediator拓扑结构


需要你在一个事件通过mediator时精心安排好几个步骤;


  • broker拓扑结构


无需mediator,而是由你串联起几个事件。


这两种拓扑架构的特征和实现有很大的不同,所以你需要知道哪一个适合你。


Mediator拓扑结构


Mediator拓扑结构适合有多个步骤的事件,需要安排处理层次。


采用Mediator模式的架构中,事件一般是复杂的(包含多个执行单元的合集),而Mediator的责任就是将该复合事件拆解为独立的子事件,然后发送到不同类型的子事件处理系统中,由子系统完成独立子事件的分发和处理。


在结构上,Mediator的EDA架构包括4个组件:


  • event queues


用于原始事件(分类)存储,并转发给Event Mediator,一般是以MQ的形式存在。


  • event mediator


用于原始事件的拆解(成为多个独立子事件),并转发给相关的Channel;


  • event channels


通道(可以理解为细分的Event Queue),按照事件的类型不同作以划分。它可以是一个消息队列,提供给特定的Processor查询,或是消息Topic,发送特定的广播。


  • event processors


事件处理器,监听特定的Channel,并在捕获事件后进行处理


Mediator的处理过程如下图所示:


微信图片_20220608111126.png


  • 客户端发送一个事件到事件队列(event queues)中,它用来将事件传送给event mediator;


  • Event mediator收到初始的事件后,会发送额外的一些异步事件给event channels来执行处理的每个步骤;


  • Event channels 既可以是消息队列,也可以是消息topic,大部分是消息topic,这样可以由多个消息处理器(event processor)处理同一个消息。


  • Event processors监听event channels,接收事件并处理一些业务逻辑。


值得注意的是:


1、在事件驱动架构中有十几个甚至几百个事件队列都很正常。


2、模式本身没有限定事件队列的实现方式,它可能是一个消息队列,一个web service或者其它;


3、消息处理器包含实际的业务逻辑。每个消息处理器都是自包含的,独立的,高度解耦的,执行单一的任务。


Broker拓扑架构


Broker是一种更简洁的事件驱动架构,不同于上面的结构,它没有中心的Mediator。


在结构上,Broker的EDA架构包括3个组件:


  • Event


事件消息;


  • Event Channel


消息队列或者是Topic,根据订阅推送(或是转发)消息;消息可能被转发到Event Processor,或是其他的Event Channel中。


  • Event Processor


获得消息后执行处理。它可能是一个消息的处理终结点,也可能在处理过程中继续下发消息,或生成新的事件,并被再次提交到Event Channel中,继续下一轮的转发和处理。

微信图片_20220608111129.png


如图所示,它包含两个组件broker和 event processor。


  • broker中的event channel可以是消息队列,消息topic或者它们的复合形式。


  • 每个event processor负责处理事件,发布新的事件。


架构考量


事件驱动架构模式实现起来相对复杂,主要是由于它的异步和分布式特性。这可能会带来一些分布式的问题,比如远程处理的可用性,缺乏响应,broker重连等问题。


1、分布式的异步架构


事件处理器之间高度解耦,软件的扩展性好,事件处理器可以独立地加载和卸载,容易部署,同时性能较好,因为事件的异步本质,软件不易产生堵塞。


2、对于单一的逻辑缺乏原子事务


此模式需要将原子事务交给一个事件处理器执行,跨事件处理器的原子事务是很困难的,很难进行回滚操作。同时对于事件处理器的创建,维护和管理比较困难,事件通常有特殊的约定(数据值和格式)。


模式分析


结合上文分析,事件驱动架构设计模式整体分析如下:


  • 总体灵活性:


  • 发布易用性:


  • 可测试性:


  • 性能:


  • 规模扩展性:


  • 开发容易度:


相关文章
|
6天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
1月前
|
分布式计算 Kubernetes Hadoop
大数据-82 Spark 集群模式启动、集群架构、集群管理器 Spark的HelloWorld + Hadoop + HDFS
大数据-82 Spark 集群模式启动、集群架构、集群管理器 Spark的HelloWorld + Hadoop + HDFS
148 6
|
1月前
|
缓存 监控 API
探索微服务架构中的API网关模式
【10月更文挑战第5天】随着微服务架构的兴起,企业纷纷采用这一模式构建复杂应用。在这种架构下,应用被拆分成若干小型、独立的服务,每个服务围绕特定业务功能构建并通过HTTP协议协作。随着服务数量增加,统一管理这些服务间的交互变得至关重要。API网关作为微服务架构的关键组件,承担起路由请求、聚合数据、处理认证与授权等功能。本文通过一个在线零售平台的具体案例,探讨API网关的优势及其实现细节,展示其在简化客户端集成、提升安全性和性能方面的关键作用。
72 2
|
1月前
|
分布式计算 资源调度 Hadoop
大数据-80 Spark 简要概述 系统架构 部署模式 与Hadoop MapReduce对比
大数据-80 Spark 简要概述 系统架构 部署模式 与Hadoop MapReduce对比
64 2
|
1月前
|
消息中间件 监控 测试技术
事件驱动架构是一种编程范式
【10月更文挑战第7天】事件驱动架构是一种编程范式
107 65
|
14天前
|
缓存 监控 API
探索微服务架构中的API网关模式
随着微服务架构的兴起,API网关成为管理和服务间交互的关键组件。本文通过在线零售公司的案例,探讨了API网关在路由管理、认证授权、限流缓存、日志监控和协议转换等方面的优势,并详细介绍了使用Kong实现API网关的具体步骤。
35 3
|
14天前
|
存储 缓存 监控
探索微服务架构中的API网关模式
探索微服务架构中的API网关模式
35 2
|
1月前
|
存储 消息中间件 人工智能
ApsaraMQ Serverless 能力再升级,事件驱动架构赋能 AI 应用
本文整理自2024年云栖大会阿里云智能集团高级技术专家金吉祥的演讲《ApsaraMQ Serverless 能力再升级,事件驱动架构赋能 AI 应用》。
|
1月前
|
存储 设计模式 监控
事件驱动架构的实现方式?
【10月更文挑战第7天】事件驱动架构的实现方式?
42 7
|
4天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####