作者：周新宇
审核 & 校对：白玙、佳佳
编辑 & 排版：雯燕

本文内容整顿自 中国开源年会 演讲

首先做一个自我介绍，我是 RocketMQ 的 PMC member 周新宇，目前负责阿里云 RocketMQ 以及 EventBridge 的产品研发。明天我的分享次要包含以下几局部：

• 音讯与事件、微服务与事件驱动架构
• 阿里云 EventBridge：事件驱动架构实际
• 基于 RocketMQ 内核构建阿里云对立的事件枢纽
•  云原生时代的新趋势：Serverless+ 事件驱动
• 事件驱动架构的将来瞻望

音讯与事件、微服务与事件驱动架构

首先，咱们先讲一下音讯跟事件的区别：大家都晓得 RocketMQ 外面的音讯，它是十分泛化的概念，是一个比事件更加形象的概念。因为音讯的内容体就是 Byte 数组，没有任何一个定义，是个弱 Data，所以它是十分通用的形象。

与之相同的，事件可能是更加具象化的。个别状况下，它有一个 Schema 来精准形容事件有哪些字段，比方 CloudEvents 就对事件有一个明确的 Schema 定义。事件也往往代表了某个事件的产生、某个状态的变动，所以十分具象化。

从用处来讲，音讯往往用于微服务的异步解耦的架构。但这一块的话，事件驱动跟音讯是略微相似的。音讯的利用场景往往产生在一个组织外部，音讯的生产方晓得这个音讯要将被如何解决。比如说在一个团队里，音讯的生产者跟发送者可能是同一个团队同一块业务，对这个音讯内容有一个十分强的约定。相比之下，事件更加松耦合，比如说事件发送方也不晓得这个事件将被投递到什么中央，将被谁生产，谁对他感兴趣，对事件被如何解决是没有任何预期的。所以说，基于事件的架构是更加解耦的。音讯的利用往往还是脱离不了同一个业务部门，即便一些大公司里最多波及到跨部门单干。音讯的应用通过文档进行束缚，事件通过 Schema 进行束缚，所以咱们认为事件是比音讯更加彻底解耦的形式。

接下来，微服务架构跟 EDA 架构有什么区别？

首先是微服务架构，微服务作为从单体利用演进而来的架构，比如说把一个单体利用拆成了很多微服务，微服务之间通过 RPC 进行组织和串联。过来一个业务可能是在本地编排了一堆 function，当初通过一堆 RPC 将之串起来。比如说用户去做一个前端的下单操作，可能后盾就是好几个微服务进行订单操作，一个微服务去新建订单，一个微服务去对订单进行解决，解决完再调另一个微服务去把订单已实现的音讯告诉进来，这是一个典型的 RPC 架构。

但纯正的 RPC 架构有很多问题，比方所有业务逻辑是耦合在一起的，只是把本地办法调用换成了近程调用。当业务增速达到肯定阶段，会发现各个微服务之间的容量可能是不对等的，比如说短信告诉能够通过异步化实现，却同步实现。这就导致前端有多大流量，短信告诉也须要筹备同样规模的流量。当筹备资源不短缺，上下游流量不对等时，就有可能导致某个微服被打挂，从而影响到上游，进而产生雪崩效应。

在这种状况下，大家个别就会引入音讯队列进行异步解耦。这个架构已十分靠近于事件驱动架构了，还是以用户前端创立一个订单举例，订单创立的事件就会就发到事件总线、event broker、event bus 上，上游各个不同订阅方去对这个事件做监听解决。

不同之处在于音讯订阅者基于消息中间件厂商提供 SDK 的去做音讯解决，业务往往须要进行革新，也会被厂商提供的技术栈绑定；事件驱动架构中订阅者属于泛化订阅，即不要求订阅方基于什么样的技术栈去开发，能够是一个 HTTP 网关，也能够是一个 function，甚至能够是历史遗留的存量零碎。只有 event broker 兼容业务的协定，就能够把事件推送到不同订阅方。能够看到，泛化订阅的用处更加宽泛，更加解耦，革新老本也最低。

阿里云 EventBridge：事件驱动架构实际

Gartner 曾预测，EDA 架构未来会成为微服务支流。在 2022 年它将会成为 60% 的新型数字化商业解决方案，也会有 50% 的商业组织参加其中。

同时，CNCF 基金会也提出了 CloudEvents 标准，旨在利用对立的标准格局来申明事件通信。EventBridge 也是遵循这一规范。CloudEvents 作为社区规范，解除了大家对于厂商锁定的担心，进步了各个系统之间的互操作性，相当于说对各个系统约定了对立的语言，这个是十分要害的一步。

