一, 规则引擎使用场景:
用于页面, 流程, 扩展点实现的选择; 输出结果: 实现的位置;
编排无数的条件积木和行为积木, 达到业务逻辑计算, 券库存消减的目的; 输出结果: 商品重计算后的价格;
通过订单, 售后单, 会员等信息编排和判断, 达到多因子决策给出最佳答案的效果; 输出结果: 响应式回答 / 营销推荐, 也或分步骤完成某类表单 (售后申请, 或工单提交);
过订单消息的触发, 和商业化协议的元数据输入, 形成结构化的计费记录; 输出结果: 计费凭证;
业务配置 - 条件积木, 以及应用的授权逻辑, 都有非常多的规则管理, 由于业务的变化大, 需求迭代快, 需要不断的嵌套规则, 硬编码开发. 基于业务需要, 希望能建立规则引擎, 将规则代码从业务中抽离出来, 降低规则迭代成本, 降低 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 比较合适.
比如一个搜索场景, 按照优先级由上到下:
如果带了某个店铺 ID, 路由到店铺分片的搜索索引
如果带了某个买家 ID, 路由到买家分片的搜索索引
如果状态是热状态, 路由到热状态索引
如果...
这种简单的, 就用 apollo 定义好关键条件 JSON , 匹配即可.
来源: https://www.cnblogs.com/Alandre/p/11491221.html