python构建决策引擎_从0到1：构建强大且易用的规则引擎(转）

2016 年 7 月恰逢美团点评的业务进入“下半场”，需要在各个环节优化体验、提升效率、降低成本。技术团队需要怎么做来适应这个变化?这个问题直接影响着之后的工作思路。

美团外卖的 CRM 业务步入成熟期，规则类需求几乎撑起了这个业务所有需求的半边天。

一方面规则唯一不变的是“多变”，另一方面开发团队对“规则开发”的感受是乏味、疲惫和缺乏技术含量。如何解决规则开发的效率问题，最大化解放开发团队成为目前的一个 KPI。

规则引擎作为常见的维护策略规则的框架很快进入我的思路。它能将业务决策逻辑从系统逻辑中抽离出来，使两种逻辑可以独立于彼此而变化，这样可以明显降低两种逻辑的维护成本。

分析规则引擎如何设计正是本文的主题，过程中也简单介绍了实现方案。

美团规则引擎应用实践

首先回顾几个美团点评的业务场景，通过这些场景大家能更好地理解什么是规则，规则的边界是什么。

在每个场景后面都介绍了业务系统现在使用的解决方案以及主要的优缺点。

门店信息校验

场景

美团点评合并前的美团平台事业部中，门店信息入口作为门店信息的第一道关卡，有一个很重要的职责，就是质量控制，其中第一步就是针对一些字段的校验规则。

下面从流程的角度看下门店信息入口业务里校验门店信息的规则模型(已简化)，如下图：

规则主体包括三部分：

分支条件。分支内逻辑条件为“==”和“

方案：硬编码

由于历史原因，门店信息校验采用了硬编码的方式，伪代码如下：

if (StringUtil.isBlank(fieldA)    || StringUtil.isBlank(fieldB)    || StringUtil.isBlank(fieldC)    || StringUtil.isBlank(fieldD)) {    return ResultDOFactory.createResultDO(Code.PARAM_ERROR, "门店参数缺少必填项"); }if (fieldA.length() 

优点：

当规则较少、变动不频繁时，开发效率最高。 稳定性较佳，语法级别错误不会出现，由编译系统保证。

缺点：

规则迭代成本高，对规则的少量改动就需要走全流程(开发、测试、部署)。 当存量规则较多时，可维护性差。 规则开发和维护门槛高，规则对业务分析人员不可见。业务分析人员有规则变更需求后无法自助完成开发，需要由开发人员介入开发。

门店审核流程

场景

流程控制中心(负责在运行时根据输入参数选择不同的流程节点从而构建一个流程实例)会根据输入门店信息中的渠道来源和品牌等特征确定本次审核(不)走哪些节点，其中选择策略的模型如下图：

规则主体是分支条件：

分支条件主体是“==”，参与计算的参数是固定值和用户输入实体的属性(比如：渠道来源和品牌类型)。

方案：开源 Drools 从入门到放弃

经过一系列调研，团队选择基于开源规则引擎 Drools 来配置流程中审核节点的选择策略。使用 Drools 后的规则配置流程如下图：

上图中 DSL 即是规则主体，规则内容如下：

rule "1.1"    when        poi : POI( source == 1 && brandType == 1 )    then            System.out.println( "1.1 matched" );            poi.setPassedNodes(1);  end  rule "1.2"    when        poi : POI( source &