mysql 规则引擎_构建强大且易用的规则引擎

原标题：构建强大且易用的规则引擎

作者 | 张宁

来源 | 公众号「zhisheng」

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

美团外卖的CRM业务步入成熟期，规则类需求几乎撑起了这个业务所有需求的半边天。一方面规则唯一不变的是“多变”，另一方面开发团队对“规则开发”的感受是乏味、疲惫和缺乏技术含量。如何解决规则开发的效率问题，最大化解放开发团队成为目前的一个KPI。

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

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

案例

首先回顾几个美团点评的业务场景。通过这些场景大家能更好地理解什么是规则，规则的边界是什么。在每个场景后面都介绍了业务系统现在使用的解决方案以及主要的优缺点。

门店信息校验

场景

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

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

规则主体包括3部分：

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

简单计算规则。如：字符串长度。

业务定制计算规则。如：逆地址解析、经纬度反算等。

方案——硬编码

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

if (StringUtil.isBlank(fieldA)

|| StringUtil.isBlank(fieldB)

|| StringUtil.isBlank(fieldC)

|| StringUtil.isBlank(fieldD)) {

return ResultDOFactory.createResultDO(Code.PARAM_ERROR, "门店参数缺少必填项");

}

if (fieldA.length < 10) {

return ResultDOFactory.createResultDO(Code.PARAM_ERROR, "门店名称长度不能少于10个字符");

}

if (!isConsistent(fieldB, fieldC, fieldD)) {

return ResultDOFactory.createResultDO(Code.PARAM_ERROR, "门店xxx地址、行政区和经纬度不一致");

}

优点

当规则较少、变动不频繁时，开发效率最高。

稳定性较佳：语法级别错误不会出现，由编译系统保证。

缺点

规则迭代成本高：对规则的少量改动就需要走全流程(开发、测试、部署)。

当存量规则较多时，可维护性差。

规则开发和维护门槛高：规则对业务分析人员不可见。业务分析人员有规则变更需求后无法自助完成开发，需要由开发人员介入开发。

门店审核流程

场景

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

规则主体是分支条件：

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