中小企业建网站多少钱,网站备案查询姓名,月付购物网站建站,淘宝客如何做淘宝客网站推广简介#xff1a;我们认为 EventBridge 是云原生时代新的计算驱动力#xff0c;这些数据可以驱动云的计算能力#xff0c;创造更多业务价值。
作者#xff1a;周新宇
本文内容整理自 中国开源年会 演讲
首先做一个自我介绍#xff0c;我是 RocketMQ 的 PMC member 周新宇…简介我们认为 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 是云原生时代新的计算驱动力这些数据可以去驱动云的计算能力创造更多业务价值。
原文链接 本文为阿里云原创内容未经允许不得转载。
