这两年聊设备接入几乎绕不开 MQTT而每回聊到工控和内网项目“MQTT 到底是私有化部署还是直接用阿里云/腾讯云 IoT 平台”总要被翻出来争一轮。搞 IT 的觉得云平台真香省运维、免部署搞工控的老法师觉得数据不出内网才是底线。两边其实都有道理但选型从来不能拍脑袋。这篇我不给你贴概念直接把两条路线的部署细节、成本账、常见坑全部摊开结合我在设备接入项目里的实操经验整理成一份能在现场直接用的选型指南。1. 为什么工控内网场景几乎绕不开 MQTT1.1 现场设备接入MQTT 凭什么是默认选项做工业现场的人应该都有体会不管是 PLC、DTU、采集网关还是传感器盒子厂商说明书里的联网协议基本都默认支持 MQTT。不是大家跟风而是 MQTT 这个协议天生就适合设备接入这种场景。先说体积。MQTT 报文头最小只有 2 个字节跑在 4G 模组、串口 DTU、甚至 LoRa 网关上都没压力。对比 HTTP 那种动不动几百字节的请求头在窄带环境里差距非常明显。其次是发布/订阅模型它把“谁产生数据”和“谁消费数据”彻底解耦一个 PLC 的数据往上发一次中控大屏、实时数据库、手机告警可以同时订阅消费互不干扰。这在工控现场太实用了因为同一份数据经常要喂给不同系统。还有一个关键点是双向通信。HTTP 轮询是设备被动的“被拉”而 MQTT 是设备主动维持连接、随时可以“被推”。下发电机的启停指令、远程修改采集频率这类控制类消息在 MQTT 里就是一条带 QoS 的 publish实时性和可靠性都比轮询高一个量级。1.2 四个决定选型的核心概念聊选型之前先把协议里四个最影响决策的概念说清楚后面讲坑的时候全靠它们。Topic 结构。消息按主题分发典型的分层设计是plant/{车间}/{产线}/{设备}/{数据类型}例如plant/workshop1/line2/pump-03/temperature。订阅方可以用通配符单层和#多层批量接收。这套结构和文件系统路径很像规划得好不好直接影响 ACL 权限控制和后续数据清洗的难度。QoS 等级。0、1、2 三个级别我习惯用快递类比QoS 0 是平信寄出去不管QoS 1 是挂号信没收到会重发但可能重复QoS 2 是签收加回执保证不重不丢但要来回确认开销最大。工控场景里上行遥测用 QoS 1 就够了下行控制命令也是 QoS 1 加业务层幂等QoS 2 用得极少。遗嘱消息LWT。客户端断开时 Broker 代发一条预设消息告诉别人“这台设备掉线了”。工控场景里这是宝贝设备异常断电、网络闪断其他系统立刻能感知状态触发报警或降级策略。保留消息Retain。Broker 把某 Topic 的最后一条消息存下来新订阅者一上来立刻能拿到当前最新状态不需要等下一次上报。搞设备状态同步时非常好用。1.3 工控内网比公网更需要 MQTT 的原因公网场景下选 MQTT更多是为了省流量和做消息分发但在工控内网里MQTT 的价值要再深一层。首先是时延可控。内网自建 Broker 的消息流转一般在 10~50ms 这个量级而设备走公网怎么也要 100ms 起步碰上网络抖动几百毫秒也正常。做实时数据展示可能差别不大但要做设备联动、联锁控制这几十毫秒就是天壤之别。其次是断网可用。很多工厂的网络并没有想象中稳定车间光纤被挖断、核心交换机升级都是会碰到的事。设备数据先落到本地 Broker等网络恢复之后再补传这套“本地闭环云端同步”的架构只有私有化部署才能做得顺。再说数据不出内网这条硬约束。很多项目方对生产数据的安全性极其敏感设备参数、工艺配方这些数据一旦离开车间哪怕只是经过公网中转审计和安全管理都会变得很麻烦。自建 Broker 让数据物理上留在内网整个系统边界清晰问题好排查责任也清楚。2. 私有化部署自建 Broker 的完整推演2.1 第一步Broker 怎么选市面上 MQTT Broker 不少但真正在工控内网里用得多的就那么几款。我整理了一个选型对照表按自己的项目规模对号入座就行。Broker定位单机规模参考适合场景备注EMQX全功能、集群成熟数万连接无压力中型以上工厂、需要高可用有开源版Dashboard 好用规则引擎强Mosquitto轻量、传统百台左右小型产线、简单网关内存占用小但配置全靠文件调试稍麻烦NanoMQ边缘专用千台以内嵌入式设备、边缘盒子主打低资源消耗适合放网关里VerneMQ集群强中大规模有硬性多节点需求的场景社区活跃度一般资料少一点HiveMQ商业版大规模企业级、需要商业支持贵工控内网很少用我给个比较保守的建议一般工控内网项目首选 EMQX 开源版理由很朴素——功能全、教程多、Dashboard 图形界面排查问题直观遇到解决不了的问题一搜一大把答案。如果是那种总共五六十台设备、数据量也不大的小产线Mosquitto 或者 NanoMQ 完全够用一台树莓派或者工控盒子就能跑没必要上重家伙。2.2 最小可用的部署配置不管选哪个 Broker我建议都用 Docker 方式部署升级回滚都方便。以 EMQX 5.x 为例一个最小可用的docker-compose.yml长这样services: emqx: image: emqx/emqx:5.8.3 container_name: emqx restart: always ports: - 1883:1883 # MQTT 普通端口 - 8883:8883 # MQTT TLS 端口 - 8083:8083 # WebSocket 端口 - 18083:18083 # Dashboard 管理界面 environment: EMQX_DASHBOARD__DEFAULT_PASSWORD: 换成强密码 volumes: - emqx-data:/opt/emqx/data - emqx-etc:/opt/emqx/etc volumes: emqx-data: emqx-etc:起来之后浏览器访问http://内网IP:18083初始账号admin密码就是环境变量里设置的那个。先别急着接设备把两步做了一是改默认密码二是只监听内网网卡。Docker 里配置EMQX_LISTENERS__TCP__DEFAULT__BIND: 192.168.1.10:1883避免 Broker 暴露在非预期网络里。生产环境我建议把 1883 纯文本端口关掉强制走 8883 TLS 端口。工控设备老的不在少数先测试确认设备固件支持 TLS 再关不然现场会有一堆设备连不上来。2.3 部署前先算账连接数、内存与消息量选 Broker 配置之前先做一道简单的算术题。连接数与内存一条空闲 MQTT 连接在 EMQX 里大约占用 10~20KB 内存活跃收发消息时因为要开缓冲区可能涨到 100~200KB。工程上我一般按“最大连接数 × 100KB × 2 倍余量”估算内存。5000 台设备预留 1GB 内存就非常稳了2 核 4G 的小服务器轻松跑。消息量与带宽举一个真实场景一条产线 200 台设备每台每 5 秒上报一条遥测消息单条消息按 200 字节算。一天的条数是200 × 86400 ÷ 5 ≈ 346 万条一天的原始流量是346万 × 200B ≈ 692MB。这个量级对本地网络完全不是事但如果走云平台按消息条数计费就得好好掂量掂量了。那什么时候需要集群我的经验判断是连接数超过 2 万或者消息转发速率持续超过每秒 5000 条再考虑多节点。普通工厂自建场景单机 EMQX 加双机热备已经能覆盖 95% 的需求不要一上来就上集群运维复杂度会成倍增加。2.4 内网部署的安全细节不能偷懒很多工控工程师觉得“内网嘛安全无所谓”这个想法最危险。内网不等于绝对安全产线上一个 U 盘、一台临时接入的笔记本都可能成为问题源头。私有化部署至少要落实四件事。第一认证必须开。最简单的用户名密码认证每一台设备单独账号不要所有设备用一个共用的账号不然出了问题没法追踪。第二ACL 权限控制。每个账号只能发布和订阅自己相关的 Topic比如设备plc-01只允许往plant/plc-01/data发消息、只允许订阅plant/plc-01/cmd防止设备串线导致误操作。第三传输加密。用自签 CA 给内网 Broker 签 TLS 证书设备端配置好 CA 根证书做校验。自签证书有效期建议设 5 年或者 10 年后面我会专门讲这个坑。第四定期备份。Broker 的配置文件、证书、Dashboard 账号体系都要纳入备份否则一台机器挂掉重建很痛苦。3. 阿里云/腾讯云 IoT云端方案的真实优势与边界3.1 云平台提供的是一整套能力阿里云 IoT 平台和腾讯云 IoT Explorer 这类产品本质上已经不是“只给你一个 MQTT Broker”这么简单了它们提供的是从设备接入到数据应用的全链路服务。设备接入层面平台内置了设备认证体系每台设备分配三元组或者证书接入即完成身份校验不用自己维护账号库。设备管理层面物模型把设备抽象成属性、事件、服务三个维度数据有了标准格式上层应用开发效率高很多。规则引擎是另一个很实用能力——数据从设备进来规则引擎可以直接转存到数据库、触发函数计算、推送告警通知等于把“数据接入 ETL 业务触发”串成了一条流水线。还有两个自建方案里要花大力气才能实现的东西OTA 固件升级和在线调试。设备端需要远程升级云平台开箱即用设备一直连不上、数据不对云平台自带在线日志和调试工具点开就能看消息流转情况。这些能力如果全自建等于要自己再造一个配套系统工作量不是闹着玩的。3.2 计费成本要自己算清楚云平台的费用结构通常包含连接费用、消息费用、实例费用或包年包月几个部分具体价格以官网计费页为准但量级是可以自己估的。接着用前面那条产线的数据200 台设备一天 346 万条消息一个月就是一亿条出头。按消息条数计费这笔费用单独拿出来就已经不算小了再加上设备连接数费用、实例费用、可能的规则引擎调用费用一年下来是一笔非常清晰、持续增长的运营成本。自建方案一次性买台服务器、电费和带宽几乎可以忽略。所以我的建议是做成本对比时把“三年总拥有成本”拉出来算而不是只比第一个月。设备量小、系统规模可控的项目自建通常更划算设备量很大、需要在多个地域快速铺开的项目云平台的弹性优势会体现出来自己扛集群的运维成本反而更高。3.3 云平台的边界在哪里说完优势也得泼一盆冷水。云平台有几个先天约束在工控内网场景里特别容易踩。最硬的约束是设备必须能访问公网。如果车间是隔离内网或者安全策略不允许设备直接出外网云平台这条路基本走不通。其次是时延不稳定公网链路天然有抖动做实时数据展示勉强可以做设备联锁控制风险很大。然后是数据归属问题业务数据存在云厂商那里每次要导数据、看报表都要走平台接口权限和数据边界要提前谈清楚。最后是协议灵活性受限平台对 Topic 结构、消息格式有自己的规范虽然是标准 MQTT但加了物模型这些概念之后底层消息流转不能完全按自己的想法折腾。所以云平台不是“不好”而是不适合所有场景。它适合的是设备分布广、网络条件好、对数据实时性要求没那么苛刻、又希望快速搭建的应用场景不适合的是封闭内网、强实时控制、数据安全性要求极高的场景。4. 核心维度选型对比一张表讲透4.1 八个维度对比表两个方案放在一起比较我习惯用下面这张表基本上把决策时关心的点都覆盖到了。维度私有化部署自建 Broker阿里云/腾讯云 IoT初始部署成本一台服务器搞定几千到几万基本为零按量/包年计费持续运营成本电费、带宽、维护人力随连接数和消息量持续增长消息时延内网 10~50ms极稳定公网 100ms 起步有抖动断网可用性内网独立运行断外网不影响设备断网即失联本地无闭环数据可控性数据物理留在内网数据在云厂商侧受平台规则约束弹性扩展需自己扩机器、组集群平台侧弹性扩容方便配套服务需要自己搭 OTA、告警、监控OTA、规则引擎、告警开箱即用维护门槛需要懂 Broker 运维主要学习平台控制台和规范这张表不是用来证明谁好谁坏的而是帮你把需求里的矛盾点摊开。你会发现工控内网项目里真正致命的需求是“数据可控”和“断网可用”这两项恰恰是自建方案的强项而云平台的“配套服务”“弹性扩展”在设备量爆发时才真正值钱。4.2 三条决策判断题如果看完表还是拿不定主意那就按下面三个问题依次过一遍第一业务数据能不能出内网这是所有工控项目的第一道门槛客户方明确说“生产数据不能出车间”那就不用再往下纠结了直接走私有化部署路线。第二现场需要断网可用吗如果设备联动、本地监控要求网络断了系统还要继续跑也必须自建 Broker 做本地闭环云平台解决不了这个需求。第三设备分布范围和数量级是多少几十台设备集中在一个厂区自建最省上千台设备分布在全国多个城市又允许走公网那云平台的统一管理优势就很明显了。三个问题走完方案基本上浮出水面。我见过不少项目就是在这三个问题上反反复复最后发现其实是需求没想清楚而不是技术方案的问题。4.3 三类典型企业画像的推荐路径根据我接触过的项目工控内网场景大概能归成三类画像第一类小型产线几十台设备预算有限没有专职 IT。这种我一般推荐轻量自建一台工控机跑 Mosquitto 或者 NanoMQ数据本地存储加一个简单的看板就够。上云平台反而要学习物模型、规则引擎学习成本比自建还高。第二类中型工厂几百到几千台设备有基本的 IT 力量数据安全要求较高。推荐 EMQX 双机热备构成本地集群所有实时数据在本地闭环如果总部需要远程查看报表再通过桥接把汇总数据同步到云平台两边各取所长。第三类集团型多工厂工厂分散在各地需要总部集中监控、统一运维。这种我更倾向“边缘自建 云端汇聚”的混合架构每个工厂本地部署 Broker 保证产线稳定运行集团云平台统一接收各厂的关键数据和告警。混合架构现在是这类项目的主流解法。5. 工控与内网场景的三种实战路线5.1 路线A完全隔离内网断网也要可用这是最纯粹的工控场景车间是物理隔离网络不允许任何设备出公网甚至厂区内部网络也不稳定要求核心系统在任何情况下都要能跑。这种场景的架构核心是“本地闭环”。Broker 部署在产线本地服务器设备数据和 Broker 之间走内网固定 IP。所有生产控制逻辑都在本地处理云端可以有但只承担“事后同步数据”的角色不能依赖它做实时控制。为了实现“断网可用”Broker 本身要做双机热备一台主节点挂了另一台秒级接管设备数据要有本地持久化至少保留 30 天以上方便事后追溯。实施细节上有几个容易忽略的地方所有设备用静态 IP 或 DHCP 保留地址避免重启后 IP 变化导致连不上Broker 所在端口只在核心 VLAN 内开放每次变更配置前先备份变更后留观察期。这套路线的核心原则就一句话把 Broker 当作跟 PLC 一样重要的工业设备来对待而不是当作普通的 IT 服务。5.2 路线B内网为主窄带同步上云很多工厂是“内网生产系统 总部远程管理”的双层结构。产线数据不能全量上云但总部需要每天的产量报表、设备状态、告警信息。这种场景建议在本地部署 EMQX 作为主 Broker生产数据全部进本地。同时在本地部署一个数据同步服务定时把汇总后的数据通过窄带通道批量推送至云端。同步策略上注意三点一是批量压缩再传输不要逐条实时推送二是断网期间数据先落本地队列网络恢复按时间戳顺序补传防止乱序三是上行同步用 QoS 1确保至少送达一次。很多实施团队在这里犯的一个错误是试图用“本地 Broker 桥接到云端 Broker”的方式做实时同步。实际上工厂带宽有限全量实时同步既浪费流量云端的 Broker 也扛不住这么高频的写入。数据先做聚合比如 5 分钟粒度汇总后再同步流量能下降一个数量级云端压力也小得多。5.3 路线C设备直连云端设备直连云平台的方案不是不能用关键是要设计好网络异常下的行为。4G 信号不稳定、工厂宽带断线都会导致设备频繁掉线重连如果设备端逻辑没做好云平台上看到的是一堆“上线、掉线”的抖动记录数据断档严重。设备侧的底线设计包括三块断网缓存——本地 SD 卡或 Flash 里开一个环形缓冲区网络恢复后按时间戳补报心跳和重连退避——不要做成上线失败后疯狂重连指数退避加随机抖动才是正确姿势本地降级逻辑——网络断开时设备按最后配置的策略继续工作不依赖远程指令。云端侧也要配合比如设备影子功能云端保存设备最新的期望状态设备重新连上后自动拉取弥补离线期间的指令缺口。这类方案适合监控类业务适合可以容忍分钟级延迟的报表类应用凡是涉及实时控制的我都不建议走这条路。5.4 桥接链路的关键配置清单不管是路线 B 还是混合架构都会用到“本地 Broker 到云 Broker 的桥接”以 EMQX 为例梳理一份关键配置清单。在 EMQX Dashboard 的“数据集成 → Bridge”里创建一个 MQTT Bridge需要关注四个参数远端地址填云端 IoT 平台的 MQTT 接入地址端口按平台要求填 1883 或 8883认证信息填云端为这台桥接单独创建的一个设备账号不要拿数据设备的账号复用Topic 映射本地主题映射到云端主题比如本地factory/{site}/data映射为云端cloud/{site}/data消息 QoS 设 1明确要求“至少一次”不丢消息。桥接最常见的坑是只做了单向转发本地设备发到云端的数据能看到但云端下发的控制指令回不到本地设备。创建 Bridge 时务必检查“双向”模式是否开启同时本地 Broker 要把云端下行 Topic 通过 ACL 放行。还有一点桥接链路一定要配置离线消息缓存否则本地 Broker 和云端之间的网络断开一两分钟期间的消息就丢了排障时会把人气死。6. 常见问题与排查速查表6.1 高频问题实录做 MQTT 接入这几年现场问题翻来覆去就那么几类整理成一个速查表至少能覆盖八成故障。症状常见原因排查手段设备一直连不上 Broker网络不通、端口未开放、认证失败ping和telnet IP 1883验证连通性看 Broker 日志中的拒绝原因设备在线但收不到消息订阅 Topic 写错、ACL 拒绝、QoS 不匹配用mosquitto_sub -v -t #在 Broker 侧抓全局消息确认消息真的进来了离线期间的消息全丢clean_session设成了 true或 Session 过期时间太短客户端改为 false并设置合理的 Session Expiry Interval命令重复执行多次QoS 1 重复投递应用层没做幂等每条命令带唯一消息 ID接收方按 ID 去重设备掉线但没有任何通知没配置遗嘱消息或遗嘱 Topic 没被订阅检查 LWT 配置确认监控端订阅了遗嘱 Topic云上数据延迟特别大公网链路问题、桥接 QoS 配置过低、云端 Broker 负载高ping 测 RTT检查桥接队列积压情况这里想多说一个遗嘱消息误发的经典场景。有一次现场排查发现系统频繁告警“设备离线”但设备明明还在正常运行。后来查到是 Broker 升级重启时没等设备重连就先把所有离线遗嘱消息发了出来监控端收到之后立刻报警。解决方式也简单Broker 启动后加一个预热延迟等设备批量重连完成后再正式服务或者监控端做告警冗余只有连续多次收到离线遗嘱才真正触发告警。6.2 排查工具箱与思路排查 MQTT 问题工具不需要多顺手就行。命令行里mosquitto_sub和mosquitto_pub是定位问题最快的两个命令一个订阅全局 Topic 看消息流转一个手动发布消息测试链路。图形界面的 MQTTX 适合模拟设备和查看消息内容比命令行直观。EMQX 自带的 Dashboard 里可以实时看连接数、订阅关系、消息速率排障第一步就是打开它看基础指标。排查顺序我的习惯是从下往上四层过一遍。第一层网络确认 IP 能通、端口能连第二层协议确认 MQTT 握手成功、认证通过、ACL 放行第三层会话确认 Session 存在、订阅关系正确第四层应用确认消息 payload 格式和业务逻辑没问题。很多问题查到最后都是 ACL 配错了或者 Topic 字符串少了个斜杠这种低级错误但如果没有按层次排查的习惯很容易在业务代码里找半天找不到根因。工控内网还有一个特殊点很多现场工程师习惯用固定的 IP 和端口改动网络配置阻力很大。调试阶段尽量先跑通 1883 端口确认业务稳定后再切换到 TLS 8883减少联调阶段的变量。全套方案落地之后再让现场工程师签一份“网络配置变更确认单”避免后续有人改交换机配置导致设备大面积掉线。结尾落到具体决策上我的个人体会是第一步永远不是选技术而是画一张数据流向图把所有数据分成“必须在本地闭环”和“可以出内网”两堆再决定走哪条路线。这个动作做完选型其实已经结束一半了。还有一个小技巧想分享给大家不管最终选什么方案正式上线前先在现场用 MQTTX 模拟一批设备跑上 48 小时观察消息时延、Broker 内存曲线和网络抖动情况。这一步花不了多少时间但能提前暴露桥接丢消息、内存泄漏、Topic 设计不合理这些问题比上线之后被产线停机的电话叫醒要舒服太多。