核心结论

代理负责连接状态和消息路由；身份生命周期、业务规则和长期数据应放在相邻服务中。

MQTT 代理接受客户端连接，通过配置的机制进行认证、执行授权、跟踪订阅和会话，并将发布消息路由到匹配的订阅者。根据产品和配置的不同，它可能还存储保留消息、离线排队消息和在途投递状态。它是消息组件，不是整个物联网平台。

代理存在的意义

没有代理，每个发布者都需要知道并直接连接每个消费者。代理将这些参与方解耦，集中处理主题匹配、投递握手和连接状态。设备可以维持外连，而平台服务按需订阅自己关心的数据流。

集中化同时也制造了关键依赖。代理必须保护租户边界、可预测地恢复会话，并防止过载将一个嘈杂客户端的问题放大为整个设备群的故障。

工作原理

客户端建立 MQTT 连接并提交认证凭据。代理将每个连接映射到一个主体，然后根据策略评估发布和订阅操作。每条发布消息都需要进行主题过滤器匹配。共享订阅（如支持）可以将匹配的消息分发给消费组。

会话状态可能包含订阅、在途交互和排队消息。持久状态提升了连续性，但会消耗内存或存储，并在故障切换时产生迁移工作量。离线队列需要设置过期和大小上限。一个断连数月的客户端不应默认收到无限堆积的历史消息。

保留消息按主题存储，发送给新的匹配订阅者。遗嘱消息在连接建立时注册，在非正常断连后按协议行为发布。最大报文大小、接收最大值、主题别名等 MQTT 5 属性会影响流量和资源使用。

集群将连接和路由分散到多个节点，但实现方式各异。有的复制会话状态，有的将请求路由到归属节点，有的在故障切换时会丢失或重建部分状态。负载均衡器、DNS、认证服务、证书服务、持久化存储仍然是代理集群之外的依赖项。

代理解决的问题

代理提供标准 MQTT 连接能力、主题路由、订阅管理、QoS 交互、保留消息、遗嘱和会话行为，可以为设备和服务之间建立一致的消息边界。

托管代理可以减少基础设施运维工作，自建产品则提供更深层的控制能力。但无论哪种选择，都需要理解其限制、故障行为、租户策略、升级路径和退出策略。

代理无法解决的问题

代理不负责设备身份 provisioning、不定义载荷语义、不验证物理结果、不存储分析历史。插件可以增加规则和集成能力，但将业务逻辑放在代理内部，会将产品行为与消息系统的故障域耦合在一起。

QoS 状态不等于端到端的恰好一次业务处理。消费者仍然需要幂等性。一个成功的发布确认，并不能证明每个下游服务都已处理该事件。

适用场景与不适用场景

代理适用于长生命周期的 MQTT 客户端和异步扇出。大文件传输、复杂的请求式 API、长时间运行的工作流和分析存储应交给专门设计的系统。小规模部署可能只需一个精心运维的代理；大规模设备群则可能需要区域隔离、准入控制和明确的灾难恢复方案。

基准测试应使用真实的连接数、TLS、认证、主题长度、订阅扇出、QoS、会话持久化、保留状态、载荷分布和下游消费者。测试节点故障、滚动升级、存储压力、证书过期和重连洪峰——而不只是稳态消息吞吐量。

在到达过载之前就定义好过载行为。准入限制、按主体的配额、发布速率控制、队列过期和负载丢弃策略，应该保护已建立的关键流量，而不是让拒绝变成看不见的数据空洞。

相关技术

MQTT 定义了客户端和代理的行为。TLS 保护传输层并可认证客户端。PKI 和设备身份管理凭据生命周期。ACL 限制主题操作。Sparkplug B 定义工业 MQTT 约定。队列和流处理平台可能位于下游，用于持久化处理和重放。

常见误区

“百万连接等于百万消息吞吐”——混淆了容量维度。“集群意味着零停机”——忽视了状态和依赖项。“保留消息就是数据库”——忽视了历史查询需求。“代理插件是免费集成”——忽视了升级和故障耦合。“加节点解决过载”——当认证或下游存储成为瓶颈时就失效了。

选择代理应基于贴近生产环境的测试和运维方案。决定性问题不是它的最佳基准数据，而是当客户端、节点和依赖项同时故障时，整个系统如何表现。