4、规则引擎入门：规则引擎概念、SQL语法基础、规则链设计思想
好，咱们进入第四章。这一章可以说是整个IoT平台里最“灵魂”的部分——规则引擎。我见过不少开发者，设备接上来了，数据也上报了，但就是不知道怎么让数据“活”起来。说白了，规则引擎就是那个让数据流动、触发动作、产生价值的核心引擎。
4.1 规则引擎到底是什么？
先别急着看代码。咱们先聊聊概念。
规则引擎，你可以把它理解成一个“智能管道工”。设备上报的数据就像水流，规则引擎就是那个能识别水流、判断水质、然后决定把水送到哪个水池的管道工。它不存数据，但它决定数据去哪、触发什么动作。
我在华为云IoT平台上做过一个智慧园区的项目。当时客户说：“设备数据都上来了，但我要的是——当温度超过35度时，自动打开空调；当湿度低于20%时，自动启动加湿器。” 你想想看，如果没有规则引擎，你得写多少后端代码？轮询、判断、调用接口……累不累？
规则引擎就是干这个的。它让你用SQL语句或者图形化配置，就能完成这些逻辑。
核心要点：规则引擎 = 数据输入 + 条件判断 + 动作输出。它不负责存储，只负责流转。
4.2 SQL语法基础——别怕，很简单
很多同学一听到SQL就头疼。其实在IoT规则引擎里，你只需要掌握几个最常用的语法就够了。我刚开始接触时也觉得复杂，后来发现，常用的就那三板斧。
4.2.1 SELECT 与 FROM
最基本的，就是选择数据。比如设备上报了一个JSON数据：
{
"deviceId": "abc123",
"temperature": 28.5,
"humidity": 65,
"timestamp": 1690000000
}你想拿到温度值，怎么写？
SELECT temperature FROM /device/abc123/data就这么简单。FROM后面跟的是数据源，也就是设备上报的Topic或者数据流。SELECT后面跟你要提取的字段。
我的小技巧：如果你不确定字段名，可以先写一个 SELECT * 看看全部数据长什么样。我在项目中经常这么干，调试时特别方便。
4.2.2 WHERE 条件过滤
光拿到数据还不够，你得判断。比如我只关心温度超过30度的数据：
SELECT temperature, deviceId
FROM /device/abc123/data
WHERE temperature > 30这里要注意，WHERE后面支持常见的比较运算符：>、<、>=、<=、=、!=。也支持AND、OR组合条件。
我曾经踩过一个坑：在WHERE条件里用了字符串比较，结果字段类型不匹配，一直没触发。后来才发现，温度字段在JSON里是数字，但我写成了字符串。嗯，这里要注意类型一致性。
4.2.3 函数与表达式
有时候你需要对数据做点加工。比如把摄氏温度转成华氏：
SELECT (temperature * 9/5 + 32) AS temp_fahrenheit
FROM /device/abc123/data华为云IoT规则引擎还支持一些内置函数，比如获取当前时间、字符串拼接等。常用的有：
| 函数 | 说明 | 示例 |
|---|---|---|
| now() | 获取当前时间戳 | SELECT now() AS current_time |
| concat() | 字符串拼接 | SELECT concat(deviceId, '_alert') AS alert_id |
| toint() | 转为整数 | SELECT toint(temperature) AS temp_int |
注意：函数名大小写敏感。我见过有人写NOW()小写，结果报错了。建议统一大写。
4.3 规则链设计思想——别做成“面条式”逻辑
好，SQL语法咱们过了一遍。接下来聊聊更重要的——规则链设计。
什么叫规则链？说白了，就是多个规则串在一起，形成一个处理流水线。数据先经过规则A，再经过规则B，最后到规则C。每个规则只做一件事。
我为什么强调这个？因为我在早期项目里吃过亏。当时一个规则里写了七八个条件，嵌套了三四层IF-ELSE逻辑。结果呢？调试时根本分不清是哪一步出了问题。后来我痛定思痛，开始用规则链。
3.1 单一职责原则
每个规则只做一件事。比如：
- 规则1：过滤掉无效数据（比如温度值为空或负数）
- 规则2：判断是否超阈值（温度>35度）
- 规则3：触发告警动作（发送短信或邮件）
这样设计的好处是：哪天你想改告警方式，只动规则3就行，规则1和2完全不受影响。
3.2 数据流转的“漏斗”模型
我习惯把规则链想象成一个漏斗。数据从最宽的口进来，经过一层层过滤，最后只有符合条件的数据到达终点。
举个例子：
数据入口 → 规则A（过滤无效数据） → 规则B（判断是否超阈值） → 规则C（触发告警）如果数据在规则A就被过滤掉了，它就不会进入规则B和C。这样能大大减少不必要的计算。
设计原则：先过滤，再判断，最后执行动作。顺序别搞反了。
3.3 分支与合并
有时候数据需要走不同的路径。比如温度超阈值走告警链路，湿度正常走存储链路。这时候就需要分支。
华为云IoT规则引擎支持条件分支。你可以这样设计：
数据入口
├── 温度 > 35 → 告警规则 → 发送短信
└── 温度 <= 35 → 存储规则 → 写入数据库你想想看，这种设计是不是很清晰？每个分支独立维护，互不干扰。
我的建议：刚开始设计规则链时，先在纸上画流程图。把数据流向、判断条件、动作都画出来。画清楚了再动手配置。我每次都是这么干的，很少出问题。
4.4 避坑指南——我踩过的那些坑
最后，分享几个我实际项目中遇到的坑，希望能帮你少走弯路。
- 坑1：SQL语句里字段名写错了。 比如JSON里是"temperature"，你写成了"temp"。规则不会报错，但永远不触发。调试时记得先用SELECT *看看。
- 坑2：规则链循环依赖。 规则A的输出又回到了规则A的输入，形成死循环。我曾经遇到过，结果平台直接报错，整个规则链都停了。
- 坑3：动作执行失败没有重试机制。 比如发送短信的接口超时了，数据就丢了。建议在关键动作上加上重试或者异常处理。
- 坑4：时间戳精度问题。 设备上报的时间戳是毫秒级，但规则引擎里用的是秒级。不转换的话，时间对比会出错。
好了，这一章的内容就到这里。规则引擎其实不难，关键是理解它的设计思想——让数据流动起来，而不是死在那里。下一章咱们会深入实战，用华为云IoT平台实际配置一个规则链。到时候你会看到，这些概念用起来有多爽。