作者：周新宇

审阅&校对：白玙、佳佳

修改&排版：雯燕

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

首要做一个自我介绍，我是 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）添加云原生小助手！获取更多相关资讯！