事件在开源社区有了对立的标准，但在云上，很多用户购买了云厂商很多云产品，这些云产品每天可能有数以亿计的事件在不停产生，这些事件躺在不同云服务的日志、外部实现里。用户也看不着，也不晓得云产品实例在云上产生什么事件。各个厂商对事件的定义也不一样，整体是没有同一类规范。各个云服务之间的事件是孤立的，就是说没有买通，这不利于开掘事件的价值。在应用开源产品时也有相似问题，用户往往也没有统一标准进行数据互通，想去把这些生态买通时须要付出二次开发老本。

最初，事件驱动在很多场景利用的现状是偏离线的，当初比拟少的人把 EDA 架构用于在线场景。一方面是因为没有事件型中间件基础设施，很难做到一个事件被实时获取，被实时推送的同时，能被业务方把整个链路给追踪起来。所以，以上也是阿里云为什么要做这款产品的背景。

因而，咱们对 EventBridge 做了定义，它有几个外围价值：

一、对立事件枢纽：对立事件界面，定义事件规范，突破云产品事件孤岛。

二、事件驱动引擎：海量事件源，毫秒级触发能力，减速 EDA/Serverless 架构降级。

三、凋谢与集成：提供丰盛的跨产品、跨平台连贯能力，促成云产品、应用程序、SaaS 服务互相集成。

首先讲一下，EventBridge 根本模型，EventBridge 有四大局部。第一局部是事件源，这其中包含云服务的事件、自定义利用、SaaS 利用、自建数据平台。

第二个局部就是事件总线，这是存储实体，事件过去，它要存在某个中央进行异步解耦。相似于说 RocketMQ 外面 topic 的概念，具备肯定存储的同时，提供了异步能力。事件总线涵盖两种，一种默认事件总线，用于收集所有云产品的事件，另一种自定义事件总线就是用户本人去治理、去定义、去收发事件，用来实际 EDA 架构概念。第三局部就是规定，规定与 RocketMQ 的消费者、订阅比拟相似，但咱们赋予规定包含过滤跟转换在内的更多计算能力。第四局部就是事件指标即订阅方，对某事件感兴趣就创立规定关联这个事件，这其中包含函数计算、音讯服务、HTTP 网关等等。

这里具体讲一下这个事件规定，尽管相似于订阅，但事件规定领有事件轻量级解决能力。比方在应用音讯时可能须要把这个音讯拿到本地，再决定是否生产掉。但基于规定，能够在服务端就把这个音讯解决掉。

事件规定反对非常复杂的事件模式过滤，包含对指定值的匹配，比方前缀匹配、后缀匹配、数值匹配、数组匹配，甚至把这些规定组合起来造成简单的逻辑匹配能力。

另一个，就是转换器能力，事件指标泛化定义，其承受的事件格局可能有很多种，但上游服务不肯定。比如说你要把事件推到钉钉，钉钉 API 曾经写好了并只承受固定格局。那么，把事件推过去，就须要对事件进行转换。咱们提供了包含：

• 残缺事件：不做转换，间接投递原生 CloudEvents。
• 局部事件：通过 JsonPath 语法从 CloudEvents 中提取局部内容投递至事件指标。
• 常量：事件只起到触发器的作用，投递内容为常量。
• 模板转换器：通过定义模板，灵便地渲染自定义的内容投递至事件模板。
• 函数：通过指定处理函数，对事件进行自定义函数解决，将返回值投递至事件指标。

目前，EventBridge 集成了 80 多种云产品，约 800 多种事件类型，第一工夫买通了音讯生态，比如说 RocketMQ 作为一个微服务生态，咱们去实际音讯事件理念，就能够把 RocketMQ 的事件间接投递到 EventBridge，通过事件驱动架构去对这些音讯进行解决，甚至 MQTT、KafKa 等音讯生态，都进行买通集成。除了阿里云音讯产品的买通，下一步也会把一些开源自建的音讯零碎进行买通。另一个生态就是 ISV 生态，为什么 ISV 须要 EventBridge？以钉钉 6.0 举例，其最近公布了连接器能力。钉钉外面要装置很多软件，这些软件可能是官网提供，也可能是 ISV、第三方开发者提供，这就造成数据的互通性差。因而，咱们提供这个能力让 ISV 的数据流通起来。最初就是事件驱动生态，咱们以后可能触达到大略 10 多种事件指标，目前也在继续丰盛当中。

事件因绝对音讯更加解耦、离散，所以事件治理也更加艰难。所以，咱们制作了事件核心并提供三块能力：

• 事件追踪：对每一个事件能有残缺的追踪，它从在哪里产生，什么时候被投递，什么时候被过滤掉了，什么时候被投递到某个指标，什么时候被解决胜利了。使整个生命周期齐全追踪起来。
• 事件洞察 & 剖析：让用户从 EDA 编程视角变成用户视角，让用户更加迅速的理解 EventBridge 外面到底有哪些事件，并进行可视化剖析。通过 EB 做到就近计算剖析，间接把业务音讯导入到事件总线中，对音讯进行及时剖析。
• 事件大盘：针对云产品，疏导云产品对业务事件进行定义，让云产品更加凋谢，从而提供大盘能力。

