规则引擎解决方案浅析

一、规则引擎使用场景：

1. 用于页面，流程，扩展点实现的选择；输出结果：实现的位置；
2. 编排无数的条件积木和行为积木，达到业务逻辑计算，券库存消减的目的；输出结果：商品重计算后的价格；
3. 通过订单，售后单，会员等信息编排和判断，达到多因子决策给出最佳答案的效果；输出结果：响应式回答/营销推荐，也或分步骤完成某类表单（售后申请，或工单提交）；
4. 过订单消息的触发，和商业化协议的元数据输入，形成结构化的计费记录；输出结果：计费凭证；

业务配置-条件积木，以及应用的授权逻辑，都有非常多的规则管理，由于业务的变化大，需求迭代快，需要不断的嵌套规则，硬编码开发。基于业务需要，希望能建立规则引擎，将规则代码从业务中抽离出来，降低规则迭代成本，降低if else等的规则嵌套，增强代码的维护性和复用性。开发人员不用过多的关注逻辑判断，可以专注与逻辑处理。

有很多规则，如校验是通过if else逻辑硬编码完成，商品目前支持电商、零售等业务部门，无非就是两种情况：一种是商品领域模型的变更，还有一种是规则的变更。可以说，支撑上层业务，业务规则占了需求的半边天。

通用的业务规则引擎，不和自己的业务藕合，提供一个通用的规则引擎是可行的。

二、什么是规则引擎

规则引擎是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。

规则本质上是一个函数，如y=f(x1,x2,..,xn)

规则引擎由三部分

• 事实（Fact）：就是用户输入的已经事实，可以理解为推理前的已知对象。
• LHS(Left Hand Side)：可以理解为规则执行需要满足的条件。
• RHS(Right Hand Sike)：可以理解为规则执行后的返回对象。

两个重要模块：

• 规则管理：可以理解为逻辑上管理规则，主要涉及规则、事实对象和规则集三个实体。涉及到规则变更时，最好对规则加个版本，可通过规则版本控制，可以平滑灰度地方式改变规则，也便于更有信心在测试规则正确性。

• 规则执行：通过规则库数据，通过规则引擎的规则解析、规则编译将可执行代码缓存起来，避免每次和DB交互，然后每次规则的变更也通过ZK或者DCC实时通知给规则执行器。规则执行器的实现方式，可以多种多样，不依赖于规则库的存储方式，可以根据需求，选用Drools、Aviator等第三方引擎，甚至可以基于ANTLR定制。

三、实践总结

实践出真理。调研了一些 Java 的规则引擎框架：

• drools比较重，适合风控金融，反欺诈。Avator、Fel、QLExpress 等不太适合搜索路由场景
• 用基于 Apollo 或者 grovvy脚本等实现引擎，配置路由规则到 apollo 或者 脚本即可。

如果是简单的场景，我们只要定义好关键条件 key ，命中 key ，返回 key 对应的 result 即可。

如果复杂金融场景，drools 比较合适。

比如一个搜索场景，按照优先级由上到下：

1. 如果带了某个店铺ID，路由到店铺分片的搜索索引
2. 如果带了某个买家ID，路由到买家分片的搜索索引
3. 如果状态是热状态，路由到热状态索引
4. 如果...

这种简单的，就用 apollo 定义好关键条件 json ，匹配即可。