PG官网

  前阵子给一个客户做产线数据采集，几十台设备接进来，头两天看着挺正常，第三天夜里全掉线了。查了一晚上，根因不复杂：设备端用的 MQTT 库断线重连策略是默认的，所有设备在同一时间点重连，把服务器连接数瞬间打满。这是物联网项目里很典型的一类问题，不是设备不行，是接入层的设计没跟上。

  物联网项目和普通 Web 项目差得很远。设备端的算力、内存、电量都是钱，网络环境可能比你想的差得多，而且设备一旦铺出去，出了问题你到不了现场。本文把物联网项目落地时最容易踩的几个坑过一遍：协议选型、设备认证、断线重连与数据可靠性、数据上云与平台选型、远程运维。每个坑后面都有能落地的做法，不是纸上谈兵。

  协议不是越高级越好，MQTT 也有不适合的时候。 现在一谈物联网就是 MQTT，好像不用 MQTT 就不专业。但 MQTT 本质是长连接协议，靠保持 TCP 连接和心跳维持，这在设备量大、网络不稳的时候反而成了负担。如果你的设备只是低频上报（比如一天几次），或者干脆在局域网里通过网关中转，HTTP 轮询可能更省事，实现也简单得多。选协议先看三个问题：设备多久上一次线？网络靠不靠谱？设备端资源（内存、功耗）够不够维持长连接？答案清楚了再决定用 MQTT 还是 HTTP。用 MQTT 的话，心跳间隔、KeepAlive、会话清理（clean session）这些参数都做成配置项，别用库的默认值。

  设备认证别裸奔，一机一密是底线。 很多项目前期图省事，所有设备共用同一个 token 接入。设备量小的时候没事，一旦有一台设备被拿去逆向，整个平台就暴露了。正规做法是一机一密：每台设备一个独立密钥，接入时做双向认证（TLS 证书，或者 MQTT 用户名密码加设备唯一标识绑定）。产线设备建议直接走证书双向 TLS；消费级设备至少做到一机一密加接入白名单。密钥要能吊销，设备丢了、退网了，能立刻从平台侧拉黑。

  弱网下的断线重连，是最容易被低估的坑。 设备端断线重连的默认策略几乎都是立即重连，几十上百台设备同时断网恢复，重连风暴直接把服务器打崩。要做的是指数退避加重连随机抖动，设备端和服务端都要有。另外两个 MQTT 特性建议用起来：遗嘱消息（LWT）告诉平台这台设备挂了，QoS 1 保证消息至少送达一次。QoS 2 看起来更保险，但握手开销大，消息量大的场景反而拖慢吞吐，一般业务 QoS 1 够用。设备离线期间的数据，要么设备本地缓存补报，要么平台侧做补偿，别指望消息自己补回来。

下面是设备端接入的最小可运行示例（Python + paho-mqtt），把上面几个点都覆盖了：指数退避重连、遗嘱消息、QoS 1：

import random
import time
import paho.mqtt.client as mqtt
BROKER = "your-broker.example.com"
PORT = 8883
CLIENT_ID = "device-001"
USERNAME = "device-001"
PASSWORD = "换成设备自己的密钥"  # 一机一密
TOPIC_REPORT = "factory/line1/device-001/report"
def on_connect(client, userdata, flags, rc):
if rc == 0:
print("connected")
else:
print(f"connect failed, rc={rc}")
def on_disconnect(client, userdata, rc):
# 断线由重连逻辑处理，这里只记录
print(f"disconnected, rc={rc}")
client = mqtt.Client(client_id=CLIENT_ID)
client.username_pw_set(USERNAME, PASSWORD)
client.tls_set()  # 按平台配置单向或双向 TLS
client.will_set("factory/line1/device-001/status", "offline", qos=1)  # 遗嘱消息
client.on_connect = on_connect
client.on_disconnect = on_disconnect
# 指数退避 + 随机抖动的重连循环
delay = 1
while True:
try:
client.connect(BROKER, PORT, keepalive=60)
client.loop_forever()
except Exception as e:
print(f"connect error: {e}")
time.sleep(delay + random.uniform(0, delay))
delay = min(delay * 2, 60)  # 上限 60 秒

  数据上云别一上来就自建，量没到别硬上。 几十台上百台设备，自建 EMQX 加时序数据库完全没问题，也灵活；但设备量到了几千上万，自建的成本和运维压力立刻上来了，不如直接上云厂商的物联网平台，阿里云 IoT、腾讯云 IoT、AWS IoT Core 都有现成的设备管理、规则引擎和设备影子服务。选平台之前先估算数据量：设备数乘上报频率乘单条消息大小，算出来再决定要不要上时序数据库（InfluxDB、TDengine 都行）。数据也不是全都要存，原始数据、聚合数据分库存放，冷数据定期归档，不然存储成本会吃掉整个项目利润。

  远程运维想清楚了再铺设备。 设备铺出去容易，出问题回不来。上线前至少想清楚三件事：设备日志怎么收（上报到平台还是本地缓存）、固件怎么升级（OTA 通道要预留）、设备状态怎么看（用设备影子做状态同步，别靠轮询）。远程调试也别依赖内网穿透工具，正规做法是设备通过 VPN 或者平台的反向通道接入，出问题能远程登录到设备上排查。这一块前期不做，后期每台问题设备都要派人跑现场。

  物联网项目没有银弹，多数事故最后都能归到接入设计没想清楚。先把协议、认证、重连这三个基础层做扎实，再考虑平台和数据的事，项目的稳定性会好很多。