百度搜索exgraph图执行引擎设计重点分成三个部分:图描述语言、图执行引擎、对接扩展。 图描述语言是一种基于文本可读的图描述语言,用于描述任务中的算子以及算子之间的依赖关系,即让人可以理解,也可以被计算机理解并执行。 图执行引擎是exgraph的核心,负责根据图描述语言生成的图语法树进行高效执行。它支持如串行、并行、中断、选择等范式,以满足不同场景下的需求。 对接扩展则提供了与其他协议框架的接口,方便用户将exgraph集成到现有的系统中。 总之,exgraph图执行引擎设计的目标是实现高效、灵活的任务编排,以满足复杂逻辑处理需求。
01
背景
搜索展现架构承载模版选择、实时摘要补充、展现数据适配、结果渲染等职责,当前由PHP开发、HHVM执行,对接数十个产品线,数百个精细化的展现策略由100+RD共同开发。随着搜索业务产品日益复杂和生成式大模型产品开发需要,展现架构面临以下难题:
1、HHVM基础设施停止维护,且不支持异步并行支持,架构升级难度大;
2、历史累计的多个展现策略框架分布在各个阶段,且各自参数不同,研发难度大。
通过调研,了解到DAG有向无环图,将DAG图中顶点描述为业务拆分后的一个个算子,边及其方向作为执行顺序,一对一作为串行执行,一对多作为并发执行,即使是很复杂的业务也可以用这套逻辑进行表达。且代码实现较简单,还能用graphviz将DAG图生成图片,将整个逻辑可视化。
△算子化后的逻辑执行视图
好像很完美~~
但似乎还有些问题:
1、对于简单逻辑,DAG图不复杂,用graphviz构建图也很简单,但一旦顶点数量爆发,可阅读性急速下降。而不幸的是,搜索的PHP模块几百个策略,如果迁移进来,预计会有几百个顶点,构建这个图以及这个图的可读性,依然很差;
2、简单意味着功能弱。
比如搜索有多种版式:手百内、手百外、纯NA渲染等,下游顶点根据上游顶点的执行结果来选择不同的版式渲染。这种场景下只能呆呆的在每个版式顶点内自行判断是否执行,而不能由上游顶点直接选择一个版式分支执行。
比如执行到某个顶点,发现后续不用执行了,逻辑执行没有好的退场机制。
各个算子间传递数据怎么处理。
...
02
图执行引擎
DAG能满足大多数场景的需要,但依然不够。所以搜索设计了一套超集于DAG的图描述,并在这个描述上,添加逻辑执行的高级功能,与web框架进行融合,逐步诞生了exgraph图执行引擎。
exgraph图执行引擎设计重点分成两个三个部分:图描述语言、图执行引擎、对接扩展(用来对接协议框架)。
2.1 图描述语言
2.1.1 核心语法
算子:业务执行的最小单位,通常一个单词就是一个算子(语法单独定义的关键词除外)。
串行组:即两个算子按照顺序执行,在图上表示为用箭头连接:
△串行组
并发组:即多个算子并发的执行,在图上用中括号[]包围:
△并发组
属性:图上所有用大括号{}包围的,都是属性。属性用于通过图描述传递参数给代码。
△属性
算子、串行组、并发组都是一个执行单元,意味着,他们可以互相包含(算子是最小的执行单元,不能包含别的执行单元)。比如:
△互相包含
上面的这个描述,用人话说就是:
1、执行a算子
2、并发地:
执行b算子,
执行c算子,然后执行d算子,然后执行e算子
执行f算子,然后再并发地执行g算子和h算子
3、最后再执行i算子
子图:主图支持通过文件引入的方式,引入另一个图嵌入到主图
△主图引入sub_graph子图
通过上面简单的介绍,你已经掌握几乎全部图描述语言语法了,可以开始思考,将自己所负责的业务如何用图进行描述了。
另外,为了更好的适配业务场景,exgraph还设计了几种指令来处理特殊场景。
扩展指令
START指令:图开始的标记,用做给图设置属性。
△START指令
目前START指令用来指导创建HTTP的handler,直接让图引擎承接http处理、streaming rpc处理请求。
MIDWARE指令:包装含义。
△MIDWARE指令
可以在执行c算子前,先执行b算子,并控制是否执行c算子;也可以在执行c算子前后,执行一些通用的逻辑。
SWITCH指令:选择执行分支。
△SWITCH指令
可以在switch_pc_or_wise算子内,选择执行哪个分支。
基于图描述语言,用纯文本的方式就可以将业务整体描述,很好的解决了DAG图构图复杂性问题,并允许自定义一些高级用法。
2.2图执行引擎
上面介绍的图描述语言,让“人”可以更加简单的方式了解到程序的执行流程,但也仅仅只是个描述而已。
如何让其按照我们设定的描述将逻辑跑起来呢?
首先介绍一个重要的、执行单元必须实现的接口:
type Job interface{ DoImpl(*engine.Context) error }
其中*Context负责传递所有信息到各个算子,提供:算子选项(算子{}附带的内容)内容获取、数据传递等功能。
在上面的章节中讲到算子、串行组、并发组都是一个执行单元,其实就是说,它们都实现了Job接口。
exgraph图执行引擎是:将图解析后的语法树作为入参,搭配全局算子注册,让算子按照预定的规则执行起来。
它的执行过程近似于:
em~~,简单的有点像把大象放冰箱的过程,但实际远不止如此。
想一下,如果你执行到a算子,发现没有必要执行b算子了,怎么办?又或者a有数据要传递到b算子,怎么办?
2.2.1 对象容器
exgraph中实现了一个并发安全的对象容器,用户可以通过*engine.Context提供的接口,方便的设置和获取对象,就像这样:
type a struct {} func (o *a) DoImpl(ctx *Context) error { // 算子a,设置对象 var a int = 2023 ctx.RegisterInstance(&a) return nil } type b struct {} func (o *b) DoImpl(ctx *Context) error { var a int // 通过类型获取值 ctx.MutableInstance(&a) // 打印2023 fmt.Println(a) return nil }
对象容器再存入时,将其类型作为标识符,取值时也通过相同类型的变量,通过反射赋值。
2.2.2依赖注入和对象导出
有了对象容器,exgraph设计了支持基于struct tag的对象依赖注入和导出功能,且采用脚本生成代码的方式实现:
type Operator struct { http.Request `inject:""` http.Response `inject:"canLost=true,canNil=true"` *Userinfo `extract:"canNil=true"` } type UserInfo struct { Name string } func (o *Operator) DoImpl(engine.Context) error { // 通过inject,算子内可以直接获取到Request对象 if v, ok := o.Request.Header.Get("xx"); ok { // do something } return nil }
利用struct tag和生成的代码,用户在使用算子时,实现了以下功能:
1、inject tag可以直接通过算子属性获取对象,省去了繁琐的取值过程,并支持:canLost=true表示允许对象不存在,canNil=true表示循序对象值为nil。
2、extract tag则允许用户直接赋值为算子属性,由生成的代码赋值将对象导出到对象容器中,且支持:canNil=true表示允许导出对象值为nil,repace=true表示允许替换对象。
2.2.3 中断和跳过
为方便程序逻辑执行,exgraph内置了几种中断跳过逻辑:
1、全局错误中断
type a struct {} func (o *a) DoImpl(ctx *Context) error { // interwetten与威廉的赔率体系 业务执行遇到了不可兜底的错误 err := errors.New("fatal error") // 调用Abort函数即可中断整个图执行引擎 ctx.Abort(err) return nil }
2、全局正常中断
type a struct {} func (o *a) DoImpl(ctx *Context) error { // 发现没必要走后面的逻辑 // 直接中断整个图执行引擎 ctx.Exit() return nil }
3、跳过串行组
type a struct {} func (o *a) DoImpl (ctx *Context) error { // a算子执行跳过`a -> b`这个子集串行组 // 即b算子不再执行,但c算子正常执行 ctx.SkipSerialGroup() return nil }
2.3执行优化
exgraph执行的一个声明周期内,大部分对象都允许池化。
2.3.1对象池
对于算子:exgraph内部对每个注册的算子,都是注册到一个sync.Pool中,算子对象在执行完成后,执行reset后返回到对象池内。
对于放入对象容器的对象:在exgraph执行引擎结束时,会循环对每个对象检测是否实现了Release接口,如果实现接口就会调用,用户就可以在Release时将对象reset后返回对象池内。
2.3.2其他优化
exgraph在执行每个算子时默认在当前goroutine执行,除非用户显示的给算子设置了超时时间a{timeout="1s"}。
依赖注入和对象导出,是基于脚本生成代码的,而非反射。
03
场景案例
3.1 同路径不同逻辑
背景:搜索PC和wise(移动端)同模块执行,检索路径都为/s
方案:可以用SWITCH选择模式,通过一个算子来判断使用哪个分支:
3.2PHP策略迁移Go
背景:搜索展现架构当前逐步由PHP迁移到Go。在过渡期,PHP代码迁移到Go之后,需要通过抽样验证Go代码逻辑无误,即:命中抽样,执行Go代码,否则执行PHP代码。而且需要迁移的PHP策略很多,如果没有统一的机制来支持,成本很高。
方案:用MIDWARE指令,用CommonDealPhpOrGoStrategy算子作为判断包装,判断命中抽样时,允许执行DemoStrategy1算子,并带标识到PHP,不执行PHP相应逻辑。
否则不执行DemoStrategy1而执行PHP相应逻辑。
关键的是,迁移后的Go算子都不需要做特殊处理,正常迁移代码加上MIDWARE就能支持以上功能。
审核编辑:刘清
-
RPC
+关注
关注
0文章
111浏览量
11529 -
PHP
+关注
关注
0文章
452浏览量
26679 -
DAG
+关注
关注
0文章
17浏览量
8146
原文标题:百度搜索exgraph图执行引擎设计与实践
文章出处:【微信号:OSC开源社区,微信公众号:OSC开源社区】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
评论