正文

请到「今天看啥」查看全文

在实践中，我们发现Drools方案有以下几个优缺点：

优点

• 策略规则和执行逻辑解耦方便维护。

缺点

• 业务分析师无法独立完成规则配置：由于规则主体DSL是编程语言（支持Java, Groovy, Python），因此仍然需要开发工程师维护。

• 规则规模变大以后也会变得不好维护，相对硬编码的优势便不复存在。

• 规则的语法仅适合扁平的规则，对于嵌套条件语义（then里嵌套when...then子句）的规则只能将条件进行笛卡尔积组合以后进行配置，不利于维护。

由于Drools的问题较多，最后这个方案还是放弃了。

绩效指标计算

场景

美团外卖业务发展非常迅速，绩效指标规则需要快速迭代才能紧跟业务发展步伐。绩效考核频率是一个月一次，因此绩效规则的迭代频率也是每月一次。因为绩效规则系统是硬编码实现，因此开发团队需要投入大量的人力满足规则更新需求。

2016年10月底我受绩效团队委托成立一个项目组，开发部署了一套绩效指标配置系统，系统上线直接减少了产品经理和技术团队70%的工作量。

下面我们首先分析下绩效指标计算的规则模型，如下图。

规则主体是结构化数据处理逻辑：

• 规则逻辑是从若干数据源获取数据，然后进行一系列聚合处理（可以采用结构化查询SQL语句+少量代码实现），最后输出到目标数据源。

方案——业务定制规则引擎

绩效规则主体是数据处理，但我们认为数据处理同样属于规则的范畴，因此我们将其放在本文进行分析。

下图是绩效指标配置系统。触发器负责定时驱动引擎进行计算；视图负责给商业分析师提供规则配置界面，规则表达能力取决于视图；引擎负责将配置的规则解析成Spark原语进行计算。

优点

• 规则配置门槛低：视图和引擎内部数据模型完全贴合绩效业务模型，因此业务分析师很容易上手。

• 系统支持规则热部署。

缺点

• 适用范围有限：因为视图和引擎的设计完全基于绩效业务模型，因此很难低成本修改后推广到别的业务。

探索全新设计

“案例”一节中三种落地方案的问题总结如下：

• 硬编码迭代成本高。

• Drools维护门槛高。视图对非技术人员不友好，即使对于技术人员来说维护成本也不比硬编码低。

• 绩效定制引擎表达能力有限且扩展性差，无法推广到别的业务。

由于“高效配置规则”是业务里长期存在的刚需，且行业内又缺乏符合需求的解决方案，2017年02月我在团队内部设立了一个虚拟小组专门负责规则引擎的设计研发。引擎设计指标是要覆盖工作中基础的规则迭代需求（包括但不限于“案例”一节中的多个场景），同时针对“案例”一节中已有解决方案扬长避短。下面分3节来重现这个项目的设计过程。首先“需求模型”一节会基于“案例”一节的场景尝试抽象出规则模型，同时提炼出系统设计大纲。然后“Maze框架”一节会基于需求模型设计一个规则引擎。最后“Maze框架能力模型”一节会介绍Maze框架的特点。

需求模型

对规则引擎来说，世界皆规则。通过“案例”一节的分析，我们对规则以及规则引擎该如何构建的思路正逐渐变得清晰，下面两节分别定义规则数据模型和规则引擎的系统模型，目标是对“Maze框架”一节中的规则引擎产品进行框架性指导。

规则数据模型

规则本质是一个函数，由n个输入、1个输出和函数计算逻辑3部分组成。

y = f（x1, x2, …, xn）

具体结合“案例”一节中的场景我们梳理出的规则模型如下图所示。

主要由三部分构成：

• FACT对象：用户输入的事实对象，作为决策因子使用。

• 规则：LHS（Left Hand Side）部分即条件分支逻辑。RHS（Right Hand Side）部分即执行逻辑。LHS和RHS部分是由一个或多个模式构成的。模式是规则内最小单位。模式的输入参数可以是另一个模式或FACT对象（比如逻辑与运算[参数1] && [参数2]中参数1可以是另一个表达式）。模式需要支持以下3种类别：

• 客户定义方法：FACT对象的实例方法、静态方法。

• 常规表达式：逻辑运算、算数运算、关系运算、对象属性处理等。

• 结构化查询。

• 结果对象：规则处理完毕后的结果。需要支持自定义类型或者简单类型（Integer、Long、Float、Double、Short、String、Boolean等）。

系统模型

我们需要设计一个系统能配置、加载、解释执行上节中的数据模型，另外设计时还需要规避“案例”一节3个方案的缺点。最终我们定义了如下图所示的系统模型。

请到「今天看啥」查看全文