这两年客户问得最多的问题之一，是老板想在手机上看厂里实时数据，出差也能瞄一眼产量和报警。数据上云路子不少，直接POST是一种，走消息中间件也是一种，工厂场景用得最多的还是MQTT。它轻、省流量、一对多分发方便，天生适合一堆设备往外发数据。不过它的概念比HTTP多，主题、QoS、遗嘱、保留消息，搞明白上云很顺，搞不明白要么消息莫名丢，要么服务器被自己拖垮。这篇讲上位机怎么把数据稳稳送上云。
MQTT和直接POST到底有啥不一样
HTTP POST是一问一答，发一条数据服务器回个状态完事。MQTT是发布订阅模式，上位机只管往某个主题发，不关心谁在收，云端看板、手机推送、数据库各自订阅，一份数据多个出口互不打扰。好处很实在，加新应用设备程序不用改；长连接不用每条数据重新握手，弱网省电省流量，上千台设备差别明显；服务端还能主动往下发，云端改参数有了正经通道。当然不是HTTP一无是处，对方只给REST接口就老老实实POST。选型看场景，小项目一个接口能解决，没必要上全套中间件。另外报警和实时数据别放一个主题，一个要可靠一个要轻快，混在一起QoS都没法选。
主题怎么设计才不返工
主题是MQTT的灵魂，斜杠分层像目录路径。新手常把所有数据揉成一个大主题，塞一大串JSON，后面想单独订一台设备、只收报警根本没法分。合理设计从粗到细，厂、车间、线、设备、数据类型一层层下来，订阅端用加号匹配单层、井号匹配多层，看一条线还是看全厂写法不一样。几个原则，主题里放身份和分类，正文里放数据；设备编号固定，别拿IP当编号；实时数据、报警、状态、指令回执分开主题，高频低频分开，云端处理策略也能分开。主题树上线就是契约，设备多了改起来伤筋动骨，设计阶段多画几版找人把关，这步省的时间后面加倍还你。主题命名的大小写、连字符也要全场统一，别这台设备用line1那台用Line01，订阅规则写起来全是特例。
QoS三个级别到底怎么选
QoS是服务质量，0发出去不管，1保证至少到一次，2保证正好一次，级别越高握手越多。有人怕丢全设2，几千台设备一起发，broker光确认就忙够呛。我按重要性分，每秒的温度压力丢一两条无所谓，下一周期新值就来，用0；报警、停机、班次产量不能丢，用1，重复的云端按编号去重；参数下发、远程控制要求不重不丢，才用2。两个机制必须用，遗嘱消息，设备异常掉线broker替它发离线通知，云端立刻知道；保留消息，最新状态留在主题上，手机晚打开也能看到最后值，不用对着空屏等。
断网了数据怎么办
工厂外网说断就断，挖断光纤、运营商故障，几小时不通是常事。最忌讳数据只往云端发本地不留，网一恢复中间几小时是个黑洞。正确姿势是本地照样采照样存，SQLite写历史，待发消息进本地队列，每条带编号和时间戳。恢复后自动重连，按顺序补发，云端按真实时间戳入库，不按到达时间覆盖。补发要限速，几万条一下全发出去两边都扛不住，实时新数据优先于历史补发。秒级数据积压太久只补分钟汇总，报警产量这类关键事件隔多久都得补齐。设备本地时钟还要靠NTP定期对时，不然补上去的时间戳本身就是错的，云端再怎么按时间入库也是一笔糊涂账。
上云项目还有哪些坑
安全是头等大事，内网设备上了云还裸奔，谁都能连，没多久被扫到往主题灌垃圾。必须开认证，用户名密码只是起步，设备多了用TLS证书一机一密，能轮换能吊销。权限按主题收紧，设备只能发自己的主题，一台被攻破不至于全厂沦陷。数据对不上多半是时间戳时区问题，统一用带时区的时间，东八区写明白。broker要监控，连接数、消息速率、堆积量看得见。上云前先问数据是不是必须出去，配方工艺参数要不要脱敏，合规比技术优先。别听了高可用宣传就不做本地兜底，云会抖网会断，现场系统能独立活才是真稳。Payload用JSON好调试但占字节，几千台设备天天发，流量也是钱，可以缩写字段或上二进制格式，按成本权衡。
数据上云建议从一台设备一个看板开始，跑顺再批量接。需要从设备联网、MQTT网关到云端看板一站式落地，找赢式科技，电话15001875806，微信同号，长三角上门。把设备数量、点位频率和云端功能列清楚，方案好定。