网站公司建设网站价格,怎么申请域名邮箱,网红营销案例,比特币网站怎么做在刚刚过去的 RocketMQ Summit 2022 全球开发者峰会上#xff0c;我们对外正式开源了我们的新产品 RocketMQ-Eventbridge 事件驱动引擎。
RocketMQ 给人最大的印象一直是一个消息引擎。那什么是事件驱动引擎#xff1f;为什么我们这次要推出事件驱动引擎这个产品#xff1f…在刚刚过去的 RocketMQ Summit 2022 全球开发者峰会上我们对外正式开源了我们的新产品 RocketMQ-Eventbridge 事件驱动引擎。
RocketMQ 给人最大的印象一直是一个消息引擎。那什么是事件驱动引擎为什么我们这次要推出事件驱动引擎这个产品他有哪些应用场景以及对应的技术方案是什么
今天我们就一起来看下整篇文章包含三部分
第一部分我们一起看下什么是事件。
第二部分和大家一起看看事件有哪些不一样的“超能力”使用这些“超能力”呢我们又能干些什么
第三部分我们讲一下 RocketMQ 给出的关于事件的解决方案也是我们这次开源的项目RocketMQ-EventBridge。
什么是事件
大家自己可以先在脑袋里想一下什么是事件我们给事件下的一个定义是
过去已经发生的事尤其是比较重要的事。
A thing that happens, especially one of importance.这个很好理解。比如说昨天下午我做了一次核酸检测今天上午又吃了一个冰激淋。这些都是过去已经发生的事件。但是如果我再问事件跟消息有什么区别这个时候大家是不是觉得事件这个定义好像又不那么清晰
刚才说的那些事件是不是也可以理解为消息啊如果老张给我发送了一条短信这个算是事件还是消息啊平常开发过程中“什么时候使用消息什么时候使用事件”
不过在回答这个问题之前我们一起来看一个典型的微服务。 一个微服务系统和外部系统的交互可以简单分为两部分一是接收外部请求就是图中上面黄色的部分二是是调用外部服务就是图中下面绿色的部分。
接收外部请求我们有两种方式一种是提供 API接收外部发过来的 Query 请求和 Commond 请求另外一种是主动订阅外部 Command 消息。这两类操作进入系统内部之后呢我们常常还会调用其他为微服务系统一起协同处理来完成一个具体的操作。当这些操作使得系统状态发生改变时就会产生事件。
这里呢我们把从外部接收到的 Command 消息和系统内部产生的事件都称之为消息。
我们总结一下消息和事件的关系是这样的消息包含两部分Command 消息和 Event 消息
1、看图中左半部分Command 是外部系统发送给本系统的一条操作命令
2、再看图中右半部分Event 则是本系统收到 Command 操作请求系统内部发生改变之后随之而产生了事件 所以事件和消息是不同的事件可以理解为是一种特殊的消息。其特殊的点主要在 4 个地方
已发生、且不可变
事件一定是“已发的”。“已发生”的代表什么呢不可变的。我们不可能改变过去。这个特性非常重要在我们处理事件、分析事件的时候这就意味着我们绝对可以相信这些事件只要是收到的事件一定是系统真实发生过的行为。而且是不可修改。
对比 Command 和 Query。Command 的中文是什么命令。很显然它是还没有发生的只是表达了一种期望。我们知道“期望的”不一定会成功发生
比如把厨房的灯打开、去按下门铃、转给 A 账户 10w……
这些都是 Commond都是期望发生的行为。但是最终有没有发生并不知道
Event 则是明确已经发生的事情。比如厨房灯被打开了、有人按了门铃、A 账户收到了 10w……
再对比 Query它则是查询系统当前状态的一种请求比如厨房的灯是打开着的、门铃正在响、查下账户显示余额 11w……
无期望的
这个怎么理解事件是客观的描述一个事物的状态或属性值的变化但对于如何处理事件本身并没有做任何期望。
相比之下Commond 和 Query 则都是有期望的他们希望系统做出改变或则返回结果但是 Event 呢它只是客观描述系统的一个变化。
我们看一个例子交通信号灯从绿灯变成红灯事件本身并没有要求行人或汽车禁止通行而是交通法规需要红绿灯并赋予了其规则。 所以系统一般不会定向的、单独向另外一个系统发送事件而是统一的告诉“事件中心”“事件中心”呢那里面有各个系统上报上来的各式各样的事件。系统会向事件中心说明自己这个系统会产生哪些事件呀这些事件的格式是怎么样的呀。
别的系统如果感兴趣呢就可以来主动订阅这些事件。真正赋予事件价值的是事件消费者。事件消费者想看看,某个系统发生了什么变化呀OK那他就去订阅这些事件所以事件是消费者驱动的。
这跟消息有什么区别呢Commond 消息的发送和订阅是双方约定好的外人不知道往往是以文档或代码的形式大家按约定好的协议发送和订阅消费所以消息是生产者驱动的。
我们打个比喻事件就像市场经济商品被生产出来具体有什么价值有多大价值很大程度上看其消费者。我们能看到系统中各种各样的事件就像橱窗里摆放了各种各样的商品。而 Commond 消息呢有点像计划经济一出生就带着很强的目的性我就是要“分配”给谁消费。
天然有序
事件的第三个特性是“天然有序”。含义同一个实体不能同时发生 A 又发生 B必有先后关系如果是则这两个事件必属于不同的事件类型。
比如针对同一个交通信号灯不能既变成绿灯又变成红灯同一时刻只能变成一种状态。 大家可能发现了一点这里其实隐藏了事件的一个额外属性因为天然有序跟时间轴上的某一时刻强绑定且不能同时发生所以它一定是唯一的。
如果我们看到了两个内容一样的事件那么一定是发生了两次而且一次在前一次在后。这对于我们处理数据最终一致性、以及系统行为分析都很有价值我们看到的不光光是系统的一个最终结果而是看到变成这个结果之前的一系列中间过程
具像化
事件的第四个特性是“具象化”的。
事件会尽可能的把“案发现场”完整的记录下来因为它也不知道消费者会如何使用它所以它会做到尽量的详尽比如
●是由谁产生的事件Subject
●是什么类型的事件Type
●是谁发送的事件Source
●事件的唯一性标志是什么Id
●什么时候发生Time
●事件的内容是什么Data
●事件的内容有哪些信息Dataschema
我们还是以交通信号灯举例子 对比我们常见的消息因为上下游一般是确定的常常为了性能和传输效率则会做到尽可能的精简只要满足“计划经济”指定安排的消费者需求即可。
总结一下事件上面的 4 个特性是对事件巨大的一个属性加成让事件拥有了跟普通消息不一样的“超能力”。使事件常常被用到 4 个典型场景事件通知、事件溯源、系统间集成和 CQRS。 下面让我们一个个展开具体看看这些应用场景。
事件的典型应用场景
事件通知
事件通知是我们系统中很常见的一个场景。比如用户下单事件通知给支付系统用户付款事件通知给交易系统。
这里让我们回到一开始信号灯那个例子。当交通信号灯从红灯变成绿灯时可能存在很多系统都需要这个信息。
方式 1:发送方主动调用适配接收方
一种最简单的方式是我们依次 call 每个系统并把信息传递出去。比如信号灯系统主动调用地图导航的 API 服务、调用交警中控的 API 服务调用城市大脑的 API 服务把红绿灯变化信号发送出去。 但我们都知道这个设计非常糟糕。尤其当系统越来越多时这无疑是灾难的不仅开发成本高而且其中一个系统出现问题可能会 hang 住整个服务则导致调用其他系统都会受到影响。
方式 2接收方主动订阅适配发送方
一个很自然的解决方案是我们将这些信息发送到中间消息服务 Broker其他系统如果有需要则主动去订阅这些消息即可。 这个时候信号灯系统与其他系统并没有直接的调用依赖交警中控服务、地图导航服务、城市大脑服务只要按照约定的协议去订阅信号灯的消息并解析这些信息即可。
但是这里同样存在一个问题这个架构中是以“信号灯”为中心。消费者需要理解发送者的业务领域并主动添加适配层就是图中白色回旋镖部分将消息转化为自己业务领域内的语言。但对于每一个微服务来说他都希望都是高内聚低耦合的。
如果交警中控需要全国的信号灯数据但是每个地域的消息格式又不一样这就意味着交警中控需要适配每一个地域的协议做一层转换。而且万一后面变化了怎么办想想就知道这个运维成本有多可怕。 那是否交警中控系统可以要求全国所有红绿灯系统都按同一种数据协议给到自己呢不好意思这些信号灯数据地图服务也在用城市大脑也在用不能更改。
方式 3引入事件Borker 根据接收方协议进行灵活适配
但如果使用事件就不一样了。因为事件是“无期望的”“具像化的”天然的保留了案发现场尽可能多的信息且更加规范标准对于消费者也就是交警中空来说可以轻易将不同省份收集上来的事件轻易组装成符合自己业务要求的格式。 而且这一组装是在中间层 Broker 发生的。对于交警中控来说它只需要按照自己业务领域的设计提供一个接收事件的 API然后其他事件通过 Broker主动投递到这个 API 上即可。从头到尾对交警中控系统没有一行适配外部业务的代码。
所以这种方式有 3 个明显的优势
1、只关注自己业务领域本身不需要做适配外部的代码
2、所有对系统的变更收敛到 API为唯一入口同一个 API可能既是用来接收事件的也可能同时用于控制台操作
3、因为事件是推送过来的所以也不需要像之前一样引入一个 SDK和 Broker 发生连接获取消息降低了系统的复杂度。
这样我们一开始的图就会变成这个样子交通信号灯产生事件投递到事件中心其他需要这些事件的消费者在事件中心订阅再由事件中心按照他们期望的事件格式主动投递过去。 让我们再来回顾下整个过程 第 1 幅图一开始我们通过强依赖的方式让信号灯系统主动将信息发送给各个系统。那这张图里我们是以各个下游服务为中心信号灯系统去适配各个下游服务。
第 2 幅图后来我们采用传统消息的方式对调用链路进行了解耦两边系统不再直接依赖了但是依旧会存在业务上的依赖。消费者需要去理解生产者的消息格式并在自己系统内部进行转换适配。所以这里其实是以生产者为中心。
第 3 幅图最后我们引入了事件通知的方式对于这种方式生产者和消费者他们都只需要关注自己系统本身就可以了。生产者生产什么样的事件消费者消费什么样的数据格式都各自以自己的业务为中心不需要为对方做适配。真正做到我们说的高内聚低耦合实现彻底的完全解耦。
现在回到我们一开始提到的典型微服务模型对于有些场景我们就可以变为下面这种方式对微服务的变更操作统一收敛到 API 操作入口去掉 Commond 消息入口。收敛入口对于我们维护微服务保障系统稳定性常常非常有好处的。 事件溯源
事件溯源是什么事件溯源简单理解就是让系统回到过去任意时刻。那怎么样才能让系统可以回到过去呢很简单首先系统所有发生的变化都得以事件的方式记录下来然后我们就可以通过回放事件的方式回到过去任何一个时刻。
那为什么只有事件才能做这个事其他普通消息不行呢这个还是要回到我们刚才说的几个事件特性已发生不可变的、天然有序且唯一的、而且是非常详细具体的完整的记录了事件的案发现场。所以对于事件溯源这个场景事件可以说是系统的一等一的公民。
举个例子比如说如果我们能够完整地收集路上的各种事件信息包括信号灯、车量、天气、拥堵路况等等那么我们就可以“穿越时间”回到交通现场重新做一次决策。比如在智慧交通场景当我们想去验证一个调度算法的时候我们就可以回放当时发生的所有事件来重现现场。 大家可能觉得这个很神奇但是其实我们平常一直有接触大家知道是什么吗就是我们常用的代码版本-管理系统比如github。
这里有大家可能会问如果一个系统积赞了很多事件想重放是不是得很久比如在一些交易场景每天都会产生大量的事件那应该怎么处理呢这里呢系统一般每天晚上都会打一份快照。如果系统意外宕机想回到某一个时刻就可以把前一天的快照取出然后再重新跑下当天的事件即可恢复。而白天呢所有的事件都是在内存中进行处理不会跟数据库交互所以系统性能非常快只有事件会落盘。
当然事件溯源也不是适合所有场景它有优点也有缺点详细看上图。
系统间集成
刚才讲的第1个场景事件通知一般涉及到两个上下游团队的协作开发讲的第 2 个场景事件溯源则一般是 1 个团队内的开发但系统间集成则往往面对的是三个业务团队的协作开发。这个怎么理解呢
其实这个也很常见比如公司里购买了 ERP 系统同时也购买了外部考勤系统、外部营销系统服务等等。这些系统都有一个共同点是什么都不是我们自己开发的是而买来的。 如果我们想把 ERP 系统的人员信息实时且自动同步到考勤系统中去怎么办其实这个是有点麻烦的因为这些都不是我们自己开发的。
1、我们不能修改 ERP 系统的代码主动去调用考勤系统把人员变更信息发送过去
2、也不能修改考情系统的代码主动去调用外部 ERP 系统的 API
但是我们可以通过事件总线借助 webhook 或则标准 API 等等方式收集上游的 ERP 系统产生的人员变更事件然后进行过滤和转换推送到下游考勤系统中去当然这里也可以是内部自研服务。
所以现在的研发模式变成了事件中心管理了所有 SaaS 服务包括内部自研系统产生的所有事件。然后呢我们只需要在事件中心寻找我们需要的事件进行订阅对 SaaS 服务和内部自研系统进行简单服务编排即可完成开发。
CQRS
CQRS 中的 C 代表 CommandCommand 什么意思就是明令一般包含Create/Update/DeleteQ 代表 Query是指查询。所以 CQRS 本质是读写分离所有的写操作在图中左边的系统中完成然后将系统因为 Command 产生变化的事件,同步到右边的查询系统。 这里同学可能有疑问这跟数据库的读写分离有什么区别数据库读写分离也是提供一个写的 DB一个读的 DB两边做同步。对吧…
那这里很大的一个区别是对于数据库的读写分离是以数据库为中心两边的数据库是一模一样的甚至数据的存储结构也是一模一样的。
但是对于 CQRS 的读写分离场景是以业务为中心两边存储的数据结构格式往往是不一样的甚至数据库都不是同一种。完全围绕各自的读写业务逻辑设计最佳技术选型。对于写场景为了保障事务我们可能使用关系性数据库对于读的场景我们为了提高性能我们可能会使用 Redis、HBase 等 Nosql 数据库。
当然 CQRS 也不是适合所有场景他往往比较适合
●希望同时满足高并发的写、高并发的读
●写模型和读模型差别比较大时
●读/写比非常高时
我们刚才讲了事件的 4 个应用场景但是事件不是万能的就像软件研发也没有银弹有很多场景也并不适合-使用事件。包括
1. 强依赖 Response 的同步调用场景
2. 要求服务调用保持事务强一致性的场景。
RocketMQ 关于事件的解决方案
需要什么样的能力 首先按照之前讲到的事件应用场景我们整理下如果我们做好事件驱动这块我们的系统需要具备什么样的能力呢 第一我们肯定得有一个事件标准对吧…因为事件不是给自己看的也不是给他看的而是给所有人看的。刚才我们也讲到事件是无期望的它没有明确的消费者所有都是潜在的消费者所以我们得规范化事件的定义让所有人都能看得懂一目了然。
第二我们得有一个事件中心事件中心里面有所有系统注册上来的各种事件这个跟消息不一样我们没有消息中心因为消息一般是定向的是生产者和消费者约定的有点像计划经济消息生产出来的时候带着很强的目的性是给谁谁消费的。而事件有点像市场经济事件中心呢这个有点类似市场经济大卖场玲琅满目里面分类摆放了各种各样的事件所有人即使不买也都可以进来瞧一瞧看一看有哪些事件可能是我需要的那就可以买回去。
第三我们得有一个事件格式用来描述事件的具体内容。这相当于市场经济的一个买卖契约。生产者发送的事件格式是什么得确定下来不能总是变消费者以什么格式接收事件也得确定下来不然整个市场就乱套了。
第四我们得给消费者一个把投递事件到目标端的能力。并且投递前可以对事件进行过滤和转换让它可以适配目标端 API 接收参数的格式我们把这个过程呢统一叫做订阅规则。
第五我们还得有一个存储事件的地方就是最中间的事件总线。
事件标准
关于刚才提到的第一点事件标准我们选取了 CNCF 旗下的开源项目 CloudEvents目前已被广泛集成算是一个事实上的标准。 它的协议也很简单主要规范了 4 个必选字段idsource、type、specversion以及多个可选字段subject、time、dataschema、datacontenttype和data。上图右边我们有一个简单的例子,大家可以看下这里就不具体展开了。
另外事件的传输也需要定义一种协议方便不同系统之间的沟通默认支持三种 HTTP 的传输方式Binary Content Mode、Structured Content Mode 和 Batched Content Mode。通过 HTTP 的 Content-Type就可以区分这三种不同的模式。其中前两种都是传递单个事件第三种则是传递批量事件。 事件 Schema
事件的 Schema用来描述事件中有哪些属性、对应的含义、约束等等信息。目前我们选取了 Json Schema. 和 OpenAPI 3.0根据事件的 Schema 描述我们可以对事件进行合法性校验。当然 Schema 本身的修改也需要符合兼容性原则这里不作具体展开。
事件过滤和转换
关于事件的过滤和转换我们提供了 7 种事件过滤方式和 4 种事件转换方式详细可以下图描述 技术架构
我们 RocketMQ 围绕事件驱动推出的产品叫做 EventBridge也是我们这次要开源的新产品。
他的整个架构可以分为两部分上面是我们的控制面、下面是我们的数据面。 控制面中最上面的 EventSource 是各个系统注册上来的事件源这些事件可以通过 APIGateway 发送事件到事件总线也可以通过配置的 EventSource生成 SouceRuner主动从我们的系统中去拉取事件。事件到达事件总线 EventBus 之后我们就可以配置订阅规则了 EventRule在规则 EventRule 里我们设置了事件怎么过滤以及投递到目标端前做哪些转换。系统基于创建的规则会生成 TargetRunner就可以将事件推送到指定的目标端。
那这里 SouceRuner 和 TargetRunner 是什么呢我们具体能对接哪些上下游 Source 和 Target
这些我们都可以在下面的 SourceRegister 和 TargetRegister 提前进行注册。
所以 EventBridge 的数据面是一个开放的架构他定义了事件处理的SPI底下可以有多种实现。比如我们把 RocketMQ 的 HTTPConnector 注册到 EventBridge 中那我们就可以把事件推送到 HTTP 服务端。
如果我们把 Kafka 的 JDBC Connector 注册到 EventBridge 中我们就可以把事件推送到数据库。
当然如果你的系统不是通用的像 HTTP/JDPC 等协议也可以开发自己的 Connector这样就能将事件实时同步到 EventBridge或则接收来自 EventBridge 的事件。
除此之外我们还会有一些附加的运维能力包括事件追踪、事件回放、事件分析、事件归档。
RocketMQ-EventBridge 与云上
在所有开源的与其他上下游系统做集成的 Connector 当中我们有一个特殊的 Connector叫EventBridgeConnector通过它可以方便的和阿里云云上的事件总线进行集成。这里有两个典型的应用场景
第一个场景是IDC 系统内部产生的事件不仅可以用来做内部系统间的解耦还可以实时同步到云上驱动云上的一些计算服务比如通过云上 Maxcompute 对内部产生的事件进行离线分析或则驱动云上的图像识别服务实时分析事件中标注的图片。
第二个场景是如果 IDC 内部使用到了自建 MQ我们同样可以通过 MQConnector 和 EventBridgeConnector实时同步事件到云上逐步将内部自建 MQ迁移到云上MQ。 生态发展
关于 EventBridge 的未来方向我们希望是在开源构建一个支持多云架构的事件总线生态。这个怎么理解简单来说我们希望在不同云厂商之间包括云厂商和内部 IDC 系统之间可以通过事件来打破围墙实现互通。虽然这几年云计算发展很快但是对于一些特别大的客户来讲有时候并不希望跟某家云厂商强绑定。这不光是市场充分竞争的结果也是大客户一种降低风险的手段。所以这个时候如何在不同云厂商之间包括云厂商系统和自己内部 IDC 系统之间灵活的交互甚至灵活的迁移是企业非常重要的一个诉求。 当然实现这个是有一定难度的。不过如果我们在进行企业架构设计的时候是基于事件驱动架构进行设计开发——不同系统之间的交互围绕事件展开就会容易很多。
事件在这里就好比一种通用语言通过这个通用语言就可以实现和不同系统之间的沟通交流。比如用 IDC 系统内部的事件去驱动阿里云上服务甚至用阿里云上的事件去驱动 AWS 上的服务运行
为了实现这个目标我们在和不同云厂商不同 SaaS 系统服务商进行系统间集成的时候需要开发与之对应的连接器。
也欢迎大家一起来共建 RocketMQ-EventBridge 的生态。
源码地址https://github.com/apache/rocketmq-eventbridge
作者罗静
原文链接
本文为阿里云原创内容未经允许不得转载。
