一、规则引擎使用场景：
- 用于页面，流程，扩展点实现的选择；输出结果：实现的位置；
- 编排无数的条件积木和行为积木，达到业务逻辑计算，券库存消减的目的；输出结果：商品重计算后的价格；
- 通过订单，售后单，会员等信息编排和判断，达到多因子决策给出最佳答案的效果；输出结果：响应式回答 / 营销推荐，也或分步骤完成某类表单（售后申请，或工单提交）；
- 过订单消息的触发，和商业化协议的元数据输入，形成结构化的计费记录；输出结果：计费凭证；
业务配置 - 条件积木，以及应用的授权逻辑，都有非常多的规则管理，由于业务的变化大，需求迭代快，需要不断的嵌套规则，硬编码开发。基于业务需要，希望能建立规则引擎，将规则代码从业务中抽离出来，降低规则迭代成本，降低 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，匹配即可。