问题背景：一条告警要走多少冤枉路
设备数据上云的链路，很多团队一开始都容易做重。典型做法是设备通过 MQTT 上报到一台常驻的接入服务器，接入层做协议解析后写入 Kafka，再由一个消费服务做规则判断，命中阈值后调用告警接口。这套架构本身没有错，但它隐含了一个前提：你必须长期养着接入服务和消费服务这两组进程，哪怕夜里设备上报量掉到个位数，机器和容器照样得开着。对于一个只有几百台设备、上报频率十几秒一次的小项目来说，这种常驻成本很快就显得不划算。
更麻烦的是运维负担。接入服务要处理断连重连、心跳保活、粘包拆包，消费服务要考虑位点提交和重复消费，任何一处出问题都会表现为“告警没收到”，排查路径长且分散。实际业务方关心的其实只有三件事：数据有没有进来、阈值有没有被突破、突破了有没有通知到人。至于中间经过几个组件，他们并不在意。所以这次我们尝试用函数计算把这条链路压到最小，目标是把常驻组件全部去掉，只保留“触发即执行”的计算单元。
方案选型：三种接法的取舍对比
我们对比了三条路线。第一条是自建 MQTT Broker 加常驻消费者，优势是协议成熟、可控性强，劣势是至少需要两台小规格 ECS 做高可用，按年算下来固定支出在六千元以上，且版本升级、证书续期都要人工介入。第二条是用消息队列产品做缓冲，设备侧通过 SDK 直投，函数计算消费队列触发，链路可靠、削峰能力强，但消息队列本身有最小规格费用，且引入了一个新的需要监控的中间件，对这个小体量场景属于过度设计。
第三条是我们最终选择的：设备通过 HTTP 或 MQTT 接入阿里云物联网平台，平台侧的规则引擎把消息直接投递到函数计算，函数内部完成解析、阈值判断和告警调用。取舍点在于，我们把“接入层的复杂性”完全交给了托管服务，自己只写业务逻辑那几十行代码。代价是设备侧要按平台规范做一次改造，大约每台设备改半天工作量，但换来的是零常驻实例、按调用计费、免运维。对于设备数量在千级以内、上报频率不高的场景，这个交换是划算的；如果设备规模上到十万级且要求毫秒级端到端延迟，那还是应该回到常驻接入加消息队列的路线，函数计算的冷启动和并发模型会成为瓶颈。
落地步骤：四步跑通最小链路
第一步是设备侧改造。我们把原有私有协议的 TCP 上报改成 MQTT 上报，主题按产品维度划分，payload 保持精简的 JSON，只带设备 ID、时间戳和几个关键指标。这里有个细节值得说：时间戳一定要用设备本地时间并附带时区，不要依赖服务端接收时间，否则设备离线补传的数据会被判成“当前异常”，导致误告警。改造完成后在平台上做设备注册和三元组烧录，用平台自带的在线调试工具验证消息能正常上报。
第二步是配置规则引擎。在物联网平台的控制台里建一条规则，SQL 写法就是从主题里筛选需要的字段，动作选择“发送到函数计算”，指定目标服务和函数。这一步不需要写代码，但要留意消息格式：规则引擎投递给函数的是一个包含多条消息的数组结构，函数入参需要按这个结构解析，很多同学第一次接的时候在这里踩坑，拿到的 payload 是空的。
第三步是写函数。函数用 Python 实现，逻辑分三段：解析入参取出设备数据和上下文、按设备维度做阈值判断、命中后调用告警 webhook。阈值判断我们做得很轻，没有引入规则引擎或配置中心，而是把阈值放在函数的环境变量里，按设备分组配置几个 JSON 字符串，函数启动时读一次。这样做的好处是改阈值不用发版，坏处是分组多了以后环境变量会变长，超过限制就得换成配置中心，属于已知的可扩展边界。告警调用做了重试和去重，同一个设备五分钟内只发一次，避免抖动刷屏。
第四步是观测。函数计算自带调用次数、错误率、执行时长三个指标，我们在函数里额外打了一行结构化日志，把设备 ID、指标值、是否触发告警记下来，接入日志服务后配一个简单的查询面板。告警链路的兜底是给函数配置死信队列，执行失败的消息进队列，再由一个定时触发的函数每分钟扫一次，发现积压就发运维告警。这样即使主链路出问题，也不会静默失败。
效果与成本：数字比描述更有说服力
上线运行三个月，几个关键数字如下。成本方面，原来两台 ECS 加一个消息队列实例，月支出约七百元；现在函数计算按调用计费，日均调用约四万次，单次执行时长均值八十毫秒，月账单稳定在四十元上下，成本下降约百分之九十四。延迟方面，从设备上报到告警送达，端到端 P95 延迟为一点二秒，其中函数冷启动占比很小，因为上报频率稳定，实例基本保持温热；对比原方案的两秒左右，反而略有改善。并发方面，压测下单函数实例并发跑到两百时，错误率仍为零，平台自动扩容在三十秒内完成，这个弹性是常驻服务很难低成本做到的。
需要说明的是，这套方案适合的是“设备量中等、告警实时性要求秒级而非毫秒级、团队没有专职中间件运维”的场景。它的边界也很清楚：如果单设备上报频率高到每秒一次以上，或者需要做跨设备的窗口聚合计算，函数计算的按次计费和状态管理就会变成短板，那时候老老实实上消息队列加常驻消费者才是正解。最小链路的价值不在于普适，而在于让你用最低的固定成本先跑通业务闭环，等量级上来了再按需加组件，而不是一开始就把架构撑到用不满的规模。
