一、政策解读

微信公众号“工信微报”4月9日消息，工业和信息化部、国家发展改革委、财政部、中国人民银行、税务总局、市场监管总局、金融监管总局等七部门近日联合印发 《推动工业领域设备更新实施方案》，提出到 2027 年，工业领域设备投资规模较 2023 年增长 25 %以上，规模以上工业企业数字化研发设计工具普及率、关键工序数控化率分别超过 90 %、75 %，工业大省大市和重点园区规上工业企业数字化改造全覆盖，重点行业能效基准水平以下产能基本退出、主要用能设备能效基本达到节能水平，本质安全水平明显提升，创新产品加快推广应用，先进产能比重持续提高。

其中在方案第二部分“实施数字化转型行动”，有多处提到“物联网”相关的名词。

那这波政策对我们做性能的技术人有什么影响，个人猜测有以下两点：

1. 设备数字化改造，这个会带来大量的物联网测试机会，对从事该方向的从业人员是一个利好消息；
2. 乘着这波大更新，剔除漂亮国留下的暗门，也就是信创改造，针对信创的适配和测试估计会有一波红利。

那么，今天我们主要聊聊“物联网”这块的压测，说道物联网那必然绕不开 MQTT，它甚至已经成为物联网系统事实上的网络协议标准。如果你想从事物联网系统压测，就一定要掌握 MQTT 消息中间件压测方法。

二、MQTT 压测常见场景

不同的协议有各自的特定需求，需要设计不同的场景和测试用例，但是在 MQTT 设计性能测试时，我们可以参考以下几种常见的通用压测场景：

• BenchMark ：基准测试，即纯数通测试，不带业务规则，从而为后续实际业务压测场景做数据比对。
• 基准场景：单业务容量，即将每一个业务都压到最大TPS，从而为后续场景做数据比对。
• 容量场景：混合业务容量性能场景，即将所有业务根据比例加到一个场景中，在数据、软硬件环境、监控等的配合之下，分析瓶颈并调优的过程。
• 稳定性场景：核心就是时长。在长时间的容量场景运行之下，观察系统的性能表现，分析瓶颈并调优的过程。
• 异常场景：在长时间的容量场景运行之下，然后就是异常的定义最为重要。之前我们常用的手段就是岩主机、岩服务、岩网卡。随着云原生架构的发展，现在我们还有岩容器、岩虚机、岩缓存、岩队列等等。实际的场景中要模拟什么样的异常，一定是根据系统的MQTT消息中间件架构分析而来的。

三、MQTT常见业务场景

首先，我们大概了解下MQTT的基础概念。

MQTT（MQ Telemetry Transport）协议，是 IBM 公司在 1999 年开发的轻量级网络协议，它有三个主要特点：

• 采用二进制的消息内容编码格式，所以二进制数据、JSON 和图片等负载内容都可以方便传输。
• 协议头很紧凑，协议交互也简单，保证了网络传输流量很小。
• 支持 3 种 QoS（Quality of Service，服务质量）级别，便于应用根据不同的场景需求灵活选择。

这三个特点，让 MQTT 协议非常适合计算能力有限、网络带宽低、信号不稳定的远程设备，所以它成为了物联网系统事实上的网络协议标准。

MQTT 属于发布 - 订阅模式，其中包含三个角色，分别是发布者（Publisher）、经纪人（Broker）和订阅者（Subscriber），它们的关系如下图所示。

相关概念：

• Publisher（发布者）：消息的发出者，负责生产数据。发布者发送某个主题的数据给经纪人，发布者不知道订阅者。
• Subscriber（订阅者）：消息的订阅者，订阅经纪人管理的某个或者某几个主题。
• Broker（经纪人）：当经纪人接收到某个主题的数据时，将数据发送给这个主题的所有订阅者。
• Topic（主题）：可以理解为消息队列中的路由，订阅者订阅了主题之后，就可以收到发送到该主题的消息。
• Payload（负载）；可以理解为发送消息的内容。
• QoS（消息质量）：全称 Quality of Service，即消息的发送质量，主要有 QoS 0、QoS 1、QoS 2三个等级，下面分别介绍下：
  • QoS 0（Almost Once）：至多一次，只发送一次，会发生消息丢失或重复；
  • QoS 1（Atleast Once）：至少一次，确保消息到达，但消息重复可能会发生；
  • QoS 2（Exactly Once）：只有一次，确保消息只到达一次。

