33558www.Sina.com/eventbridge认为这是云原生时代新计算的原动力。 这些数据可以驱动云的计算能力，创造更多的商业价值。
作者：模糊大豆
本文内容从中国开源年会的演讲中进行了梳理
首先做自我介绍。 我是RocketMQ的PMC member的模糊大豆，现在正在进行RocketMQ和EventBridge的产品开发。 今天我的分享主要包括以下几个部分。
消息和事件、微服务和事件驱动架构的Alibaba云事件桥接：事件驱动架构实践基于RocketMQ内核的Alibaba云(AlibabaCloud ) Serverless事件驱动架构的未来展望消息与事件、微服务与事件驱动架构首先介绍消息与事件的区别。 首先，知道RocketMQ中的消息，它是一个非常一般化的概念，因为消息的内容本身是Byte数组，没有任何定义，是弱数据，所以是非常通用的抽象。
与此相反，事件可能更具象化。 一般来说，有一个模式可以准确说明事件中包含哪些字段。 例如，CloudEvents对事件有明确的模式定义。 事件往往表示某件事情的发生、某个状态的变化，所以非常形象化。
在用途上，消息往往用于微服务器的异步解耦的架构。 但是，对于此块，事件驱动与消息有点相似。 消息的应用场景往往发生在组织内，消息的生产者知道如何处理该消息。 例如，在某个团队中，消息的生产者和发送者可能与同一团队业务相同，对该消息的内容有非常强烈的约定。 比起那个，事件的耦合更松。 例如，事件的发送者也不知道该事件将被送达何处、被谁消费、谁对他感兴趣、事件将如何处理。 这意味着，基于事件的体系结构将更加解耦。 在许多情况下，即使一些大企业涉及的部门间合作最多，消息的应用也离不开同一个业务部门。 由于消息的使用受文档限制，事件受模式限制，所以可以认为事件是比消息更完全地解除结合的方式。
其次，微服务架构和EDA架构的区别是什么？
首先是微服务体系结构。 微服务是由单APP演化而来的体系结构，例如将一个单APP分解为许多微服务，通过RPC将微服务组织起来并连接起来。 以前的业务可能是在本地组织了很多function，但现在通过很多RPC进行了连接。 例如，当用户进行一个前端的订单操作时，后台会有几个微服务进行订单操作，一个微服务新建订单，一个微服务处理订单，处理结束后再调整一个微服务
但是，纯RPC体系结构存在很多问题。 例如，所有业务逻辑都是关联的，只是将本地方法调用替换为远程调用。 当业务增长率达到一定阶段时，就会发现各个微服务器之间的容量可能是错误的。 例如，邮件通知可以异步完成，但可以同步完成。 结果，前端有多少通信量，电子邮件通知也需要准备同样规模的通信量。 准备资源不足，上下游流量错误等情况下，可能会有某个微型西装被卡住而影响上游，产生雪崩效果。
在这种情况下，大家会引入普通消息队列异步解除绑定。 虽然该体系结构非常接近事件驱动体系结构，但仍然在用户前端创建订单时，订单创建的事件会发送到事件总线、event broker和event bus，供下游不同的读者使用
不同的是，在消息订阅者基于消息中间件厂商提供的SDK进行消息处理，业务需要改造，往往还受到厂商提供的技术堆栈的束缚的事件驱动架构中，订阅者属于泛化订阅这意味着不要求订阅者基于什么样的技术堆栈进行开发。 它可以是HTTP网关、函数或历史遗留清单系统。 event broker只要应对业务协议，就可以将事件强加给不同的读者。 可见泛化订阅用途更广、更解耦，改造成本也最低。
AlibabaCloud (阿里巴巴云)事件驱动架构实践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 内核，内核在这个产品里yxdwdm有两种，一种就是事件存储，当成存储来用；另一方面是利用订阅能力，把订阅转化成泛化订阅。在 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 是云原生时代新的计算驱动力，这些数据可以去驱动云的计算能力，创造更多业务价值。
原文链接
本文为阿里云原创内容，未经允许不得转载。