规则引擎解决方案浅析

1、规则引擎使用场景：

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

业务配置-条件积木，以及应用的受权逻辑，都有很是多的规则管理，因为业务的变化大，需求迭代快，须要不断的嵌套规则，硬编码开发。基于业务须要，但愿能创建规则引擎，将规则代码从业务中抽离出来，下降规则迭代成本，下降if else等的规则嵌套，加强代码的维护性和复用性。开发人员不用过多的关注逻辑判断，能够专一与逻辑处理。

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

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

2、什么是规则引擎

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

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

规则引擎由三部分

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

两个重要模块：

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

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

3、实践总结

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

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

若是是简单的场景，咱们只要定义好关键条件 key ，命中 key ，返回 key 对应的 result 便可。

若是复杂金融场景，drools 比较合适。

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

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

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