简介：阿里云事件总线 EventBridge 作为云上的事件枢纽，最外围的能力是连贯。无论是在线业务场景、IoT 场景、还是大数据场景，无论是阿里云、其余云厂商，还是公有 IDC 机房，咱们都将提供安全可靠的集成形式。

作者 | 六翁

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

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

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

事件及事件驱动架构

1、事件

事件是曾经产生的事实，并且是不可变的。相比而言，音讯 是一个服务为了另一个服务的生产或存储而生产的原始数据，音讯是能够被批改的。

事件的生产者如实地产生和投递事件，它不关怀这个事件将由谁、因何，以及怎么去解决。而音讯的生产者是晓得谁来生产的，并且晓得封装哪些因素到音讯中，以便消费者解决。

事件的 Broker 被设计为提供事实日志。事件在超时工夫后被删除，这个超时工夫是由组织或者业务定义的。而音讯的 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) 事件的传递模式

咱们走近事件驱动，来看一下事件的传递模式。与申请驱动不同，事件驱动的两端不是直连的。
事件的传递模式蕴含如下三种。

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

基于队列的异步申请 - 回调模式。这种模式和申请驱动的 request-response 相似，是异步的 request-reply 或者叫 request-callback，同样用于两个服务之间的事件传递。生成者服务会关怀消费者服务随后生产的响应事件。

基于主题的发布者 - 订阅者模式。这是一种多对多的模式。发布者服务可能生产不同类型的事件，并将其传输给不同的主题，订阅者服务可能订阅一个或者多个主题，以实现对不同类型事件的解决。

### 2) 事件的服务定义模式

咱们再来理解下事件的服务定义模式。

咱们曾经晓得，事件的生产者并不知道消费者是谁，因而不能像音讯那样事后定义音讯的格局。因而，在事件驱动架构中，须要一个 Schema Registry 为生产者提供序列化根据，为消费者提供反序列化根据。

Schema 相似 gRPC 中的 proto 定义。在申请驱动模式下，gRPC 的服务端和客户端会别离依据 proto 定义，生成 stub 模板代码。而后将模板代码提供给本人的下层代码调用，从而实现序列化和反序列化。

与之相似，在事件驱动模式下，消费者在获取事件后，能够依据 CloudEvents 标准协议，解析出 Schema 和 Content（通常是二进制），而后通过消费者调用 Schema Registry 服务，将 Content 反序列化为事件体。

能够看到，事件的服务定义模式，能够将事件的生产者和消费者充沛地解耦。

## 3、EventBridge

通过下面的介绍，置信你曾经对事件和事件驱动的概念有了较清晰的意识。接下来我介绍下 EventBridge。

EventBridge 是为用户提供 构建 松耦合、分布式的事件驱动架构的 Serverless 事件总线服务。EventBridge 的事件传输和存储遵循 CloudEvents 协定。

在 EventBridge 中，事件的生产者称为 事件源 ，传输和存储事件的介质称为 事件总线 ，事件的消费者称为 事件指标 。事件由 事件规定 转换、匹配、聚合，并路由到事件指标。

EventBridge 连贯了事件生产和生产的两端，利用云原生基础设施的能力及 Serverless 按需生产的特点，为用户提供了低代码、松耦合、高可用的事件处理能力。用户能够以极简的投入，实现强响应能力的 EDA 云原生利用。

同时，EventBridge 基于规范的事件协定，有利于促成各类事件源的事件规范对立，使事件孤岛逐渐交融进残缺的事件生态体系之中。因而，EventBridge 正成为云原生事件驱动架构的规范范式。

那么，EventBridge 是如何联合 Serverless 实现极简的 EDA 利用的呢？在接下来的事件总线范式及利用场景中，我将会具体介绍。

# 事件总线

##

EventBridge 的一大特点是规范事件协定的管道。那么，咱们一起来看一下，阿里云事件总线 EventBridge 实现这个管道能力的各个组成部分。

