一个 broker，两种模式：EMQX 原生支持实时 MQTT 发布/订阅和持久化消息队列

架构师的两难困境

每位物联网架构师都面临着一个相同的根本性挑战：系统需要同时处理两种截然不同的消息模式。

一方面，你需要即时的发布/订阅模式来实现物联网设备的连接： 例如：实时仪表板需要显示车辆的即时位置，操作员需要观看生产线指标每秒更新，以及传感器检测到异常时需要即时触发警报。

另一方面，你需要持久可靠的消息队列来实现企业级系统集成： 确保每笔交易都能被处理、每个命令最终都能到达目的地，以及即使消费者离线，每个分析任务也能接收到完整的数据集。

多年来，这种功能上的二元性迫使架构师们做出妥协： 搭建一个 MQTT broker 负责边缘连接，再配合独立的企业级消息队列来保证后端可靠性。但最终结果是得到一个构建复杂、运行昂贵、维护艰难的架构。

但如果有一个统一的平台能无缝处理这两种模式呢？让您不必在实时性和可靠性之间做选择。

让我们一同探索 EMQX 的统一架构如何破解这个困扰业界数十年的难题。

旧模式：隔离架构（EMQX + 外部消息队列）

典型设置

如今，大多数物联网系统看起来像这样：

工作流程

1. 设备连接：设备使用 MQTT 协议连接到 EMQX 集群。
2. 实时分发：实时客户端直接订阅 EMQX 主题，以获取即时通知。
3. 数据转发：EMQX 的规则引擎或桥接功能将消息转发到外部消息队列（如 RabbitMQ、Kafka 等）。
4. 后端消费：后端应用使用 AMQP、Kafka 协议或专有 API 从该外部消息队列中消费数据。

听起来合情合理？理论上确实如此。但在实际应用中，这种架构会带来诸多严峻问题。

实际成本：从一个具体案例分析

我们来考虑一家正在大规模运营的车队管理公司：

基础设施配置：

• EMQX 集群：3 个节点处理 5 万辆联网车辆
• Kafka 集群：5 个节点处理行程数据和命令
• 总共需要管理、修补和监控 8 台服务器

隐性成本：

• 每年额外投入 4.5 万美元用于云基础设施（Kafka 集群 + 集成层）
• 需要 2 个专业团队（MQTT 专家 + Kafka 工程师）维护
• 由于桥接开销，平均消息延迟增加了 45 毫秒。
• 桥接服务静默故障导致三天服务中断，消息已发布到 EMQX 但从未到达 Kafka，导致计费差异。

这并非企业遇到的最糟糕的情况，而是正常经营中很常见的现象：高昂的隐性开支和运维成本带来极大的运营负担。

为什么隔离式架构会失败

这种将 MQTT broker 与外部消息队列生硬拼凑的隔离架构，看似实现了功能，但实际上带来了诸多问题：

架构复杂性：

系统需要部署、配置和扩展两套截然不同的基础设施。每个系统都有自己独立的集群管理方式、数据复制策略和故障模式。这要求您的运维团队必须同时具备两种系统的专业知识。

运营开销：

您需要维护两套独立的监控仪表盘、告警系统和备份流程。当凌晨 3 点系统发生故障时，运维人员需要迅速判断问题源头：MQTT broker、桥接服务还是外部消息队列。这极大地增加了故障排查的难度和耗时。

延迟和故障点

每一条需要后端处理的消息都必须经过一连串的跳转，增加了多个不必要的环节：

1. EMQX → 桥接服务：涉及网络跳转和数据序列化。
2. 桥接 → 外部消息队列：涉及协议转换和另一次网络跳转。
3. 外部消息队列 → 消费者：涉及另一种协议和最后一次网络跳转。

每次跳转都会增加延迟（通常总计 30-50 毫秒），并造成潜在的故障点。

协议不匹配：

边缘设备开发人员使用 MQTT 客户端，而后端开发者则面向 Kafka 消费者或 AMQP 客户端。双方需要维护不同的 API、不同的编程思维模型和不同的调试工具。培训新工程师需要数月而非数周的时间。

成本累积

基础设施成本会不断叠加：您需要支付 MQTT 基础设施 + 外部消息队列基础设施 + 集成层的费用，以及管理这三者带来的巨大运营开销。

新模式：基于 EMQX 的统一架构

简化架构

使用 EMQX 的原生消息队列功能后，同一套系统看起来是这样的：

区别显而易见：一个系统，两种消费模式，零外部依赖。

核心概念：主题到队列的映射

EMQX 的创新之处在于它能够通过智能的主题到队列映射，在单个 Broker 中处理实时和异步消息传递。

工作原理：

当您在 EMQX 中创建一个消息队列时，需要将其绑定到一个主题过滤器（包括通配符）。此时，所有发布到匹配主题的消息将流经两条并行路径：