在 发布/订阅模型 的背景下，设计 MQTT 测试场景的关键在于考虑如何模拟发布者和订阅者的不同行为，主要包括以下场景的场景：

• 连接：客户端在一定时间内连接到 Broker，并与 Broker 维持连接一段时间。
• 广播：大量客户端作为订阅者，只有少数或单个发布者。
• 点对点：发布者客户端和订阅者客户端数量相同。
• 上报：大量客户端作为发布者，只有少数或单个订阅者。

1、并发连接

MQTT 连接是一种基于 TCP 的长连接。客户端首先与 MQTT Broker 建立 TCP 连接，然后发送 MQTT 登录请求。连接成功建立后，客户端和 MQTT Broker 通过定期发送心跳包来维持连接状态。所以建立和长期维持一个MQTT连接是需要占用MQTT broker一定资源的，在高并发场景下，这种长连接会消耗 Broker 的大量资源。因此，通过压测，我们可以评估 MQTT Broker 在有限资源下能够承受多少并发连接。

并发连接场景我们主要关注以下两个指标：

• 并发连接数：
• 连接速率

并发连接数
维持海量设备连接需要消耗大量的计算资源，在并发连接测试中还要考虑是否使用 TLS/SSL 加密传输，因为它会增加压力机和MQTT Broker额外的资源开销。在计划测试时，需要评估它对性能的影响。

比如常见技术指标：支持千万级设备在线，背景连接 (只连接不发送消息)

连接速率
即每秒新增连接数越高，需要的计算资源越多，在制定测试场景时需要考虑这个因素，因为在有些场景下大量的设备会同时上线，在测试 broker 的能力或规划系统容量时需要这个指标。

比如，实际项目我们在模拟异常场景在连接故障的时候，实现了整个连接 FailOver，避免设备批量故障、云平台发布、网络抖动等原因导致大规模设备集体上线、下线，从而触发整个平台雪崩。

比如常见的技术指标：能支持百万设备掉线 3 分钟故障转移目标。支持百万长连接的 session 在分钟内迁移，可用于容灾、发布断连等场景。

综上所述，在 MQTT 并发连接测试中，应该考虑以下几种场景：

• 在固定的较低连接速率下逐步提高并发连接数，测试系统响应和资源消耗情况。这可以确定系统在给定的硬件和网络资源下能够承受的最大并发数。
• 在给定的并发连接数下，测试不同连接速率下系统的响应和资源消耗情况。
• 在给定的并发连接数下，测试海量连接并发瞬时连接，测试所有连接完成所需时间，期间平台不会雪崩。
• 在设计时，区分普通 TCP 连接和 TLS/SSL 加密连接。

2、消息吞吐量测试

如前文所述，MQTT 是一种基于发布/订阅模式的消息传输协议，它是一种异步协议，实现了发布-订阅 1对1，1对多，多对1这3种类型，广泛应用于各种物联网场景。因此，消息吞吐量测试应该涵盖以下三种场景：

2.1 1 对 1

发布者和订阅者的数量相等。对于每个发布者，有唯一一个订阅者订阅其发布的主题。也就是说，MQTT Broker 的消息流入速率与流出速率相同。

举例场景：

• 场景名称：单节点 10 万并发连接下支持 20 万 QoS1 消息吞吐
• 描述：10 万 MQTT TCP 连接， pub 客户端和 sub 客户端数量相同都是 5 万，每个接收端均订阅一个对应的发送端 pub 主题，每个 pub 客户端每秒发送 2 条 QoS 1、payload 为 1k 字节的消息。因此消息发送和接收均为每秒 10 万，总的消息吞吐达到每秒 20 万。测试执行 1 个小时。
• 期望结果：内网测试成功率为 100%，无消息积压，CPU 和内存在测试期间表现平稳，没有大幅度的抖动。

2.2 多对1（上报）

一种典型的物联网应用场景，有大量物联网设备作为发布者，但只有少数或单个订阅者，例如大量设备上报其状态或数据。