###

## 1、EventBridge 的组成

### 1）事件源

阿里云 EventBridge 的事件源无所不包。能够是阿里云的各类云产品、阿里云第三方 SaaS 服务，也能够是阿里云用户本人的服务，甚至能够是其余云厂商、边缘服务、公有机房内的服务。用户应用 CloudEvents 的 SDK，即可将事件推送到阿里云事件总线，从而实现事件上云。

### 2）事件总线

为了提供开箱即用的云产品事件处理能力，阿里云 EventBridge 为每个用户提供了租户隔离的默认事件总线。用户所应用的云产品产生的事件，会由这条事件总线传输和存储。

用户能够通过自定义事件总线对接各类事件源，将不同的数据源产生的事件对立采集、存储和响应。

### 3）事件规定

EventBridge 的事件规定的两端别离是事件总线和事件指标。用户通过配置匹配规定、转换规则等，以低代码甚至无代码的形式，实现从事件总线到事件指标的事件过滤、转换和路由。

### 4）事件指标

事件指标是事件被最终解决的中央。阿里云 EventBridge 目前曾经反对了多种事件指标，为用户带来开箱即用的体验。咱们能够为一个告警事件指定钉钉机器人，能够将一个订单事件通过 HTTP 网关传输给用户服务，也能够将事件投递给音讯服务实现事件上云。

当然，云原生的经典事件指标是由 Serverless 服务，因为 Serverless 服务充沛展示了云原生的劣势。

* Serverless 的资源是按需生产的，将弹性施展到极致
* 轻量级的函数具备低提早、高可用的能力，且无运维老本
* 用户编写事件处理函数的学习门槛低、开发代码量小

####

### 5）举个例子

我这里给大家展现个小例子，一起感触下 EventBridge+Serverless 实现 EDA 的轻量化。

首先咱们自定义一个事件总线，将 Kubernenets 容器服务作为事件源，将 Serverless 服务 (函数计算) 作为事件指标。

而后咱们为容器内的资源状态变动事件定义一个事件规定，当这类事件进入事件总线后，将被路由到函数计算服务。

最初，咱们编写并部署一个解决这类事件的函数到函数计算服务，在函数内，首先接管到 CloudEvents 标准协议的事件，通过 Schema Registry 解析事件，最初由函数本身实现事件处理——比方调用容器服务的 API，对资源进行相干操作。

从这个小例子中，咱们能够看到，EventBridge+Serverless 能够让用户以很低的老本疾速实现一个事件驱动的业务。四两拨千斤。

接下来，我将介绍两种事件驱动架构的编排模式，并给出相应的例子，抛砖引玉，心愿能激发你的脑洞，联合本身业务，失去就地取材的事件总线最佳实际。

## 2、事件驱动架构的编排模式

####

### 1）调停者模式

对于解决较简单的事件驱动场景，调停者模式 能帮忙咱们井井有条地对事件进行拆解和剖析，并最终执行指定的动作。调停者模式由三个角色组成：内部服务、调停者、执行者。

首先，内部服务 作为一个事件总线的事件源，将事件传输给事件总线。作为 调停者 的微服务或者函数是这个事件总线的事件指标，接管并解决来自某个事件源的事件。

调停者函数在执行过程中，会将事件处理的多个中间状态作为新的事件，传输到对应的事件总线。此时，调停者是作为这些事件总线的事件源。作为 执行者 的函数是这些事件总线的事件指标。这些函数从事件总线中接管并处理事件，而后产生一个回调事件并传输到相应的事件总线中。能够看出，这里调停者和执行者之间，是后面讲到的异步申请 - 回调模式。

调停者接管到回调事件后，执行调解逻辑，并将后果作为回调事件，通过事件总线，传输给内部服务。

### 2）示例：智能家居

接下来，我来展现一个应用调停者模式实现智能家居的例子。

在这个例子中，咱们将 IoT 设施 / 传感器作为 外部服务 ，将用户的全屋零碎作为 调停者 ，将用户在函数计算中创立的函数作为 执行者。

