1. 项目缘起与整体架构设计1.1 为什么要把4G云广播和4G免流量监控放在同一平台这个项目的出发点其实很朴素很多场景下广播和监控是天然一对。比如工地、矿区、农场、偏远路口、临时施工现场这些地方往往没有稳定的有线网络但既需要定时或实时喊话又需要看现场画面。如果广播走一套系统、监控走另一套系统运维人员要维护两张SIM卡、两个后台、两套账号成本高不说出了问题还得两头排查。把两者整合到同一平台核心价值在于三点。第一共用一条4G通道的流量池免流量监控通常走定向流量或专网通道广播的指令流和控制流可以复用这条链路不必再单独开卡。第二统一设备管理设备上下线、心跳、告警都在一个后台看运维效率翻倍。第三联动能力比如监控画面里检测到异常可以自动触发广播喊话这是分开部署做不到的。从技术选型上看这个平台的核心通信层我最终选了MQTT TCP 双协议栈。为什么不是纯MQTT或者纯TCP下面细说。1.2 通信协议选型MQTT与TCP各管一段先说结论控制信令走MQTT音视频流和透传数据走TCP。MQTT 是发布/订阅模型天生适合设备状态上报、指令下发、心跳保活。它的优势是长连接维护成本低、支持QoS分级、断线重连机制成熟。广播设备的开关、音量、播放列表更新、定时任务下发这些都用MQTT走。但MQTT不适合传大块音频流。音频数据对时延敏感走MQTT的broker转发会引入额外跳数而且MQTT的payload不适合做流式传输。所以音频流和监控视频流走原生TCP长连接设备与平台之间直接建立socket通道平台侧做流分发。这里有个关键点免流量监控的“免流量”通常依赖运营商定向流量策略也就是说设备访问的IP或域名在白名单内才不计费。所以平台的服务端地址必须是固定的、备案过的不能随便换。这一点在架构设计初期就要和运营商确认清楚否则后期迁移会非常麻烦。通信类型协议典型用途QoS/可靠性控制信令MQTT开关、音量、定时、状态上报QoS 1音频流TCP实时喊话、文件播放自定义重传视频流TCP监控画面回传丢帧优先透传数据TCP485设备指令、Modbus请求应答1.3 平台整体拓扑整个平台分四层设备层、接入层、业务层、应用层。设备层就是4G广播终端和4G摄像头它们通过4G模组拨号上网内置MQTT客户端和TCP客户端。接入层是MQTT Broker我用的EMQX和TCP接入网关。业务层负责设备管理、任务调度、流媒体转发、数据存储。应用层就是Web后台和手机端。这里要特别提一句MQTT Broker和TCP网关最好部署在同一内网通过内网通信减少公网暴露面。对外只暴露Broker的MQTT端口和TCP网关的流端口其他一律走内网。2. 核心细节解析与实操要点2.1 MQTT主题设计与消息格式主题设计是MQTT落地最容易踩坑的地方。我的原则是层级清晰、可通配、带设备ID。推荐的主题结构/{product}/{deviceId}/cmd 下发指令 /{product}/{deviceId}/state 状态上报 /{product}/{deviceId}/event 事件通知 /{product}/broadcast 群发广播product用来区分广播设备和监控设备deviceId用IMEI或自定义唯一码。群发主题用通配符订阅比如平台订阅//state就能收到所有设备状态。消息体统一用JSON字段尽量精简。举个例子广播开关指令{ cmd: play, url: http://xxx/audio/001.mp3, vol: 80, ts: 1730000000 }注意MQTT的payload不要超过1KB大文件走URL引用不要直接塞base64。我见过有人把整段音频base64塞进MQTT结果broker内存直接爆掉。2.2 TCP接入网关的设计要点TCP网关是整个平台最容易被忽视但最关键的组件。它要处理大量长连接每个连接对应一个设备。设计要点连接鉴权设备连上来第一件事是发鉴权包带deviceId和token网关校验通过才允许后续通信。心跳机制TCP本身没有心跳需要应用层自己做。我设的是30秒无数据就发心跳包90秒无响应就断开。粘包处理TCP是流式协议必须自定义包头。我用的是魔数(2B) 长度(4B) 命令(2B) 数据(N)的格式。连接映射维护deviceId - socket的映射表方便平台主动下发指令。// 简化的包头结构 typedef struct { uint16_t magic; // 0xAA55 uint32_t length; // 数据长度 uint16_t cmd; // 命令字 char data[]; // 变长数据 } PacketHeader;实操心得TCP网关一定要做连接数限制和限流。我遇到过设备固件bug导致疯狂重连瞬间把网关打满。后来加了单IP连接数限制和重连退避才稳住。2.3 免流量监控的定向流量配置“免流量”不是技术问题是商务配置问题。流程是先向运营商申请定向流量套餐提供平台服务器的IP和域名运营商在白名单里配置。设备侧APN要设置成运营商指定的定向APN。这里有个坑定向流量通常只对特定端口生效。比如运营商只放行80和443那你的MQTT端口1883和TCP流端口就可能在计费范围内。解决办法是把MQTT over WebSocket走443TCP流也走443端口复用。这个要和运营商确认清楚。2.4 485设备与Modbus TCP的接入热词里出现了“mqtt如何给485设备发指令”和“modbus tcp”这其实是同一个需求的两面。485设备本身是串口设备要接入平台需要经过网关转换。我的做法是485设备 - Modbus RTU - 4G网关转Modbus TCP- 平台。平台侧用MQTT下发指令网关收到后转成Modbus TCP请求发给485设备读到的数据再通过MQTT上报。# 平台侧下发Modbus读取指令 import paho.mqtt.client as mqtt import json client mqtt.Client() client.connect(broker.local, 1883, 60) cmd { cmd: modbus_read, slave: 1, func: 3, addr: 0, count: 10 } client.publish(/broadcast/dev001/cmd, json.dumps(cmd))注意西门子PLC200系列不支持标准Modbus TCP需要加网关转换。FX5U倒是原生支持Modbus TCP主站功能可以直接对接。选型时一定要确认设备协议支持情况。3. 实操过程与核心环节实现3.1 MQTT服务器搭建我用的是EMQX开源版部署在Linux服务器上。步骤# 下载并安装 wget https://www.emqx.com/zh/downloads/broker/5.0/emqx-5.0.0-ubuntu20.04-amd64.deb sudo dpkg -i emqx-5.0.0-ubuntu20.04-amd64.deb # 启动 sudo systemctl start emqx # 开放端口 sudo ufw allow 1883 sudo ufw allow 8083配置要点开启匿名访问要谨慎生产环境必须开认证。我用的是用户名密码ACL每个设备一个账号只能发布和订阅自己的主题。3.2 设备端MQTT客户端实现设备端用ESP32或4G模组内置的MQTT库。以ESP01S为例它本身是WiFi模组但可以通过串口接4G模组实现4G通信。核心逻辑// 伪代码 mqtt_connect(broker, deviceId, token); mqtt_subscribe(/broadcast/ deviceId /cmd); while(1) { if (mqtt_msg_arrived()) { parse_cmd(); execute(); report_state(); } if (timeout()) { send_heartbeat(); } }实操心得设备端一定要做断线重连本地缓存。网络抖动时指令可能丢失本地缓存最近几条指令重连后补报状态避免平台和设备状态不一致。3.3 TCP流通道建立与音频传输音频传输的流程平台收到广播指令 - 从存储拉取音频文件 - 通过TCP通道分片发送 - 设备端接收并解码播放。分片大小我设的是1024字节每片带序号设备端按序重组。丢包时设备端发NACK平台重传。这个机制比纯UDP可靠比纯TCP灵活。# 平台侧发送音频分片 def send_audio(sock, audio_data): seq 0 for i in range(0, len(audio_data), 1024): chunk audio_data[i:i1024] packet struct.pack(!HIH, 0xAA55, len(chunk), seq) chunk sock.send(packet) seq 13.4 监控视频流的接入监控视频走RTSP或私有协议平台侧用流媒体服务器如ZLMediaKit拉流并转封装成HLS或WebRTC供Web端播放。设备侧只需要把视频流推到平台指定的TCP端口即可。这里的关键是带宽控制。4G上行带宽有限视频码率不能太高。我一般设720P、1Mbps够看清现场就行。如果要做AI分析可以在平台侧抽帧不要传原始高码流。3.5 平台联动逻辑实现联动的核心是事件驱动。监控侧检测到异常比如移动侦测发一个MQTT事件到/monitor/dev002/event平台订阅到这个事件后自动向广播设备发/broadcast/dev001/cmd播放告警音频。def on_message(client, userdata, msg): if msg.topic.endswith(/event): event json.loads(msg.payload) if event[type] motion: # 触发广播 client.publish(/broadcast/dev001/cmd, json.dumps({cmd: play, url: ALARM_AUDIO}))4. 常见问题与排查技巧实录4.1 MQTT连接不稳定排查设备频繁掉线先看三个地方网络信号、心跳间隔、Broker负载。现象可能原因排查方法频繁重连信号弱查设备RSSI低于-100dBm就不稳连接超时心跳太长缩短keepalive到60秒Broker拒绝认证失败查ACL配置和账号密码大量设备掉线Broker过载查CPU和连接数考虑集群踩过的坑EMQX默认最大连接数有限制设备多了要改配置。还有如果用了NATTCP长连接可能被运营商回收心跳间隔要小于NAT超时时间一般设60秒比较稳。4.2 TCP粘包与断包处理这是TCP编程的经典问题。我的处理方式是定长头变长体先读固定长度的头从头里解析出body长度再读body。如果一次读到的数据不够就缓存起来等下次。// 读包逻辑 while (1) { n recv(sock, buf offset, need - offset, 0); if (n 0) break; offset n; if (offset HEADER_LEN) { parse_header(buf, body_len); if (offset HEADER_LEN body_len) { process_packet(buf); // 移动剩余数据 memmove(buf, buf HEADER_LEN body_len, offset - HEADER_LEN - body_len); offset - HEADER_LEN body_len; } } }4.3 免流量失效问题设备跑了一段时间发现流量超标排查思路确认设备APN是否设置正确有没有走定向APN。确认平台服务器IP是否在白名单内有没有换过IP。确认端口是否在放行范围内非放行端口的流量会计费。检查设备有没有后台偷偷跑其他流量比如OTA升级走了公网。独家技巧在设备侧加一个流量统计模块每天上报一次流量使用情况平台侧做趋势分析异常时提前告警。这个比等运营商账单出来再查要主动得多。4.4 Modbus TCP通信失败排查热词里提到“西门子PLC200不能实现modbus tcp协议通讯”这确实是常见问题。PLC200只有串口要接Modbus TCP必须加网关。排查步骤确认网关的串口参数波特率、数据位、停止位、校验和PLC一致。确认Modbus从站地址正确。用Modbus Poll工具先直连网关测试排除平台侧问题。检查功能码是否支持有些设备只支持03和06。4.5 音频播放延迟与卡顿音频卡顿一般是网络抖动或分片重传导致。优化方向增大设备端缓冲区预缓冲2秒再播放。降低分片大小减少单次传输时间。开启前向纠错FEC牺牲一点带宽换流畅度。平台侧做码率自适应网络差时降码率。5. 部署与运维经验5.1 服务器配置建议初期设备量在1000台以内一台4核8G的云服务器足够。EMQX和TCP网关可以同机部署但流媒体服务器建议分开因为视频转发吃带宽。组件配置说明EMQX2核4G支持5000连接TCP网关2核4G支持2000长连接流媒体4核8G按路数扩展数据库2核4GMySQL Redis5.2 监控与告警必须监控的指标在线设备数、消息吞吐量、TCP连接数、流量使用、服务器负载。我用Prometheus Grafana做可视化阈值告警走钉钉或邮件。实操心得设备在线率是最重要的指标。我设的是低于95%就告警因为在线率下降往往意味着网络或平台出了问题早发现早处理。5.3 固件OTA升级设备多了之后OTA是个刚需。我的做法是平台通过MQTT下发升级指令设备从指定的HTTP地址下载固件下载完成后校验MD5再重启切换分区。升级过程要支持断点续传和回滚避免变砖。6. 后续扩展方向这套平台跑通之后扩展空间很大。比如接入AI分析在监控侧做人员检测、安全帽识别检测到异常自动触发广播。再比如接入更多类型的485传感器把温湿度、PM2.5等数据也纳入平台做成一个综合的物联网管理平台。协议层面后续可以考虑MQTT over QUIC在弱网环境下比TCP更稳。不过目前4G网络下TCP已经够用等设备量再上一个量级再考虑。我在实际部署中发现最容易被低估的是设备端的稳定性。平台做得再好设备端一个内存泄漏就能让整个系统瘫痪。所以设备端代码一定要做内存检查和看门狗这是血泪教训。