关于java:阿里云-EventBridge-事件驱动架构实践

简介：咱们认为 EventBridge 是云原生时代新的计算驱动力，这些数据能够驱动云的计算能力，发明更多业务价值。

作者：周新宇

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

首先做一个自我介绍，我是 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 是云原生时代新的计算驱动力，这些数据能够去驱动云的计算能力，发明更多业务价值。

原文链接
本文为阿里云原创内容，未经容许不得转载。