基于 RocketMQ 内核构建阿里云对立的事件枢纽

EventBridge 一开始就构建在云原生的容器服务之上。在这之上首先是 RocketMQ 内核，内核在这个产品里表演的角色有两种，一种就是事件存储，当成存储来用；另一方面是利用订阅能力，把订阅转化成泛化订阅。在 RocketMQ 内核之上就是 connect 集群。EventBridge 比拟重要的能力是连贯，所以 EventBridge 首先要具备 Source 的能力，把事件 Source 过去，而后再存下来；其外围是 Connect 集群，每个 Connect 集群有很多 Worker。每个 Worker 要负责很多事件，包含事件的摄入，事件过滤，事件转换，事件回放，事件追踪等，同时在 Connect 集群之上有 Connect 管制面，来实现集群的治理，Worker 的调度等。

在更下面一层是 API Server，一个事件的入口网关，EventBridge 的世界里，摄入事件有两种形式，一种是通过 Connect 的 Source Connector，把事件被动的 Source 过去，另一种用户或者云产品能够通过 API server，通过咱们的 SDK 把事件给投递过去。投递的形式有很多种，包含有 OpenAPI，有多语言的官网 SDK，同时思考 CloudEvents 有社区的规范，EventBridge 也齐全兼容社区开源的 SDK，用户也能够通过 Webhook 将事件投递过去。

这个架构长处非常明显：

（1）缩小用户开发成本

• 用户无需额定开发进行事件处理
• 编写规定对事件过滤、转换

（2）原生 CloudEvents 反对

• 拥抱 CNCF 社区，无缝对接社区 SDK
• 标准协议对立阿里云事件标准

（3）事件 Schema 反对

• 反对事件 Schema 主动探测和校验
• Source 和 Target 的 Schema 绑定

（4）寰球事件任意互通

• 组建了跨地区、跨账户的事件网络
• 反对跨云、跨数据中心事件路由

云原生时代的新趋势：Serverless+ 事件驱动

咱们认为 Serverless 加事件驱动是新的研发形式，各个厂商对 Serverless 了解各有偏重，然而落地形式小道趋同。

首先，Serverless 基础设施把底层 IaaS 屏蔽掉，下层 Serverless 运行时即计算托管，托管的不仅仅是微服务利用、K8s 容器，不仅仅是函数。

EventBridge 首先把这种驱动的事件源连接起来，可能触发这些运行时。因为 Serverless 最须要的就是驱动方，事件驱动带给他这样的能力，即计算入口。EventBridge 驱动 Serverless 运行时，再去连贯与后端服务。目前，EventBridge 与 Serverless 联合的场景次要是松耦合场景，比方前端利用、SaaS 服务商小程序，以及音视频编解码等落地场景。

那么，Serverless 的 EDA 架构开发模式到底是怎么的呢？以函数计算为例，首先开发者从利用视角须要转换为函数视角，将各个业务逻辑在一个个函数中进行实现；一个函数代表了一个代码片段，代表了一个具体的业务，当这段代码上传后就变成了一个函数资源，而后 EventBridge 能够通过事件来驱动函数，将函数通过事件编排起来组成一个具体的利用。

这外面 function 还须要做很多事件，大家也晓得 function 有很多弊病，它最受诟病的就是冷启动。因为 Serverless 须要 scale to zero 按量付费，在没有申请没有事件去触发时，应该是间接收到 0 的，从 0~1 就是一个冷启动。这个冷启动有些时候可能要秒级期待，因为它可能波及到下载代码、下载镜像，波及到 namespace 的构建，存储挂载，root 挂载，这外面很多事件，各个云厂商投入很大精力优化这一块。Serverless 价格优势很显著，它资源利用率特地高，因按量付费的，所以能做到靠近百分百的资源利用率，也不须要去做容量布局。

举一个简略的例子，就是基于 Serverless 加 EDA 的极简编程范式，再举一个具体的例子，新批发场景下 EDA 架构对这个业务进行革新。首先来讲，业务中有几个要害资源，可能有 API 网关、函数计算，首先能够去买通一些数据，买通 rds 并把 rds 数据同步过去，兼容一些历史架构，同时去触发计算资源、function、网关。整个架构劣势非常明显，所以具备极致弹性能力，不须要去预留资源。

事件驱动的将来瞻望

咱们认为事件驱动的将来有两局部，一是要做好连贯，做好云内、跨云的集成，让用户的多元架构更加高效。二是开源生态的集成，咱们能够看到开源生态愈发蓬勃，所以也须要把这些开源生态中的数据集成好。此外，还有传统 IDC 计算能力、边缘计算能力这些生态都须要有连接性软件把它连接起来。

EventBridge 是云原生时代新的计算驱动力，这些数据能够去驱动云的计算能力，发明更多业务价值。

理解更多相干信息，请扫描下方二维码或搜寻微信号（AlibabaCloud888）增加云原生小助手！获取更多相干资讯！