这是我参与「第五届青训营 」伴学笔记创作活动的第 5 天
概述
所谓规则引擎，指的是if some condition match then trigger some thing的机制。condition是一系列的expression，比如设备状态变更为离线（属性），考勤有人通过闸机（事件）；trigger一系列的action，比如存储到数据库、发出告警信息。乃至于触发其他设备的动作，比如温度过高则判断火灾则触发喷淋联动。
将rule抽象出来，让用户可以自由定义，就是设计规则。关联好rule和action，本质就是一种回调注册机制，当condition匹配时，代码会query用户已经定义的action，并依次触发（当然还有服务端写死的一些action）。
可以match的condition，以及可以trigger的action，都是我们实现定义好的模版，用户可以在rule/action里面填入自定义的参数。因此设计规则引擎就是设计一种模版语言，前端可以渲染这种语言让用户填充参数，后端可以解析这种语言实现对应的逻辑。因为这相当于设计一种语言。举个例子，如果写python的话，可以直接用python写condition，然后eval计算结果。对于Java而言，开源的drools本质上是一门脚本语言，让客户端去解析这个工作量太大，不太可能采用；而urule的开源版功能过于孱弱，只能拿来参考。不过如果使用工作流引擎，比如flowable，内部集成了DMN决策树，本质上就是一个规则引擎，可以考虑直接使用，不过我们这里简化了一下用了自己的实现。
condition和action的设计依赖于设备本身能提供的功能，因此需要将设备具体的型号和能支持的condition/action关联起来。举例来说，如果考勤机支持温度上报，那么就可以支持定义体温报警。不支持的话，用户就没法设置体温报警。
规则引擎的组成 数据输入、规则理解、规则执行
数据输入 支持接受使用预定义的语义编写的规则作为策略集。比如 " price > 500 "
支持接受业务的数据作为执行过程中的参数，比如价格、标签等
规则理解 能够按照预先定义的词法、语法、优先级、运算符等正确理解业务规则所表达的语义。
规则执行 根据执行时输入的参数对策略集中的规则进行正确的解释和执行。同时对规则执行过程中的数据类型进行检查，确保执行结果正确。
规则引擎使用场景：
用于页面，流程，扩展点实现的选择；输出结果：实现的位置；
编排无数的条件积木和行为积木，达到业务逻辑计算，券库存消减的目的；输出结果：商品重计算后的价格；
通过订单，售后单，会员等信息编排和判断，达到多因子决策给出最佳答案的效果；输出结果：响应式回答/营销推荐，也或分步骤完成某类表单（售后申请，或工单提交）；
过订单消息的触发，和商业化协议的元数据输入，形成结构化的计费记录；输出结果：计费凭证；
使用规则引擎的优势
业务规则与系统代码分离，实现业务规则的集中管理
在不重启服务的情况下可随时对业务规则进行扩展和维护
可以动态修改业务规则，从而快速响应需求变更
规则引擎是相对独立的，只关心业务规则，使得业务分析人员也可以参与编辑、维护系统的业务规则
减少了硬编码业务规则的成本和风险
使用规则引擎提供的规则编辑工具，使复杂的业务规则实现变得的简单
