Azure IoT Hub 和 EMQX 是实现大规模设备连接和可靠 IoT 数据传输的两大主流平台。二者均已在生产环境中得到广泛验证，但由于其底层架构截然不同，直接决定了它们的性能、功能以及长期成本构成。
本文将深入对比 Azure IoT Hub 与 EMQX 在架构设计、协议支持、消息路由、扩展性、存储、设备状态、文件传输、安全性及运营限制等方面的差异，帮助架构师与技术决策者理解两个平台的适用场景、核心区别以及大规模部署时可能面临的技术选型问题。
架构基础
在 IoT 系统设计中，架构决定了吞吐量上限和协议灵活性。Azure IoT Hub 和 EMQX 采用了两种完全不同的架构。
分区事件架构 vs. 分布式 Actor 模型
Azure IoT Hub 基于 Azure Event Hubs 构建，采用分区日志架构。传入的遥测数据被写入固定的分区，每个分区在单个消费者组内同一时间只能由一个消费者实例读取。这种设计既带来了稳定的吞吐量，也导致了结构性的读取瓶颈，这一问题在下游系统需要高并发处理能力时尤为明显。此外，其日志储存周期较短，主要为对接 Azure 后端服务而优化。
EMQX 基于 Erlang/OTP Actor 模型构建。每个连接都由一个轻量级进程处理，赋予了 EMQX 极高的并发处理能力和极低的响应延迟。EMQX Enterprise 6.0 进一步引入了基于 RocksDB 的存储引擎，支持在同一集群内实现持久化和异步消息传输。
架构对比
| 特性 | Azure IoT Hub | EMQX Enterprise / Cloud |
|---|---|---|
| 核心模式 | 用于数据摄取与转储的云网关。 | 集发布/订阅与持久化队列于一体的统一消息中间件。 |
| 并发模型 | 连接速率受限（S1：每秒大约 12 次）。 | 受硬件限制，测试支持 1 亿并发连接。 |
| 扩展方式 | 通过预定义规格的容量单元（S1、S2、S3）水平扩展，吞吐量、连接数和存储绑定扩展，容易产生资源浪费。 | 支持细粒度的水平集群扩展。可根据部署模式，独立扩展会话连接、吞吐能力或存储容量。 |
| 数据路径 | 分区日志架构，消费者并发数受分区数量限制。 | 分布式网状路由，无分区数量限制。 |
| 持久化 | 短期日志存储（1 至 7 天）。 | 双引擎（内存 + RocksDB 持久化存储）。 |
| 多租户 | 每个 IoT Hub 实例对应一个租户。 | 单集群内支持基于命名空间的多租户隔离。 |
协议兼容性与 MQTT 标准
Azure IoT Hub 仅将 MQTT 3.1.1 作为兼容层使用，并非功能完整的 Broker，缺失了许多关键的 MQTT 特性。相比之下，EMQX 原生支持 MQTT 3.1、3.1.1 和 5.0，以及 CoAP、LwM2M 及 MQTT-SN 等协议。
协议支持对比
| 特性 | Azure IoT Hub | EMQX Enterprise / Cloud | 技术影响 |
|---|---|---|---|
| MQTT 版本 | 部分支持 3.1.1 | 完整支持 3.1, 3.1.1, 5.0 | Azure 无法使用 MQTT 5 的功能，如主题别名、流控制。 |
| 主题结构 | 固定且以设备为中心 | 完全自定义的层级结构 | EMQX 支持更复杂的工业及多租户场景 |
| QoS 2 | 不支持 | 支持 | 事务性或高完整性 IoT 负载的刚需 |
| 保留消息 | 忽略 | 完整支持且可持久化 | Azure 用户依赖外部数据库查询「最后已知状态」 |
| 共享订阅 | 不支持 | 支持 | 启用工作池和水平负载均衡 |
| MQTT over QUIC | 不支持 | 原生支持 | 提升不稳定网络和移动网络下的连接性能 |
| CoAP、LwM2M、MQTT-SN 等 | 需要外部网关转换 | 原生网关支持 | 资源受限设备可以直接连接 EMQX |
| 心跳间隔 | 最长 1,767 秒 | 最长 65,535 秒 | 更长的间隔有助于降低蜂窝设备的电池消耗 |
消息路由、转换与持久化
路由引擎
Azure IoT Hub 提供基于消息头和内容的简单 SQL 过滤，但不支持消息转换、丰富或动态重塑。复杂逻辑需要依赖 Azure Functions 或 Stream Analytics 实现。
EMQX 内置功能强大的 SQL 规则引擎，提供解码、编码、JSON 重塑、正则匹配、数学运算及调用外部 API 等原生函数。此外，EMQX 6.0 还新增了可视化流设计器，无需编码即可构建数据处理管道。
消息持久化
Azure IoT Hub 提供有限的云到设备（C2D）队列，并依赖 Event Hubs 实现设备到云（D2C）的缓冲。
EMQX 6.0 直接在 Broker 内部集成了持久化队列，支持：
- 离线消息存储
- 高频遥测数据的最后值队列
- 拉取式消费模式
- 竞争消费者模型
这在中小规模架构中，可以有效替代对 Kafka 等外部消息队列的依赖。
扩展性与系统限制
Azure 基于单元的扩展模式
Azure 采用「容量单位」计费，连接速率限制非常严格：
| 单元 | 每日消息上限 | 预计连接速率 |
|---|---|---|
| S1 | 40 万条 | 每秒大约 12 次 |
| S2 | 600 万条 | 每秒大约 120 次 |
| S3 | 3 亿条 | 每秒大约 6000 次 |
由于资源维度是捆绑的，用户往往为了满足连接速率而被迫购买昂贵的超额消息容量。此外，分区数在创建时即固定，限制了后端消费者的并发上限。
EMQX 基于资源的扩展模式
得益于 Erlang Actor 模型，EMQX 支持极高的连接密度。在测试中，单个 23 节点的 EMQX 5 集群支持了 1 亿并发 MQTT 连接。EMQX 的性能主要受限于硬件，没有固定的每日消息上限，添加计算资源即可实现线性扩展。
设备状态、文件传输与远程访问
设备状态
Azure 提供设备孪生功能，通过托管的 JSON 文档同步所需的预期属性和报告属性，与 Azure 服务无缝集成，并提供查询支持。
EMQX 则使用保留消息和最后值队列来维护设备状态，支持即时读取最新值。但 EMQX 并未内置期望值与报告值的同步功能，对该功能有需求的应用程序通常会在后端逻辑中实现。
文件传输
Azure IoT Hub 通过 SAS URL 实现文件上传，设备需要支持 HTTPS、处理 Token 轮换，并直接上传至 Blob 存储。
EMQX 支持基于 MQTT 连接的文件传输，避免了设备端多协议栈的复杂性，并支持断点续传和带宽限速。
远程访问
Azure 为远程访问提供安全的双向 TCP 隧道，但该功能仍处于预览状态。
EMQX 虽然没有专门的远程访问产品，但可以通过二进制负载和主题路由灵活构建自定义隧道方案。
安全性与多租户
认证授权
Azure 与 Microsoft Entra ID 集成，支持 X.509、SAS Token 和 TPM 认证。
EMQX 支持内部数据库、JWT、LDAP 及外部 REST 服务认证，并拥有细粒度的的主题级 ACL 控制。
多租户模式
Azure IoT Hub 以每个实例为单一租户。SaaS 提供商通常需要为每个客户部署独立的 Hub。
EMQX 6.0 支持基于命名空间的多租户，允许不同业务部门在同一集群内共享资源，同时保持数据和权限的逻辑隔离。
定价模式与总成本
Azure IoT Hub 的定价模式以单元和消息计量为基础，消息以 4KB 为单位计费，通常会增加小型部署场景的成本。此外，用户必须按峰值负载预置资源，且无法缩容至零。
EMQX 的定价模式灵活多样，可根据部署模型进行选择：
- Serverless：按会话时长、流量和规则动作次数计费。非常适合规模波动大或间歇性在线的设备集群。
- 专有版：支持连接数与吞吐量独立扩展。非常适合高并发连接、低消息频率的业务场景。
- 私有化部署：通过直接管理基础设施，可进一步降低大规模部署的长期成本。
成本场景示例：
- 场景：50,000 台设备，每 10 分钟发送 1KB 数据。
- 流量：每日约 720 万条消息。
- Azure 方案：S2 每日消息上限为 600 万条，需要 2 个 S2 单元，月成本约 500 美元。
- EMQX 方案：专有版月成本约为 250 - 350 美元。
随着消息速率增加，成本差距会进一步拉大。这是因为 Azure 用户必须升级整个单元，而 EMQX 的成本主要与带宽成正比。
运营限制对比
| 指标 | Azure IoT Hub S1 | Azure IoT Hub S3 | EMQX 专有版 | EMQX Enterprise |
|---|---|---|---|---|
| 最大连接数 | 1,000,000 | 1,000,000 | 按配置扩展 | 测试至 1 亿 |
| 吞吐量 | 每秒 100 条或 12 连接 | 每秒约 6,000 条 | 每次部署约 10,000 条 | 受硬件限制 |
| 最大消息大小 | 64 KB C2D, 256 KB D2C | 同左 | 默认 1 MB，可选 10 MB | 256 MB |
| 文件上传速率 | 1.67 次/秒/单元 | 83.33 次/秒/单元 | 计入消息速率 | 受硬件限制 |
| 保留状态大小 | 40 KB | 40 KB | 1 MB | 256 MB |
总结
什么时候选择 Azure IoT Hub？
- 您的技术栈深度绑定 Azure 生态（如 Digital Twins, Cosmos DB, Azure Functions）。
- 需要开箱即用的、完全托管的设备生命周期管理。
- 设备规模适中，对 MQTT 5.0 或 QoS 2 等高级特性无硬性要求。
什么时候选择 EMQX？
- 高并发连接：需要支持百万甚至千万级以上的并发连接。
- 标准协议需求：需要完整的 MQTT 5.0 支持或多协议（CoAP/LwM2M）接入。
- 多租户架构：需要在单个基础设施上支撑多个客户或业务线。
- 跨云/混合云需求：希望在公有云、私有云及边缘侧运行完全一致的数据平台。
- 成本敏感型：追求更高的性价比，避免被厂商特定的计费逻辑限制。
注：本文内容基于 2025 年 12 月的产品特性及定价信息。鉴于两个平台的技术迭代迅速，建议在决策前参考各官网的最新文档。