路径一：实时发布/订阅

任何订阅该主题的客户端都会立即收到消息，就像标准的 MQTT 一样。您的仪表板、告警系统和实时监控器将像以前一样工作。

路径二：持久队列（新功能）

消息会同时持久化到持久存储中，并提供给队列消费者使用。后端服务订阅 $q/{topic-filter} 而非原始主题，从而获得以下优势：

• 即使消费者离线，也能保证送达。
• 跨多个消费者实例进行负载均衡
• 偏移跟踪功能，让消费者可以从上次中断的地方继续消费
• 灵活的调度策略（轮询、随机、最少未处理数）

通配符映射：架构倍增

EMQX 统一架构的真正强大之处在于：单个队列可以通过通配符模式聚合来自数千个主题的消息。

它解决的问题：

想象一下，您正在管理一座拥有 10,000 个交通传感器的智慧城市，每个传感器都会发布到自己的主题上：

• sensor/001/data
• sensor/002/data
• ...
• sensor/10000/data

使用 EMQX 消息队列，一个队列映射到 $q/sensor/+/data 即可处理所有消息。

架构对比

将两种架构并置比较时，统一平台的优势是显而易见的。

特征	旧模式：隔离架构	新模式：EMQX 统一架构
系统管理	复杂：需要部署、监控和扩展两个不同的分布式系统。	简化：仅需管理一个统一的系统
基础设施成本	高：服务器占用空间、监控工具和维护成本翻倍。	降低：整合的基础设施，降低总体拥有成本。
数据延迟	高：会增加一次网络跳转，并在桥接端产生额外的处理延迟。	低：主题和队列之间直接分发。
开发复杂性	高：需要掌握 MQTT、AMQP 等多种协议和 SDK 的知识。	低：实时和队列客户端都使用单一 MQTT 协议。
系统弹性/韧性	较低：故障点更多（桥接、外部消息队列）。	更高：活动部件更少，数据路径集成度更高。
安全/访问控制列表	需在两套系统中配置重复的安全策略。	单一的策略配置界面。
可观测性	指标和追踪分散在多个系统中。	统一的指标/追踪视图。
更新管理	需要协调两套系统的发布和升级流程。	统一且连贯的升级和发布生命周期。

统一架构不仅更简单，而且从根本上来说更高效、更可靠、更具成本效益。

基于外部消息队列的迁移说明

您不必大刀阔斧的改革，而是采取渐进式、低风险的迁移路径：

首先进行镜像：

• 保留您现有的 Kafka/RabbitMQ 消费者。
• 在 EMQX 中，声明具有相同主题过滤器的队列。
• 将一部分消费者指向 $q/... 队列地址。

证明服务水平目标：

• 比较通过旧路径和新路径传输的消息的延迟、错误率和运营负载。
• 验证新架构能够满足或超越您的服务水平目标。

逐步淘汰桥接器：

随着服务切换到 $q/... 逐步停用原有的代理间连接器及其背后的外部消息队列基础设施。

提示：首先选择已经使用 MQTT 作为控制路径的服务；这样可以直接接入新的队列地址，最大限度地减少 SDK 的变更。

保留 Kafka 的场景与整合策略

有些团队将 Kafka 用于长期数据保留、批量分析或数据湖摄取等场景。在这种情况下，应将其视为一个分析边界，而不是每一个设备消息都必须依赖的运行时依赖项。

• 使用 EMQX 处理面向设备的发布/订阅 + 消息队列功能，实现低延迟、统一认证。
• 将经过筛选和整理的数据流导出到 Kafka，用于归档和批处理任务。
• 让应用程序始终使用 MQTT 协议，避免双协议的复杂性。

通过这种方式，物联网系统的运行核心就保留在一个 broker 内部，而分析任务则交给 Kafka 负责。

不只是 Broker，更是统一的消息平台

多年来，架构师们不得不做出取舍：要么选择轻量级的边缘 MQTT broker，要么选择功能强大的后端消息队列。最终的解决方案通常是将两者复杂且成本高昂地集成在一起。

通过原生集成持久化消息队列功能，EMQX 消除了这种问题。它使您能够构建一个更简单、更具成本效益、延迟更低的架构 ，同时不牺牲任何功能或可靠性。

您的开发人员现在可以使用他们已经熟悉的单一 MQTT 协议来构建实时仪表板和高弹性、基于队列的后端服务。这让 EMQX 从领先的 MQTT broker 转变为一个全面的统一消息传递平台，在单个集群中同时满足边缘和企业级需求。

您的物联网架构是否过于复杂？或许是时候统一您的消息传递协议栈了。

联系我们的专家，探讨 EMQX 如何简化您的系统设计。

咨询 EMQ 技术专家

联系我们 →