小微企业自建 MQTT 物联网消息中枢：EMQX 与 Mosquitto 部署、设备认证与主题分层实战

摘要：当车间、门店的设备越来越多，你需要一个统一消息总线把传感、工控与业务系统连起来。本文对比 EMQX 与 Mosquitto 两类开源 MQTT Broker，给出 Docker Compose 部署、设备一机一密认证、TLS 加密与主题分层设计的完整落地方法。

为什么需要一个自建 MQTT Broker

零散设备用 HTTP 各自上报，遇到弱网就丢数据、难联动。MQTT 是物联网事实标准，天生适合低带宽、不稳定网络：支持三种 QoS、保留消息（Retained）、遗嘱（LWT）掉线检测。自建 Broker 相对云平台的优势是数据不出内网、无按量计费、拓扑完全可控，特别适合产线、冷库、门店这类敏感场景。

EMQX 与 Mosquitto 怎么选

Mosquitto：用 C 写的轻量单机 Broker，内存占用极低（几十 MB），适合设备量在千级以内、追求简单稳定的场景；
EMQX：Erlang 写的分布式 Broker，自带 Web 控制台、规则引擎、集群与桥接，适合多厂区、规模化接入；
两者都支持 MQTT 5.0/3.1.1、TLS、WebSocket，部署都可用 Docker Compose。

中小型企业从 Mosquitto 起步最省心，等设备过万或需要规则转发再上 EMQX。

实战：Docker Compose 部署 Mosquitto

先准备配置文件 mosquitto.conf：

listener 1883
allow_anonymous false
password_file /mosquitto/config/pwfile
listener 8883
cafile /mosquitto/certs/ca.crt
certfile /mosquitto/certs/server.crt
keyfile /mosquitto/certs/server.key

用 mosquitto_passwd -c pwfile sensor01 为每个设备创建独立账号。Compose 中把配置、证书、密码文件挂载进去，端口映射 1883（明文，仅内网）与 8883（TLS，可暴露公网）。

实战：EMQX 部署与控制台

EMQX 一条 docker run emqx/emqx 即可启动，默认控制台在 18083（账号 admin/public，首次登录强制改密）。在控制台里创建设备用户名密码、配置 ACL 主题权限，开启 8883 TLS 端口，前端页面还可用 8084 WebSocket 直连。

设备认证与安全防护（关键）

禁用匿名：allow_anonymous false，每台设备发独立账号，做到一机一密；
ACL 最小权限：限制设备只能发布/订阅自己的主题树，例如 sensor01 只能写 factory/a/+/sensor01/#，防止越权控制他人设备；
TLS 双向认证（mTLS）：高安全场景要求设备也带客户端证书，杜绝伪造设备接入；
公网暴露：只开放 8883，前置防火墙白名单，绝不把 1883 裸奔到公网。

主题（Topic）分层设计

糟糕的主题会让系统后期无法维护。推荐分级结构：

企业 / 厂区 / 设备类型 / 设备ID / 测点
例：factory/a/thermo/sensor01/temp

订阅端用通配符 factory/a/+/+/temp 一次性拿某厂区所有温度。要点：

不要把敏感数据（如密码、定位）塞进主题名；
用 Retained 消息让新上线设备立刻拿到最新状态（如空调目标温度）；
用 LWT 遗嘱主题让平台实时感知设备掉线。

桥接与高可用（进阶）

EMQX 支持集群部署与桥接（Bridge），可把分厂 Broker 的数据汇聚到总部，或用规则引擎把消息转存 PostgreSQL、转发到企业微信告警。Mosquitto 也能通过 bridge 配置跨节点同步。

常见坑

ClientID 冲突：两台设备用了相同 ClientID 会互相踢下线，务必全局唯一；
Clean Session 误解：设 false 才保留订阅与离线消息，但积压过多会吃内存；
证书过期：TLS 证书到期会导致大规模掉线，建议监控到期时间并提前轮换；
QoS 与磁盘：QoS1/2 需要 Broker 持久化，高吞吐时注意磁盘 IO 与队列积压。

小结

自建 MQTT 消息中枢是企业物联网的「神经总线」。设备量不大用 Mosquitto 配一机一密和 TLS 即稳妥，规模化用 EMQX 的规则引擎与集群扩展。把主题分层设计好、认证收紧、证书管住，后续接入成百上千台设备也不会乱。