百度搜索exgraph图执行引擎设计与实践分享

百度搜索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 {
    // 模拟业务执行遇到了不可兜底的错误
    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.2 PHP策略迁移Go

背景：搜索展现架构当前逐步由PHP迁移到Go。在过渡期，PHP代码迁移到Go之后，需要通过抽样验证Go代码逻辑无误，即：命中抽样，执行Go代码，否则执行PHP代码。而且需要迁移的PHP策略很多，如果没有统一的机制来支持，成本很高。

方案：用MIDWARE指令，用CommonDealPhpOrGoStrategy算子作为判断包装，判断命中抽样时，允许执行DemoStrategy1算子，并带标识到PHP，不执行PHP相应逻辑。

否则不执行DemoStrategy1而执行PHP相应逻辑。

关键的是，迁移后的Go算子都不需要做特殊处理，正常迁移代码加上MIDWARE就能支持以上功能。

审核编辑：刘清