共计 3125 个字符，预计需要花费 8 分钟才能阅读完成。
作者：肯梦
阿里云音讯队列 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）发送音讯。模型如下：
音讯驱动模式下通常会用到中间件，比拟常见的两头组件有 RocketMQ，Kafka，RabbitMQ 等。这些中间件的目标是缓存生产者投递的音讯直到消费者筹备接管这些音讯，以此将两端零碎解耦。
在音讯驱动架构中，音讯的格局是基于消费者的需要制订的；消息传递能够是一对一，多对多，一对多或多对一。
音讯驱动通信比拟常见的一个例子是商品订单推送，上游组件负责生成订单，上游组件负责接管订单并解决。通过这样的通信形式上游生成组件其实无需关怀整个订单的生命周期，更专一于如何疾速生成订单，使单个组件的性能得以晋升。!
音讯驱动模式在服务之间提供了轻的耦合（这部分耦合指代 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. offset，time）是有状态的。有状态操作中，流解决逻辑必须保留一些已被生产音讯的内存。有状态包含对数据做 Batch Size，Batch 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 作为下一代消息中间件，也是目前的重点方向之一。如果大家感兴趣，想要有更多理解，可关注 「阿里云 EventBridge 系列公开课」，残缺课程正炽热开讲中！
点击 此处 ，能够间接观看课程视频～
