事件驱动作为分布式异步服务架构

本文涉及的产品
性能测试 PTS,5000VUM额度
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
可观测可视化 Grafana 版,10个用户账号 1个月
简介: 【6月更文挑战第25天】本文介绍事件驱动架构(EDA)是异步分布式设计的关键模式,适用于高扩展性需求。EDA提升服务韧性,支持CQRS、数据通知、开放式接口和事件流处理。然而,其脆弱性包括组件控制、数据交换、逻辑关系复杂性、潜在死循环和高并发挑战。EDA在云原生环境,如Serverless,中尤其适用。

1 简介

事件驱动架构模式是一种主流的异步分发事件架构模式,常用于设计高度可拓展的应用。当然了,它有很高的适应性,使得它在小型应用、大型应用、复杂应用中都能表现得很好。

该模式具有高度适应性的分布式异步体系结构,此模式最适合具有高可伸缩性的小型到大型应用程序。

由于事件处理器组件在此模式中彼此隔离,因此可以在不影响其他组件性能的情况下对组件进行更改。

此模式有两个主要结构: 中介和代理结构.

事件(Event)是状态发生变化时软件发出的通知,结构图可以直接查看本文末尾。

2 事件中介模式 Mediator结构

事件驱动架构(Event-driven Architecture)是通过事件进行通信的软件架构,它分成四个部分

事件队列 Event Queue  接收事件的入口
事件分发器 Event Mediator 将不同的事件分发到不同的业务逻辑单元
事件通道   Event Channel  分发器和处理器的联系通道
事件处理器 Event Processor  实现业务逻辑,处理完后发出事件触发下一步

当事件具有多个步骤需要通过中央处理器进行某种程度协调时,将使用中介器。
当用户将初始事件发送到事件队列时,初始事件将定向到事件中介器。

事件驱动包含两种结构:

   Mediator 用于多步骤事件需协调,由事件队列、分发器、通道和处理器组成;
   Broker 则直接代理事件,无中间分发。

接收初始事件将提示事件中介器发布处理事件并将其发送到事件通信,告诉它们开始执行每个步骤。
从事件通道接收处理事件的事件处理器包括执行处理初始事件所需的全部步骤的业务逻辑组件。

image.png

通常事件处理器组件只执行单个业务任务,不依赖其他事件处理器,这是由于已设置事件处理器与其他处理器同步运行。

对于简单的项目,事件队列、分发器和事件通道可以合为一体,整个软件就分成事件代理
和事件处理器两部分。

3 事件代理结构 Broker结构

代理模式用于事件不需要中介分发或协调事件的流程。代理结构有两个主要组件:

代理人
事件处理器

代理组件包含此事件流的所有事件通道。这些事件通道可以是消息队列、消息主题或两者的组合。

在代理拓扑中,事件处理器组件直接接收事件,并负责处理和发布新事件以指示事件已处理。

事件连续流经处理器组件链,直到不再为初始事件发布事件。

这种进程分布允许事件驱动的体系结构以最小的资源消耗运行大量并发连接。

image.png

4 优点

事件驱动架构(EDA,Event DrivenArchitecture)本质上是一种应用/组件间的集成架构模式。

事件和传统的消息不同,事件具有schema,所以可以校验event的有效性,同时EDA具备QoS保障机制,也能够对事件处理失败进行响应。事件驱动架构不仅用于(微)服务解耦,还
可应用于下面的场景中。

(1)增强服务韧性 

由于服务间是异步集成的,也就是下游的任何处理失败甚至宕机都不会被上游感知,自然也就不会对上游带来影响。

(2)CQRS(Command Query Responsibility Segregation):把对服务状态有影响的命令用事件来发起。而对服务状态没有影响的查询才使用同步调用的API接口;

结合EDA中的EventSourcing机制可以用于维护数据变更的一致性,当需要重新构建服务状态时,把EDA中的事件重新“播放”一遍即可。

(3)数据变化通知 

在服务架构下,往往一个服务中的数据发生变化,另外的服务会感兴趣,比如用户订单完成后,积分服务、信用服务等都需要得到事件通知并更新用户积分和信用等级。