举例场景：

• 场景名称：千万连接+消息吞吐
• 描述：1000 万 MQTT TCP 并发连接，心跳间隔 200s。其中 700 万为背景连接 (只连接不发送消息)，300 万活跃用户，每个用户每隔 15S 上报一条 QOS 0 的消息，payload 为 100B。消息通过规则引擎桥接到 Kafka。稳定性运行30分钟。
• 期望结果：内网测试成功率为 100%，无消息积压，CPU 和内存在测试期间表现平稳，没有大幅度的抖动。

  2.3 1对多

即广播模式，少量客户端发布消息，大量设备端订阅消费消息，如控制端指令下发。

举例场景：

• 场景名称：消息广播
• 描述：1000 万 MQTT TCP 并发连接，所有连 接均订阅同一个 OTA 广播主题(QoS 0，payload 为 100B)。模拟一个 MQTT 客户端每隔 10 分钟向该主题广 播一条消息，测试 30 分钟
• 期望结果：内网测试成功率为 100%，所有订阅客户端成功消费 3 条消息

另外，在设计消息吞吐量场景时，不要忽略 QoS、消息有效载荷大小、带通配符的订阅主题等因素。不同的 QoS 对负载测试的性能和资源消耗有很大影响。有效载荷大小可以根据实际使用情况确定。

2.4 其它场景

对于其它 MQTT 功能，如共享订阅、消息转存到数据库或其他消息队列（MQ）、海量主题订阅等极端情况，可以根据实际需求进行设计并加入测试场景中。

三、MQTT常见性能指标

指标一般可以分为两大类：应用指标（比如 MQTT Broker 的指标）和计算资源指标。

• 应用指标与用户场景和需求有关，例消息时延、并发连接数、数据吞吐量（TPS）等。
• 计算资源指标与硬件资源消耗有关，例如 CPU、内存、网络、磁盘 I/O。

常见的指标如下表所示：

四、MQTT常见性能工具

1、emqtt-bench

emqtt-bench 是 emqx 编写的用于测试 MQTT 服务器性能 BenchMark 的测试程序，使用 Erlang 语言编写，与其它工具（如：JMeter）相比，emqtt_bench 的优点是安装和使用简单，占用的计算资源较少。但它支持的场景比较有限，需要结合其他监控工具测试指标数据。

具体安装和使用方法请参考： 性能工具之emqtt_bench快速上手

2、JMeter

如果要进行大规模业务压测，我们推荐另一款更专业的性能和负载测试工具 - JMeter。

JMeter 提供了基于 MQTT 协议开源测试插件：https://github.com/xmeter-net/mqtt-jmeter 。

目前 JMeter MQTT 插件的最新版本为 2.0.2，支持连接、消息发布、消息订阅等多种采样器，并可通过组合构建更复杂的测试场景。

五、小结

物联网系统在架构、网络模式、通信协议等方面与传统的互联网系统有所区别。因此，传统的性能测试方法不能直接套用到物联网系统中。

首先，物联网系统压测的对象主要是“设备”，而非“用户”，需要模拟大量设备进行连接和通信，并产生海量的数据。所以模拟真实的设备规模非常重要，这需要对生成压测工具进行更精细的设计，以及对测试结果进行更有效的分析。

其次，物联网的通信方式与互联网不同，因此多种物联网通信协议应运而生。

对于 MQTT 协议，它所具备的一些特点使其与互联网消息协议有很大的区别：

• MQTT 是轻量级的，专为不稳定的网络连接和节省带宽而设计。
• MQTT 使用 QoS 来支持复杂的设备网络环境。
• MQTT 与数据无关。
• MQTT 是一种基于 TCP 的长连接，具有持久会话的特性。

因此在对 MQTT 协议压测进行测试时，要注意考虑它的独特性。

参考资料：

• 构建可靠的物联网系统：了解 MQTT 性能测试
• MQTT 性能测试入门：常见测试场景和指标
• 阿里云物联网平台技术解读与实践
• 物联网平台业务链路设计方案
• EMQ X 企业版 4.3.0 千万并发连接、千万订阅和百万消息吞吐性能测试报告.pdf
• 下一代车联网设计与实现.pdf