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

简介: 事件驱动架构(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、对于单一的逻辑缺乏原子事务


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


模式分析


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


  • 总体灵活性:


  • 发布易用性:


  • 可测试性:


  • 性能:


  • 规模扩展性:


  • 开发容易度:


相关文章
|
5天前
|
弹性计算 Kubernetes Serverless
Kubernetes 的架构问题之Serverless Container中不支持特权模式的问题如何解决
Kubernetes 的架构问题之Serverless Container中不支持特权模式的问题如何解决
27 6
|
2天前
|
弹性计算 监控 数据挖掘
事件驱动架构的优势与应用:深度解析与实战应用
【8月更文挑战第17天】事件驱动架构以其松耦合、可扩展性、异步处理、实时性和高可靠性等优势,在实时数据处理、复杂业务流程、弹性伸缩和实时通信等多个领域展现出巨大的应用潜力。通过合理应用事件驱动架构,可以构建灵活、可扩展和可维护的系统架构,满足不断变化的业务需求和技术挑战。对于开发者而言,深入理解事件驱动架构的核心概念和优势,将有助于更好地设计和实现高质量的软件系统。
|
9天前
|
设计模式 监控 API
探索微服务架构中的API网关模式
在微服务的宇宙里,API网关是连接星辰的桥梁。它不仅管理着服务间的通信流量,还肩负着保护、增强和监控微服务集群的重任。本文将带你走进API网关的世界,了解其如何成为微服务架构中不可或缺的一环,以及它在实际应用中扮演的角色和面临的挑战。
|
14天前
|
消息中间件 缓存 Kafka
混合云中的事件驱动架构
混合云中的事件驱动架构
23 4
|
15天前
|
负载均衡 监控 API
探索微服务架构中的API网关模式
在微服务架构的海洋中,API网关扮演着枢纽的角色。它不仅是客户端请求的接收者,也是各个微服务间通信的协调者。本文将深入探讨API网关的设计原则、实现策略以及它在微服务生态中的重要性。我们将通过实际案例分析,了解API网关如何优化系统性能、提高安全性和简化客户端与服务的交互。
31 4
|
20天前
|
负载均衡 监控 API
探索微服务架构中的API网关模式
【7月更文挑战第30天】在微服务架构的复杂网络中,API网关扮演着交通枢纽的角色,不仅简化了客户端与各微服务的交互,还提升了系统的安全性和可维护性。本文将深入探讨API网关的设计原则、核心功能以及在实际应用中的部署策略,旨在为后端开发者提供一套完整的API网关解决方案。
|
17天前
|
运维 负载均衡 监控
探索微服务架构中的API网关模式
在当今分布式系统和微服务架构日益盛行的背景下,API网关作为一种重要的设计模式,承担着请求路由、负载均衡、认证授权、监控统计等关键职责。本文将深入探讨API网关在微服务架构中的作用,分析其实现机制,以及如何在实际应用中高效地部署和管理API网关,从而提升系统的可扩展性、安全性和可维护性。
20 2
|
20天前
|
监控 负载均衡 API
探索微服务架构中的API网关模式
在现代后端开发中,微服务架构因其灵活性和可扩展性而受到青睐。然而,随着服务的增多,如何有效管理和路由请求变得至关重要。API网关作为微服务架构中的一个关键组件,承担着请求转发、负载均衡和服务聚合等职责。本文将深入探讨API网关的设计原则、实现技术以及在实际应用中面临的挑战和解决方案。
|
12天前
|
消息中间件 前端开发 编译器
10种常见的软件架构模式简述
10种常见的软件架构模式简述
|
19天前
|
运维 Kubernetes Cloud Native
云原生技术浪潮下的微服务架构演进
在数字化转型的风潮中,云原生技术以其灵活性、可扩展性和弹性成为企业IT战略的核心。本文深入探讨了微服务架构如何借助云原生环境进行优化,并分析了容器化、服务网格等技术如何助力微服务更好地适应云原生生态。通过案例分析,我们揭示了微服务在现代云平台上的实践挑战与解决策略,同时对未来的技术趋势进行了预测。
36 0