关于后端:云原生事件驱动引擎RocketMQEventBridge应用场景与技术解析

0次阅读

共计 9261 个字符,预计需要花费 24 分钟才能阅读完成。

简介:RocketMQ 给人最大的印象始终是一个音讯引擎。那什么是事件驱动引擎?为什么咱们这次要推出事件驱动引擎这个产品?他有哪些利用场景,以及对应的技术计划是什么?本文咱们就一起来看下。作者:罗静 在刚刚过来的 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 代表 Command,Command 什么意思?就是明令,个别蕴含:Create/Update/Delete,Q 代表 Query,是指查问。所以 CQRS 实质是读写拆散:所有的写操作,在图中右边的零碎中实现,而后将零碎因为 Command 产生变动的事件, 同步到左边的查问零碎。

 这里同学可能有疑难,这跟数据库的读写拆散有什么区别?数据库读写拆散也是提供一个写的 DB,一个读的 DB,两边做同步。对吧… 那这里很大的一个区别是:对于数据库的读写拆散,是以数据库为核心,两边的数据库是截然不同的,甚至数据的存储构造也是截然不同的。然而对于 CQRS 的读写拆散场景,是以业务为核心,两边存储的数据结构格局,往往是不一样的,甚至数据库都不是同一种。齐全围绕各自的读写业务逻辑,设计最佳技术选型。对于写场景,为了保障事务,咱们可能应用关系性数据库;对于读的场景,咱们为了进步性能,咱们可能会应用 Redis、HBase 等 Nosql 数据库。当然 CQRS 也不是适宜所有场景,他往往比拟适宜:●心愿同时满足高并发的写、高并发的读;●写模型和读模型差异比拟大时;●读 / 写比十分高时;咱们方才讲了事件的 4 个利用场景,然而,事件不是万能的,就像软件研发也没有银弹,有很多场景也并不适宜 - 应用事件。包含:1. 强依赖 Response 的同步调用场景;2. 要求服务调用放弃事务强一致性的场景。RocketMQ 对于事件的解决方案 须要什么样的能力?首先,依照之前讲到的事件利用场景,咱们整顿下,如果咱们做好事件驱动这块,咱们的零碎,须要具备什么样的能力呢?

 第一,咱们必定得有一个事件规范,对吧…因为,事件不是给本人看的,也不是给他看的,而是给所有人看的。方才,咱们也讲到事件是无冀望的,它没有明确的消费者,所有都是潜在的消费者,所以,咱们得规范化事件的定义,让所有人都能看得懂,高深莫测。第二,咱们得有一个事件核心,事件核心外面有所有零碎,注册上来的各种事件,(这个跟音讯不一样,咱们没有音讯核心,因为音讯个别是定向的,是生产者和消费者约定的,有点像计划经济,音讯生产进去的时候,带着很强的目的性,是给谁谁生产的。而事件有点像市场经济,事件核心呢,)这个有点相似市场经济大卖场,玲琅满目,外面分类摆放了各种各样的事件,所有人即便不买,也都能够进来瞧一瞧,看一看,有哪些事件,可能是我须要的,那就能够买回去。第三,咱们得有一个事件格局,用来形容事件的具体内容。这相当于市场经济的一个交易契约。生产者发送的事件格局是什么,得确定下来,不能总是变;消费者以什么格局接管事件也得确定下来,不然整个市场就乱套了。第四,咱们得给消费者一个,把投递事件到指标端的能力。并且投递前,能够对事件进行过滤和转换,让它能够适配指标端 API 接管参数的格局,咱们把这个过程呢,对立叫做订阅规定。第五,咱们还得有一个存储事件的中央,就是最两头的事件总线。事件规范 对于方才提到的第一点事件规范,咱们选取了 CNCF 旗下的开源我的项目 CloudEvents,目前已被宽泛集成,算是一个事实上的规范。

 它的协定也很简略,次要标准了 4 个必选字段:id,source、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/roc… 感兴趣的小伙伴们能够扫描下方二维码退出钉钉群探讨(群号:44552972)

 点击此处,进入 EventBridge 官网理解更多信息~ 原文链接:https://click.aliyun.com/m/10… 本文为阿里云原创内容,未经容许不得转载。

正文完
 0