Yeats' Wiki

外观

阿里云 · 消息与规则引擎：从设备上报到多目标分发的最后一公里 ​

技术栈：阿里云物联网平台消息通道与规则引擎（Serverless）作为具体案例 适用场景：理解百亿级设备消息怎么可靠流转、实时优先，又怎么通过规则引擎自动"流"到数据库、队列、业务系统

设备连上来，下一句话就是"发消息"。

但"连得上"和"消息到得了"是两件事：连接关心的是这个设备在不在；消息关心的是它发的那条数据到没到、快不快、该去哪。

当消息量从每天几万条变成百亿级，事情就变了味：一条告警晚到 3 秒可能就错过了关断窗口，一条数据丢了可能让整张统计报表失真，而不同业务系统还都抢着要同一份数据。

这一篇讲消息层：怎么在百亿级规模下，仍然让消息可靠、实时、并且自己知道该去哪。

消息与规则引擎

消息全链路架构（官方原图）

消息规则引擎（官方原图）

（以下为阿里云官方原图，作对照参考）

1.问题背景：消息层的三道坎 ​

1.1 海量消息 + 实时性 ​

设备上行消息是持续、高频、且不可预测的突发流。一个省的电表在整点会同时上报，一个工厂的传感器在异常时会瞬间灌数据。平台要在这种潮汐里，既保证不丢，又保证够快。

1.2 设备发什么都有，平台要统一收 ​

设备侧数据是五花八门的：有的发 JSON，有的发二进制，有的按自己的私有字段命名。平台不能要求每个设备都改成统一格式——那样接入成本爆炸。平台得自己把差异"吃"进来，再做归一。

1.3 一份数据，多个业务都要 ​

监控大屏要看实时温度，数据库要落盘做统计，算法服务要喂模型做预测。同一个温度值，三个系统都要。如果让每个业务系统都去"蹲"设备消息，既浪费连接，又容易乱。

2.设计理念：解耦、可靠、再让消息"自己跑" ​

2.1 协议解耦：设备怎么发，平台都能收 ​

消息接入层先做一个"翻译官"：不管设备用的是 MQTT、CoAP 还是 HTTP，上来之后统一抽象成平台内部的消息对象。设备和下游业务之间，第一次被解耦——设备改不改格式、用不用新协议，都不影响业务侧。

2.2 可靠可达 + 实时优先：两个硬指标 ​

平台在设计上把"消息"当成有 SLA 的东西：

  • 可达率 99.99%：消息不轻易丢，关键链路有重发、有确认、有积压保护；
  • 实时优先：热数据走实时通道，不和业务落盘、统计任务挤同一条道。

这背后是"消息到达前的中枢"——先把海量 Topic 隔离开、把实时和离线分开，再谈可靠。

2.3 规则引擎：让消息"自己流"到该去的地方 ​

这是最关键的一步。平台提供规则引擎（Serverless 形态）：你写一条类似 SQL 的规则，描述"从哪个 Topic 取哪些字段、满足什么条件、转发到哪里"，剩下的事平台自动办。

sql
SELECT deviceName, temperature, humidity
FROM /a1b2c3/+/user/update
WHERE temperature > 30

这条规则的意思是：从产品 a1b2c3 下所有设备的 /user/update Topic 里，挑出温度大于 30 的数据，转发走。转发的目标可以是：

text
规则引擎转发目标（按需任选）：
  表格存储 / 时序数据库  →  落盘、统计、回溯
  消息队列 RocketMQ/Kafka →  给下游业务系统消费
  函数计算 FC             →  触发一段自定义逻辑（如告警）
  业务 API / AMQP         →  直接推给自有系统

把消息层的能力串起来：

mermaid
graph LR
  D[海量设备<br/>MQTT/CoAP/HTTP] --> M[消息接入层]
  M -->|协议解耦| R[规则引擎 Serverless]
  R -->|SQL式过滤| DB[(数据库/时序库)]
  R -->|实时转发| MQ[消息队列]
  R -->|触发| FC[函数计算]
  R -->|推送| API[业务系统]
  M -. 99.99%可达 实时优先 .-> R

3.实际应用：配规则时盯什么 ​

  • Topic 规划先行。海量 Topic 要按"产品 / 设备 / 用途"分层，别把所有设备塞进一个 Topic，否则规则过滤和权限都难做；
  • 能下推到规则引擎的，别写代码。数据转发、过滤、简单计算，优先用规则引擎配置，而不是自己起一个消费者服务；
  • 实时和离线分通道。监控看实时，统计走离线/落盘，别让落盘任务拖慢实时链路。

4.注意事项 ​

（1）可达率不是口号。 99.99% 背后是重发、确认、积压保护一整套工程。自建时最容易忽略"消息积压"——设备一突发，队列就满，满则丢。

（2）规则别写成"全量转发"。 SELECT * 把所有数据无脑转走，既费流量又费下游。按字段、按条件过滤，是基本功。

（3）协议解耦有边界。 平台能消化协议差异，但设备侧的字段语义（"temp"到底是不是温度）还得靠物模型来约定——这正是下一篇（四）的话题。

5.小结 ​

消息层要解决的，是"百亿级消息，怎么既不丢、又快、又各自到该去的地方"。它的三板斧是：协议解耦让设备自由发、可靠+实时让消息靠得住、规则引擎让消息自己跑。

真正省事的，是最后这一刀：把"数据怎么流转"从写代码变成"配规则"。下一篇（四），我们讲物模型与数字孪生——消息到了平台，平台怎么"看懂"这台设备。

参考链接 ​