基于 RocketMQ 构建阿里云事件驱动引擎EventBridge

‍

‍作者：尘央

审核&校对：白玙

编辑&排版：酒圆

以 Kubernetes 为基础设施的云原生技术，彻底改变了我们的开发和思维模式。事件作为云原生领域的一等公民，已经无处不在，是云原生架构体系松耦合、灵活性的基础。

作为 Gartner 定义的 10 大战略技术趋势之一，事件驱动架构（EDA）逐渐成为主流技术架构。根据 Gartner 的预估，到 2022 年，在新型数字化商业的解决方案中，将有 6 成使用 EDA，在商业组织参与的技术栈中，EDA 有一半的占比。

本文将介绍事件、事件驱动架构、阿里云事件驱动引擎 EventBridge 及其在事件的标准化、中心化、事件驱动架构上的能力。

事件及事件驱动架构

Aliware

1

事件

事件是已经发生的事实，并且是不可变的。相比而言，消息是一个服务为了另一个服务的消费或存储而生产的原始数据，消息是可以被修改的。

事件的生产者如实地产生和投递事件，它不关心这个事件将由谁、因何，以及怎样去处理。而消息的生产者是知道谁来消费的，并且知道封装哪些因素到消息中，以便消费者处理。

事件的 Broker 被设计为提供事实日志。事件在超时时间后被删除，这个超时时间是由组织或者业务定义的。而消息的 Broker 被设计为处理各类问题的，当消费者感知到消息后，消息即可被删除。

	事件	消息
Data	已经发生的事实，并且不可变(Immutable)	为消费或存储而生产的原始数据
Producer/Consumer	生产者不知道消费者是谁以及如何处理	生产者知道消费者是谁以及如何处理
Broker	提供事实日志 超时时间后，事件被删除	处理各类问题 被消费者感知后，消息被删除

• 离散事件：描述状态(state)的变化 可执行的

• 连续事件：描述处于怎样的状态(condition) 可分析的

通常，事件是离散的，用于描述一个事物的状态变化，可以被执行。消费者根据离散事件所描述的状态，执行相应的动作。

事件也可以是连续数据流中的一部分，用来描述一个事物当前处于某种状态下。这些连续的事件是可分析的，消费者可以根据这些状态的变化，分析出某种趋势及背后的原因。

事件应当被设计为最小尺寸、最简类型、单一目的。这里要着重介绍下 CloudEvents。CloudEvents 在 2018 年 5 月进入 CNCF 基金会的沙箱项目，然后只用了1年多时间就成为 CNCF 的孵化项目，其发展速度非常快。CloudEvents 将会成为云服务之间，事件通讯的标准协议。同时要强调的是，CloudEvents 已经发布了多个消息中间件的绑定规范。

CloudEvents

• 2017 年 12 月 启动

• 2018 年 05 月 CNCF 沙箱项目

• 2019 年 10 月 1.0 CNCF 孵化项目

• 2020 年 12 月 1.0.1

2

事件驱动

事件驱动架构是一种围绕着事件的生产、探测、消费，及响应的软件架构范式。为云原生应用的分布式和伸缩性，提供了基础保证。事件驱动架构天然的异步特性，使云原生应用在设计上，可以根据 DDD 理论，清晰地划分出服务间的上下文边界，优雅地实现松耦合。

1、事件的传递模式

我们走近事件驱动，来看一下事件的传递模式。与请求驱动不同，事件驱动的两端不是直连的。

事件的传递模式包含如下三种。

基于队列的生产者-消费者模式。这是一种单一接收者的模式，用于两个服务之间的事件传递。生产者服务并不关心消费者服务如何处理事件。