大型物联网平台都有规划规则引擎，而规则引擎到底是什么，这个组件有什么意义，具体该怎么做，这些是我在做的过程中不断问自己的问题，以下从产品角度聊聊我对这些问题的理解。
规则引擎是什么
为什么叫规则引擎
我猜这个词是英译过来的，国外的网站叫rule engine，我们也就叫规则引擎了，其实我一直好奇为啥不翻译成规则发动机，虽然不高深，但是很好理解呀。
拆词理解就是：
规则，是运作规律所遵循的法则。
引擎来源于发动机，有时候直接被用来指代发动机，泛化后被用在很多地方，比如搜索引擎。
所以物联网平台的规则引擎就是对接入设备设定规则的，而规则的基本公式是如果A，那么B。
为什么做规则引擎
物联网平台的基本功能就是对物的管理和对物产生的数据进行处理，数据的处理涉及数据的存储、流向、使用。
那么会自然的提出3个问题：
1、数据存储在哪里
2、流转至什么地方
3、怎么使用
针对这3个问题都可以通过代码实现，但是不同的行业的业务规则复杂多样，通过代码实现的话代码量、逻辑分支、代码维护工作量会不可想象。所以需要一种组件，可以将业务决策从代码中分离，易于编写，易于维护，基于这些需求，规则引擎应运而生。
其实这么解释总觉的有一点事后诸葛亮，一种组件的诞生肯定伴随的需求和功能的不断迭代，只是事后看起来清晰了很多。
规则引擎怎么做
从实际场景出发
如果公式是如果A,那么B,，那么通过下面几个例子看看A、B分别有什么。
场景1：
某个地库，红外感应器感应到有车移动，则旁边的10个灯亮，2分钟内车不动，灯灭。
A1：[某类型红外设备]感应到[车移动]，B1:[旁边10个灯][开关属性设置为开]；
A2：[某类型红外设备]感应到[2min内没有车移动]，B2:[旁边10个灯][开关属性设置为关]；
场景2:
某条街道，所有路灯夏季19:00亮，6:00灭，冬季17:30亮，7:00灭。
A1：[街上的所有路灯]在[5月1日-8月31日的19点]，B1:[街上所有路灯的开关属性设置为开]；
A2：[街上的所有路灯]在[5月1日-8月31日的6点]，B2:[街上所有路灯的开关属性设置为关]；
A3：[街上的所有路灯]在[9月1日-4月30日的17点半]，B3:[街上所有路灯的开关属性设置为开]；
A4：[街上的所有路灯]在[9月1日-4月30日的7点]，B4:[街上所有路灯的开关属性设置为关]；
场景3:
某个家，识别开门人员，非主人的话报警。
A：[门感应器]在[感应到门开]，B:[报警]；
场景4:
某个大型工厂，某类机器的温湿度数据转发至A服务（用于分析环境的服务），某类机器的运行参数，如高度、角度等数据转发至B服务（用于分析机器运转情况的服务）。
A1：[是X类机器的温度、适度]，B1:[转发至A服务]；
A2：[是Y类机器的高度、角度]，B2:[转发至B服务]；
以上几个场景可以看出A包括时间点、时间范围、日期范围、设备的属性值、设备的类型等，B可能是状态的变化、产生告警、转发数据等。
接下来的工作就是如何把这些信息整合成界面上易于操作的功能了。
需求的抽象与逻辑的整合
把以上的ABCD进一步抽象：
条件：日期、时间、设备的类型、设备的范围、设备的某个属性、设备的某个属性的值
逻辑关系：=、==、≥、≤、!=、>、＜
执行动作：告警、转发、改变属性
是不是很熟悉，在excel或者木疙瘩、axure等工具里有很多处理类似逻辑的地方
那么参考这些逻辑，整合出来的页面便是：
等等，还有好多问题没有考虑清楚：
1、条件间的逻辑关系是“与”还是“或”？（A与A）
如果是“与”，那恰好在某个点设备上报数据符合设定条件的情况在现实中存在吗？
如果是“与”，用户创建了两个时间点的条件，那这条规则就没意义了吧？
2、动作间的关系是“与”还是“或”？（B与B）
既要将数据转发到别的服务上，又要让某个设备执行某个动作，合理吗？
3、不合理的规则是按照正常（自认为正常）的逻辑写死在程序里还是让用户自己判断？
4、规则什么时候生效，立即生效还是指定时间生效，还是周期生效？
……
没有标准答案…
其实以上问题没有标准的答案，做成什么样子都要根据现实的需求来.
对于某些简单的场景，规则引擎都没必要做，有些场景，没必要做数据转发…
阿里和华为都把规则引擎分为数据转发和设备联动，这个分法比较通用，而通用的另一面便是抽象，不贴合业务。
贴合业务近的平台可以按照自己的需求划分，比如规则引擎（定时联动、设备联动）、规则引擎（设备联动、告警）、规则引擎（数据转发、定时联动、设备联动）等等。
大厂的规则引擎是怎么做的
阿里云物联网平台的规则引擎
阿里云把条件分成触发器和执行条件，好处是从代码的角度知道什么时候执行，比如
1、到点就判断条件；
2、执行动作或者上报的数据符合逻辑就判断条件，执行动作。
这样的设计我理解，规则的执行只能根据设备上报的值或者时间点开始执行程序，只有一个时间范围的时候是无法运行的，但是有些程序员思维，尤其引入“触发器”概念对用户很不友好，见仁见智吧。
条件间逻辑关系与动作间逻辑关系：
1、将条件分成触发器和执行条件，隐含的一层逻辑是触发器和执行条件间是“与”的关系。
2、触发器间的关系明确定义为“或”，可以为时间触发或者设备触发。这样设计是合理的，毕竟不管时间或者设备上报的属性/事件同时满足条件的情况几乎没有。
3、执行条件间的关系明确说明定义为“与”。
当室内温度低于23°C时
如果室内：有人
或者有宠物
则：打开空调
并将温度调节至26°C
以上例子需要创建2条联动规则，但是也可以这么设置：
当室内：有人
或者有宠物
如果室内：温度低于23°C时
则：打开空调
并将温度调节至26°C
也就是说如何使用，很大一部分由用户的脑洞决定。
4、动作间定义了关系也是“与”，这个设计我认为合理，如果确实有“或”的需求，设计的时候自己选择一个设置在规则中即可，到目前为止，没有碰到过必须是“或”的强需求。
规则的生效时间有如下设计：
1、规则列表有一个是否启动的手动开关，打开后表示规则开始生效。
2、是否指定时间生效设计在执行条件中，用的是明确的时间范围表单。
3、是否指定周期生效设计在触发器中，用的是cron表达式，很灵活，对使用者有一定要求。
华为云IoTDA的规则引擎
华为云就只有执行条件和执行动作，把生效周期和范围这个条件隐含在了规则的基本信息中，个人觉得这样设计对使用者更友好。
条件间逻辑关系与动作间逻辑关系：
1、将生效周期和时间范围放在规则的基础信息中隐含的一层逻辑是生效时间和执行条件间是“与”的关系。
2、执行条件间通过灵活的选项让用户选择是“或”还是“与”，设计很灵活，灵活的反面就是错误操作导致条件间相互矛盾，规则只判断不执行。
3、动作间逻辑关系是指定“与”。
规则的生效时间有如下设计：
1、规则列表有一个是否启动的手动开关，打开后表示规则开始生效。
2、是否指定时间生效设计在规则基础信息中，用的是明确的时间范围表单。
3、是否指定周期生效同样设计在规则基础信息中，指定按照“周”循环，用户很明确知道怎么用，但是按照年、月循环的场景无法实现。
做的时候如何决策和平衡
参考同类型的产品会发现同样的功能如何做都存在优劣势，做好选择便是我们要考虑的问题，而决策的源头不仅是公司面临的实际需求、市场的变化、技术的选型都会影响最后的呈现，一点小小的不同便会导致大大的差别。
而这个软能力并非一蹴而就，我们可能需要一边往前走一边检验，是否做得好甚至还需要一点点运气。
文中描述的细节只涉及到了规则的逻辑组织，但是数据关系的细节更多，主要和物模型的定义、设备接入、技术选型有关，就不再赘述了。