(4)构建开放式接口

在EDA下,事件的提供者并不用关心有哪些订阅者,不像服务调用的场景——数据的产生者需要知道数据的消费者在哪里并调用它,因此保持了接口的开放性。

(5)事件流处理

应用于大量事件流(而非离散事件)的数据分析场景,典型应用是基于Kafka的日志处理。

基于事件触发的响应:在IoT时代大量传感器产生的数据,不会像人机交互一样需要等待处理结果的返回,天然适合用EDA来构建数据处理应用。

5 弱点

事件驱动架构的脆弱性主要表现在:

(1)组件的脆弱性。组件削弱了自身对系统的控制能力,一个组件触发事件,并不能确定
响应该事件的其他组件及各组建的执行顺序。

(2)组件间交换数据的脆弱性。组件不能很好地解决数据交换问题,事件触发时,一个
组件有可能需要将参数传递给另一个组件,而数据量很大的时候,如何有效传递是一个脆弱性
问题。

(3)组件间逻辑关系的脆弱性。事件架构使系统中各组件的逻辑关系变得更加复杂。

(4)事件驱动容易进入死循环,这是由编程逻辑决定的。

(5)高并发的脆弱性。虽然事件驱动可实现有效利用CPU资源,但是存在高并发事件处理
造成的系统响应问题,而且,高并发容易导致系统数据不正确、丢失数据等现象。

(6)固定流程的脆弱性。因为事件驱动的可响应流程基本都是固定的,如果操作不当,容
易引发安全问题,

6 小结

事件驱动架构是一种流行的分布式异步架构,是一种适合高扩展工程的、较流行的分布式
异构架构模式,有较高柔性,它由高度解耦、单一目的异步接收的事件处理组件和处理事件组
成。

事件驱动架构通常有两种拓扑结构:Mediator结构和Broker结构,

Mediator结构通常适用于事件的多个步骤需要通过中间角色来指挥和协调的情形。

Broker结构适用于事件是链式关系而不需要中间角色的情形。

云原生应用Serverless非常适合于事件驱动的数据计算任务、计算时间短的请求/响应应用、没有复杂相互调用的长周期任务。

云原生Lambda架构的诞生离不开很多现有设计思想和架构的铺垫,如事件溯源(Event Sourcing)
架构和命令查询分离(Command Query Responsibility Segregation,CQRS)架构,Lambda架构
的设计思想和这两者有一定程度的相似。