首先，传感器产生一条 ” 空气质量超标 ” 事件，并将其传输到用户自定义的 ” 空气质量 ” 事件总线。

用户的全屋零碎接管到这个事件后，别离计算室内外空气质量，得出室外空气超标，而后将窗内外空气质量事件发送到用户自定义的 ” 窗内外空气 ” 事件总线，窗户管制函数作为执行者，向 IoT 服务收回关窗指令，而后传输窗户状态事件。

全屋零碎得悉窗户都已敞开后，持续依据用户定义的全屋逻辑，向新风管制、灯控等对应的事件总线发送相应的事件，以实现全屋管制。

调停者模式的示例就介绍到这儿。接下来，我来介绍管道和过滤器模式。

### 3）管道和过滤器模式

管道和过滤器模式由三个角色组成：源服务、管道函数、指标服务。

源服务产生的事件，经验多个事件总线，被相应的管道函数执行转换、过滤、聚合等操作，最终将新的事件，经事件总线传输给指标服务。

### 4）示例：在线学习

接下来，我来展现一个应用管道和过滤器模式实现人工智能服务在线学习的例子。

咱们都晓得，AI 的衰亡源自大数据。咱们明天所应用的各类人工智能服务，背地都有一个或多个业务算法模型。这些模型通常是由算法架构 + 离线的、批量的大数据重复训练而成的。因为这些服务具备人造的数据相关性，因而实时产生的在线数据会对模型的改良有肯定的帮忙。

这里，咱们假设出行举荐零碎为 源服务 ，出行模型训练服务为 目标服务 ，两头的各个函数为 管道函数。出行举荐零碎将实时的路况事件传输到实时交通事件总线。

实时交通事件总线的事件指标是两个性能不同的函数。

* 第一个函数负责实现数据荡涤和特征提取，而后生成特色事件，传输到特色事件总线。
* 第二个函数负责数据标注，将原始数据打标后，生成标注数据事件，传输到标注数据事件总线。

特色数据事件总线的事件指标同样是两个性能不同的函数。这里不再冗述。

最终出行模型训练服务会依据实时数据，训练出一个新的模型。这里省去了模型回归等工业化流程细节。

# 事件核心

##

到这里，咱们对 EventBridge 作为事件传输、存储和路由的管道能力有了肯定意识。接下来，我将介绍 EventBridge 的另一大特点，事件的中心化查问、展现、剖析能力。

如前所述，EventBridge 基于规范的事件协定 CloudEvents，正逐渐将事件孤岛对立、交融到一起，造成残缺的事件生态体系。

在这个生态体系下，事件核心将用户应用的云产品、第三方 SaaS 服务、用户服务、云下服务所产生的事件对立到一起，为用户提供全方位的事件查问、可视化和剖析能力。

* 事件核心以租户维度，为用户提供一个或者多个事件总线的查问和剖析。
* 针对事件特色显明的服务或者云产品，事件核心提供了大盘和图表，不便用户实时观测。
* 同时，事件核心提供了事件告警和事件卡片，实现用户以 0 代码的形式解决特定的事件。

事件核心让事件的价值最大化，从事件角度为用户的云原生服务提供可追踪、可度量、可观测性。

# 瞻望

##

阿里云事件总线 EventBridge 作为云上的事件枢纽，最外围的能力是连贯。无论是在线业务场景、IoT 场景、还是大数据场景，无论是阿里云、其余云厂商，还是公有 IDC 机房，咱们都将提供安全可靠的集成形式。

将来，EventBridge 会重点倒退生态网络。云时代下这么宏大的神经中枢零碎，不是一日能够建成的，咱们须要并期待与你一起共建云原生事件驱动架构生态。

﹀

﹀

﹀

搜寻钉钉群号 31704055 退出技术交换群，

可获取云原生具体解决方案材料与专家答疑。

> 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。