北京南站,wordpress wp_query 排序,网站免费申请注册,素材库网站简介#xff1a;本文旨在帮助大家对近期消息领域的高频词“消息驱动#xff08;Message-Driven#xff09;#xff0c;事件驱动#xff08;Event-Driven#xff09;和流#xff08;Streaming#xff09;”有更清晰的了解和认知#xff0c;其中事件驱动 EDA 作为 Gartn…简介本文旨在帮助大家对近期消息领域的高频词“消息驱动Message-Driven事件驱动Event-Driven和流Streaming”有更清晰的了解和认知其中事件驱动 EDA 作为 Gartner 预测的十大技术趋势之一 EventBridge 作为下一代消息中间件也是目前的重点方向之一。
作者肯梦
阿里云消息队列 RocketMQ 5.0 实现了全新升级实现了从“消息”到“消息、事件、流”的大融合基于此Message-Driven、Event-Driven、Streaming 这三个词是近期消息领域高频词但由于概念过于新很多同学其实是不太理解这里的异同。本文把三个概念重新整理下梳理出比较明确的概念讲给大家。
背景
首先这三个概念具体翻译如下
Message-Driven消息驱动的通信Event- Driven事件驱动的通信Streaming流模式。
这三个模式都是类似异步通信的模式发送消息的服务不会等待消费消息服务响应任何数据做服务解耦是三个模式共同的特性
只要是在服务通讯领域内在选型时还要考虑如下特性
排序是否可以保证特定的顺序交付事务生产者或消费者是否可以参与分布式事务持久化数据如何被持久化以及是否可以重放数据订阅过滤是否拥有根据Tag或其他字段做订阅过滤的能力At – least -once最少交付一次At-most-once最多交付一次Exactly-once 精确交付。
通用背景介绍完依次来看看各个模型代表的是什么意思。
消息驱动 Message-Driven
在消息驱动通信中一般链路就是消息生产者Producer向消息消费者Consumer发送消息。模型如下 消息驱动模式下通常会用到中间件比较常见的中间组件有 RocketMQKafkaRabbitMQ 等。这些中间件的目的是缓存生产者投递的消息直到消费者准备接收这些消息以此将两端系统解耦。
在消息驱动架构中消息的格式是基于消费者的需求制定的消息传递可以是一对一多对多一对多或多对一。
消息驱动通讯比较常见的一个例子是商品订单推送上游组件负责生成订单下游组件负责接收订单并处理。通过这样的通讯方式上游生成组件其实无需关心整个订单的生命周期更专注于如何快速生成订单使单个组件的性能得以提升。 消息驱动模式在服务之间提供了轻的耦合这部分耦合指代 Producer/Consumer SDK并可以对生产和消费服务根据诉求进行扩展。
事件驱动 Event-Driven
首先要申明一个观点事件驱动其实是对消息驱动方法的改进它对消息体大小消息格式做了较为严格的限制这层基于消息的限制封装其实就称为事件Event。
在事件驱动模式中生产者发布事件来表示系统变更任何感兴趣且有权限接入的服务都可以订阅这些事件并将这些事件作为触发器来启动某些逻辑/存储/任务。 事件驱动的模式可以是一对一多对一一对多或多对多。通常情况下一般是多个目标根据过滤条件执行不同的事件。
在事件驱动架构中事件的格式是由生产者根据事件标准协议制定的由于更规范限制和封装事件的生产者完全不需要关心有哪些系统正在消费它生成的事件。
事件不是命令事件不会告诉消费者如何处理信息他们的作用只是告诉消费者此时此刻有个事件发生了事件是一份不可变的数据重要的数据它与消息的数据价值相同通常情况下当某个事件发生并执行时往往伴随着另一个事件的产生。
事件驱动提供了服务间的最小耦合并允许生产服务和消费服务根据需求进行扩展事件驱动可以在不影响现有服务的情况下添加各类新增组件。
事件驱动也可以举一个非常贴切的例子我们以“客户购买完一款商品”为一个事件举证在事件场景的应用
CRM客户关系系统系统接收到客户购买信息可自行更新客户的购买记录EMR库存管理系统 系统接收到客户购买信息动态调整库存并及时补货快递服务接收到客户购买信息自行打单并通知快递公司派送。
这么看事件驱动模式是不是可以应用并出现在任何地方
在 EventBridge 产品化方向也正是由于针对消息做了一些标准化封装才有可能实现譬如针对事件本身的 filter过滤 transform转换schema事件结构search查询 等能力。这些能力也拓展出更多针对事件驱动特有的场景功能及相关特性。
流 Streaming
流是一组有序的无界事件或数据执行操作通常是固定的某个事件段e.g. 00:00 – 12:00或一个相对事件E.g. 过去 12 小时。 通常情况下单个事件往往就是使用事件本身但是对于流可能的操作大概率是过滤组合拆分映射等等。
流的操作可以是无状态也可以是有状态的
对于单个事件操作是无状态的包括过滤和映射依赖消息在流的时间或位置e.g. offsettime是有状态的。有状态操作中流处理逻辑必须保留一些已被消费消息的内存。有状态包括对数据做 Batch SizeBatch Window 等。
流这里也可以举一个比较简单的例子比如我们的物流系统在物品通过一个物流节点时会生成一个事件但是要查到这个物品完整的流转状态事件则必须是各个物流节点单个事件的聚合那这个聚合事件就是流事件。
Kafka 是最典型的流式中间件在流式场景中事件的位置信息至关重要。通常情况下位置信息E.g. offset是由消费者托管的。
事件规范标准
聊完 Event 和 Streaming 是什么再来补充一点有关于它们的规范。
事件规范存在的目的是为了清晰事件生产者和消费者的关系目前主要有两部分AsyncAPI 和 CloudEvents
AsyncAPI基于事件 API 提供了与之对应的 Open API 和 Swagger 等CloudEvents侧重于处理事件的元数据。
下面也重点介绍一些关于 CloudEvents 的相关概念参考CloudEvents 的核心其实是定义了一组关于不同组件间传输事件的元数据以及这些元数据应该如何出现在消息体中。
其主旨大抵如下
事件规范化降低平台集成难度提高 FaaS 的可移植性源事件可追踪提升事件关联性
准确的事件体事件信息才可以做出更稳定的系统架构永远保持对事件的敬畏。
附 一些术语及定义
Occurrence发生指事件逻辑上的发生基于某种情况事件出现了
Event事件表示事件以及上下文的数据记录。可以根据事件中的信息决定路由但事件本身并不包含路由信息
Producer生产者真正创造事件的实例或组件
Source源事件发生的上下文可以由多个 producer 组成
Consumer消费者接收事件并对事件进行消费
Intermediary中介接收包含事件的消息message并转发给下一个接收方类似路由器
Context上下文上下文元数据被封装到 context attributes 中用来判断事件与其它系统的关系
Data数据也可以叫做 payload
EventFormat事件格式例如 json
Message消息封装事件并将其从 source 传递到 destination
Protocol协议可以是行业标准如 http开源协议如 Kafka 或者供应商协议如 AWS Kinesis
Protocol Binding协议绑定描述如何通过给定的协议收发事件如何将事件放到消息里。
重磅推荐
本文旨在帮助大家对近期消息领域的高频词“消息驱动Message-Driven事件驱动Event-Driven和流Streaming”有更清晰的了解和认知其中事件驱动 EDA 作为 Gartner 预测的十大技术趋势之一 EventBridge 作为下一代消息中间件也是目前的重点方向之一。
原文链接
本文为阿里云原创内容未经允许不得转载。