目录
相关文章
|
10天前
|
存储 缓存 NoSQL
分布式系统架构8:分布式缓存
本文介绍了分布式缓存的理论知识及Redis集群的应用,探讨了AP与CP的区别,Redis作为AP系统具备高性能和高可用性但不保证强一致性。文章还讲解了透明多级缓存(TMC)的概念及其优缺点,并详细分析了memcached和Redis的分布式实现方案。此外,针对缓存穿透、击穿、雪崩和污染等常见问题提供了应对策略,强调了Cache Aside模式在解决数据一致性方面的作用。最后指出,面试中关于缓存的问题多围绕Redis展开,建议深入学习相关知识点。
83 8
|
29天前
|
存储 Prometheus Cloud Native
分布式系统架构6:链路追踪
本文深入探讨了分布式系统中的链路追踪理论,涵盖追踪与跨度的概念、追踪系统的模块划分及数据收集的三种方式。链路追踪旨在解决复杂分布式系统中请求流转路径不清晰的问题,帮助快速定位故障和性能瓶颈。文中介绍了基于日志、服务探针和边车代理的数据收集方法,并简述了OpenTracing、OpenCensus和OpenTelemetry等链路追踪协议的发展历程及其特点。通过理解这些概念,可以更好地掌握开源链路追踪框架的使用。
84 41
|
13天前
|
存储 缓存 安全
分布式系统架构7:本地缓存
这是小卷关于分布式系统架构学习的第10篇文章,主要介绍本地缓存的基础理论。文章分析了引入缓存的利弊,解释了缓存对CPU和I/O压力的缓解作用,并讨论了缓存的吞吐量、命中率、淘汰策略等属性。同时,对比了几种常见的本地缓存工具(如ConcurrentHashMap、Ehcache、Guava Cache和Caffeine),详细介绍了它们的访问控制、淘汰策略及扩展功能。
37 6
|
16天前
|
存储 关系型数据库 分布式数据库
[PolarDB实操课] 01.PolarDB分布式版架构介绍
《PolarDB实操课》之“PolarDB分布式版架构介绍”由阿里云架构师王江颖主讲。课程涵盖PolarDB-X的分布式架构、典型业务场景(如实时交易、海量数据存储等)、分布式焦点问题(如业务连续性、一致性保障等)及技术架构详解。PolarDB-X基于Share-Nothing架构,支持HTAP能力,具备高可用性和容错性,适用于多种分布式改造和迁移场景。课程链接:[https://developer.aliyun.com/live/253957](https://developer.aliyun.com/live/253957)。更多内容可访问阿里云培训中心。
[PolarDB实操课] 01.PolarDB分布式版架构介绍
|
1月前
|
设计模式 存储 算法
分布式系统架构5:限流设计模式
本文是小卷关于分布式系统架构学习的第5篇,重点介绍限流器及4种常见的限流设计模式:流量计数器、滑动窗口、漏桶和令牌桶。限流旨在保护系统免受超额流量冲击,确保资源合理分配。流量计数器简单但存在边界问题;滑动窗口更精细地控制流量;漏桶平滑流量但配置复杂;令牌桶允许突发流量。此外,还简要介绍了分布式限流的概念及实现方式,强调了限流的代价与收益权衡。
83 11
|
1月前
|
设计模式 监控 Java
分布式系统架构4:容错设计模式
这是小卷对分布式系统架构学习的第4篇文章,重点介绍了三种常见的容错设计模式:断路器模式、舱壁隔离模式和重试模式。断路器模式防止服务故障蔓延,舱壁隔离模式通过资源隔离避免全局影响,重试模式提升短期故障下的调用成功率。文章还对比了这些模式的优缺点及适用场景,并解释了服务熔断与服务降级的区别。尽管技术文章阅读量不高,但小卷坚持每日更新以促进个人成长。
57 11
|
1月前
|
消息中间件 存储 安全
分布式系统架构3:服务容错
分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!
70 11
|
3月前
|
NoSQL Java Redis
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
Redis分布式锁在高并发场景下是重要的技术手段,但其实现过程中常遇到五大深坑:**原子性问题**、**连接耗尽问题**、**锁过期问题**、**锁失效问题**以及**锁分段问题**。这些问题不仅影响系统的稳定性和性能,还可能导致数据不一致。尼恩在实际项目中总结了这些坑,并提供了详细的解决方案,包括使用Lua脚本保证原子性、设置合理的锁过期时间和使用看门狗机制、以及通过锁分段提升性能。这些经验和技巧对面试和实际开发都有很大帮助,值得深入学习和实践。
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
|
1月前
|
存储 NoSQL Java
使用lock4j-redis-template-spring-boot-starter实现redis分布式锁
通过使用 `lock4j-redis-template-spring-boot-starter`,我们可以轻松实现 Redis 分布式锁,从而解决分布式系统中多个实例并发访问共享资源的问题。合理配置和使用分布式锁,可以有效提高系统的稳定性和数据的一致性。希望本文对你在实际项目中使用 Redis 分布式锁有所帮助。
180 5
|
2月前
|
NoSQL Java 数据处理
基于Redis海量数据场景分布式ID架构实践
【11月更文挑战第30天】在现代分布式系统中,生成全局唯一的ID是一个常见且重要的需求。在微服务架构中,各个服务可能需要生成唯一标识符,如用户ID、订单ID等。传统的自增ID已经无法满足在集群环境下保持唯一性的要求,而分布式ID解决方案能够确保即使在多个实例间也能生成全局唯一的标识符。本文将深入探讨如何利用Redis实现分布式ID生成,并通过Java语言展示多个示例,同时分析每个实践方案的优缺点。
95 8