• 1 背景
• 2 物联网介绍
  • 2.1 开篇故事
  • 2.2 物联网是什么
  • 2.3 物联网的基本组成
• 3 物联网技术选型和落地方案
  • 3.1 应用层协议选型
  • 3.2 Broker 选型
  • 3.3 QoS 消息质量选型
  • 3.4 Broker 的部署方案
• 4 结语
• 5 参考链接

1. 背景

在转转智能质检中心，随着业务的不断发展，自动化检测硬件设备、以及设备端（手机、Pad 等）的自动化检测能力越来越丰富。

下图列举了目前转转智能质检中心的几个自动化检测设备

在前期发展过程中，各类自动化检测能力的设计和开发，主要围绕本身的功能来进行，缺少一个对整体自动化程序的统一规划和设计，管理维护和迭代成本都较高。

在这背景下，主要存在以下几个问题：

• 系统维护成本高： 质检自动化设备与其他设备的通信协议没有做到很好的统一，各成体系。随着业务的不断发展，系统越发臃肿，开发和维护成本随之增加。
• 设备状态监控不足： 设备故障无法被及时发现，导致停机和维修成本增加。
• 数据延迟与不完整： 由于设备离线运行，数据的实时性和完整性难以保证。
• 设备维护成本高： 设备依赖人工维护，效率低下且成本高昂。
• 自动化能力集成设备越来越多，更需要稳定可靠的架构： 随着业务发展和技术能力的突破，自动化能力建设已进步不单单是对硬件设备的调度，还不断扩大到对针对被检测设备（比如手机、Pad、笔记本等）的检测能力调度。

综上，笔者所在的团队通过引入 物联网（IoT） 技术，实现了自动化设备的智能化管理。通过物联网技术，统一技术架构设计、降低开发维护成本的同时，完善自动化设备实时监控，来解决当下面临的主要问题。本文将重点介绍物联网技术选型和落地方案。

2. 物联网介绍

2.1 开篇故事

在工作时渴望来一杯冰凉的咖啡提提神，但你每次走到楼下的咖啡店，却发现咖啡店已经打烊或者心仪的咖啡已经售罄。是不是很失望？

20 世纪 70 年代末到 80 年代初，卡内基梅隆大学计算机科学系的研究人员也有同样的烦恼，在工作时渴望喝一瓶冰凉的可乐，但每次走到楼下的自动售货机，却发现可乐已经卖完或者刚刚补货还没有冷却。这导致他们频繁地空跑，浪费了宝贵的时间和精力。

1982 年，几位计算机科学系的学生，包括 Mike Kazar、David Nichols、John Zsarnay 和 Ivor Durham，决定通过互联网解决这个问题。

他们在自动售货机内安装了微型开关，用于检测每一列饮料的库存状态。这些开关连接到一台计算机，通过互联网向研究人员报告饮料的库存和温度状态。

这台联网的可乐贩卖机成为世界上第一台连接到互联网的设备，被认为是物联网的早期雏形。

就这样，这个项目启发了后续的许多研究和发展，使得物联网技术逐渐成熟，并应用到更广泛的领域中，包括智能家居、智慧农业、智能制造等等。

2.2 物联网是什么？

**物联网（IoT）**是指通过传感器、软件和其他技术将物理设备连接到互联网，使它们能够相互通信和共享数据。例如，智能家居设备可以通过手机远程控制，工业机器可以自动监测和报告运行状态。

2.3 物联网的基本组成

• 传感器和设备： 采集数据并执行操作，如温度传感器、智能灯泡等。
• 网络连接： 通过 Wi-Fi、蓝牙、蜂窝网络等方式将设备连接到互联网。
• 数据处理和分析： 收集的数据通过云计算或边缘计算进行分析，提供有价值的信息。
• 用户接口： 用户通过应用程序或控制面板与设备交互。

3 物联网技术应用和选型方案

3.1 应用层协议选型

物联网协议可以根据不同的层级和功能进行分类，包括设备层协议、网络层协议、传输层协议、数据链路层协议和应用层协议等。这里主要介绍物联网的应用层协议。

针对应用层协议，调研时参考了国内各云平台的主流支持情况，从以下几个方案中做了横向对比：

3.1.1 HTTP/HTTPS

HTTP（超文本传输协议）和 HTTPS（安全超文本传输协议）是用于分布式、协作式和超媒体信息系统的应用层协议，广泛应用于 Web 浏览和其他互联网服务。

• 优势：
  • 标准化、通用性强，几乎所有编程语言都有成熟的库。
  • HTTPS 提供加密，确保传输安全。
• 不足：
  • 开销大，实时性差，不适用于资源受限的设备。
  • 通信开销和延迟较高，不适合高频率的小数据传输。

3.1.2 MQTT（Message Queuing Telemetry Transport）

MQTT 是一种轻量级的发布/订阅消息传输协议，设计用于低带宽、高延迟或不稳定的网络。

• 优势：

  • 轻量级、高效，适合受限设备和低带宽环境。
  • 支持不同的服务质量（QoS）级别，确保消息的可靠传递。
  • 发布/订阅模式支持灵活的通信拓扑结构。
  • 支持基于用户名和密码的简单身份验证，还可以使用 TLS（传输层安全）或 SSL（安全套接字层）来加密通信。

• 不足：

  • 需要消息代理，增加了系统复杂性。
  • 长连接，大规模场景下心跳包仍可能造成一定的网络开销。

3.1.3 CoAP（Constrained Application Protocol）

CoAP 是一种专为物联网设计的协议，基于 UDP，适用于资源受限的设备和网络。

• 优势:

  • 无连接、轻量级、低功耗，专为资源受限设备设计。
  • 支持请求/响应模型，具有较好的实时性。
  • 通过 UDP 传输，网络开销小，适合低带宽和高延迟的网络环境。

• 不足：

  • 未建立在可靠的 TCP 上，可靠性和消息确认需要额外机制。
  • 安全性需要额外考虑，通过 DTLS 实现较为复杂。

3.1.4 选型依据和结论

考虑在质检过程中自动化设备以及质检的 3C 产品都需要联网，在设备数量达到一定程度时，核心关注点主要包括：

• 稳定性和可靠性：协议需要在复杂网络环境中保持稳定的数据传输，确保系统的可靠性。
• 实时性：在质检流程中，需要实时的数据传输和响应，以支持快速决策和即时反馈。
• 网络成本：随着设备数量的增加，网络传输成本显著提升，选择轻量化的协议能够有效降低成本。

方案评估：

• HTTP/HTTPS 在频繁的数据交换过程中，协议包报文较大，网络开销大。
• CoAP 适用于资源受限的设备和网络，如智能电表、燃气表等数据上报的场景。不太适用于大规模双向通信的场景。为了保障数据传输的安全性，通常需要通过 DTLS 来加密通信。自动化设备本身不是一个资源受限的设备。
• MQTT 由于协议足够轻量适合低带宽和高延迟的网络环境，同时支持不同的 QoS 级别，确保消息的可靠传递和实时性。

综上，MQTT 协议在协议包大小、稳定性、可靠性等方面都能够满足智能质检中心的需求。尤其是在需要低延时和高可靠性的场景中，MQTT 凭借其轻量级和高效的特性成为最优选择。因此，我们最终选择了 MQTT 协议作为应用层协议。

3.2 Broker 选型

MQTT 消息代理（MQTT Broker）是 MQTT 协议中的核心组件，负责管理客户端之间的消息传递。它在发布/订阅模型中扮演中间人的角色，确保消息从发布者（Publisher）传递到订阅者（Subscriber）。

当前，市场上有超过 20 个开源 MQTT Broker 项目，下面主要介绍 HiveMQ、 RabbitMQ 和 EMQX。

3.2.1 HiveMQ

HiveMQ 是一种企业级的 MQTT 消息代理，专注于高性能和高可靠性的物联网（IoT）应用。

• 高可用
  • 优势：支持分布式集群部署，具有自动故障转移和负载均衡功能，确保系统的高可用性。
  • 不足：需要企业版才能获得全套高可用性功能，免费版本功能受限。
• 安全性
  • 优势：支持 TLS/SSL 加密、身份验证和授权，提供企业级安全特性，还支持 OAuth 2.0 和 X.509 证书。
  • 不足：高级安全特性需要企业版支持。
• 易用性
  • 优势：提供直观的管理控制台，文档详尽，社区和企业支持非常强大。
  • 不足：企业版价格较高，入门门槛较高。

3.2.2 RabbitMQ

RabbitMQ 是一个通用的消息代理，支持多种消息协议，包括 AMQP、MQTT、STOMP 等。

• 高可用
  • 优势：支持分布式集群部署、镜像队列和持久化，保证消息在系统故障时的可用性。
  • 不足：配置复杂，集群管理和维护需要较高的运维经验。
• 安全性
  • 优势：支持 TLS/SSL 加密、身份验证和授权，提供细粒度的安全控制。
  • 不足：安全配置较复杂，需要深入理解 RabbitMQ 的安全模型。
• 易用性
  • 优势：支持多种协议和插件扩展，功能非常丰富。
  • 不足：初始配置和优化可能较为复杂，需要深入了解其架构。

3.2.3 EMQX

EMQX 是一种高性能、可扩展的 MQTT 消息代理，专为物联网设计。

• 高可用

  • 优势：原生支持分布式集群和高可用性，能够支持百万级连接，自动故障转移。
  • 不足：配置复杂，集群管理需要一定的技术背景。

• 安全性

  • 优势：支持 TLS/SSL、LDAP、JWT 和 ACL 等安全机制，提供全面的安全保障。
  • 不足：高级安全配置可能需要较高的学习成本。

• 易用性

  • 优势：提供丰富的插件和管理工具，支持可视化管理。
  • 不足：配置和优化需要一定的技术经验，尤其是在大规模部署中。

3.2.4 选型依据和结论

• HiveMQ：分开源版本和付费版本，开源版本基于 Java 语言开发，集群部署最大支持 5 个节点。仅支持使用用户名和密码进行身份验证，不支持 TLS 加密，无法满足高级别的安全认证。
• RabbitMQ：完全开源，核心使用 Erlang 语言开发，MQTT 支持是通过扩展实现的，因此 MQTT 功能相对而言不是原生的，这可能在性能上不如原生支持 MQTT 的 Broker。
• EMQX：分开源版本和付费版本，开源版本基于 ErLang 语言开发，集群部署最大支持 3 个节点。支持基本的用户名和密码认证的同时支持 TLS/SSL 加密和简单的 ACL（访问控制列表），满足大多数中小型应用的需求。

综上，EMQX 开源版本能满足大多数中小型应用的需求，在高可用性、安全性、性能、成本和易用性等多个条件下均优于 HiveMQ 和 RabbitMQ，最终我们选择的 EMQX 作为 MQTT 的消息代理。

3.3 QoS 消息质量选型

在 MQTT 协议中，消息质量（QoS, Quality of Service） 是一个关键概念，用于决定消息在传输过程中的可靠性。MQTT 定义了三种消息质量等级（QoS 0、QoS 1、QoS 2），它们分别适用于不同的应用场景。下面是对每种 QoS 等级的详细分析，以及如何在实际应用中选择适合的 QoS 等级。

3.3.1 QoS 0: 至多一次（At most once）

消息被发送一次，发送者不会要求确认消息是否被成功接收。消息可能会丢失。

• 优势：网络开销最小，延迟最低。
• 不足：无法保证消息一定到达，适用于对数据可靠性要求不高的场景。

3.3.2 QoS 1: 至少一次（At least once）

消息至少会被送达一次，接收者需要确认接收到消息。如果发送者未收到确认，会重发消息，直到确认接收为止。

• 优势：提供了较好的消息到达保障。
• 不足：可能导致消息重复，需要额外处理逻辑来消除重复影响。

3.3.3 QoS 2: 仅一次（Exactly once）

消息保证精确传递一次，不会重复或丢失。通过多步骤握手协议来确保消息到达。

• 优势：提供最高的消息传递保障。
• 不足：需要更多的网络开销和处理时间，增加系统延迟。

3.3.4 选型依据和结论

在实际场景中，需要精确控制自动化设备完成一系列交互，自动化设备指令的重复执行都可能带来严重后果（例如：机械手在夹持手机过程中重复执行操作可能导致手机损坏）。因此，我们在 MQTT 的三个消息质量选项中选择了 QoS 2，具体原因如下：

• Qos 0 效率最高，但不保证消息的可靠性，可能导致消息丢失，不适合需要严格控制的场景。

• QoS 1 可以确保消息至少传递一次，但有可能导致消息重复，各端需要额外处理重复消息的逻辑，增加了开发和运维的复杂度。

• QoS 2 能够确保消息仅传递一次，是最可靠的消息质量等级。尽管在网络延迟上有所牺牲，但 PUBREC、PUBREL 和 PUBCOMP 报文大小仅为 4 个字节，使得延时在大多数情况下可以接受。选择 QoS 2 可以让开发人员更专注于应用逻辑，而无需过多担心消息传输的可靠性问题。

综上所述，QoS 2 是我们在严苛场景下的最佳选择，能有效降低因消息重复而可能造成的风险，同时确保系统的高可靠性。

3.4 Broker 的部署方案

前面我们介绍了消息发布、消息中间件和消息质量的选型，接下来我们就要考虑该如何部署了。先简单介绍一下背景：

• 云服务器：主要集中在华北地区。
• 智能质检中心：全国各大区域均有分布。

在不考虑运营商、物理距离等其他外界环境影响的情况下，消息的延时可能会随着消息量的增加而增加（正常情况下从华南到华北的网络延时大概在 50 毫秒以上），因此提出了以下部署方案。

3.4.1 云服务器部署

将 MQTT Broker 部署在云服务器上，设备通过网络连接到中心服务器进行消息传递。

• 优势：Broker 可以做到统一管理，简化了维护和监控。
• 不足：由于跨区域传输，可能会出现较高的消息延时，影响实时性。

3.4.2 本地部署

在智能质检中心内部署，设备通过局域网连接到 Broker，处理当前质检中心设备的消息传递。

• 优势：消息传递几乎是即时的。
• 不足：多个本地 Broker 需要分别进行管理和维护，增加了运维的复杂度。

3.4.3 混合部署（边缘计算）

在智能质检中心部署边缘节点，处理当前质检中心设备的消息传递。并与中央云服务器上的 Broker 同步数据，同时中央服务器还承载着没有服务器资源站点的消息处理。

• 优势：延时极低、有效减轻中心节点负载。
• 不足：在大规模部署时，边缘节点的分散性可能增加管理的复杂性。

3.4.4 选型依据和结论

主要考虑的因素：

• 网络延时：智能质检中心的地域分布不均，比如华南到华北的网络延时，如何部署 Broker 来减少延迟。
• 扩展性：未来智能质检中心将有更多的自动化设备接入，因此系统需要具备良好的扩展能力。

方案评估：

• 云服务器部署：网络延时较高，按照网络延时 50 毫秒计算，单台自动化设备完成一个完整流程可能增加约 2 秒的执行时间。
• 本地部署：消息延时几乎为零，能够显著提高自动化设备的响应速度和实时性。
• 混合部署（边缘计算）：在保证低延时的同时，减轻中心节点的负载。

同时在云服务器和本地部署分别进行了以下压测(因篇幅有限，这里仅展示不同客户端连接数情况下消息质量 QoS 2 时报文大小为 1KB 的场景)，结果如下：

压测场景（客户端连接数）	本地部署延时	云服务器部署延时
10	6ms	42ms
100	7ms	47ms
1000	10ms	57ms

综上，我们目前选择了本地部署方案。本地部署方案能够显著降低延时，虽然管理上有一定挑战，但能够满足当前的响应速度要求。

然而，随着智能质检中心自动化设备的增加，混合部署方案应该是未来的首选，即通过边缘计算降低延时，并同步关键信息至中央服务器。这个方案能够在延迟、管理难度和系统性能之间取得最佳平衡。

4 结语

通过本文的分析和讨论，我们清楚地看到，物联网技术在智能质检中心中的应用，不仅成功地解决了传统质检方式中的多项难题，还为未来的业务发展提供了坚实的技术支撑。

首先，通过引入物联网技术解耦了各端原本藕合的业务逻辑，统一了各端的通信协议。

其次，在应用层协议、MQTT Broker 的选型，以及 QoS 消息质量选择的过程中，通过全面的对比和评估，选择了最符合业务需求的技术方案。这些技术方案的落地实施，使得智能质检中心能够更加高效、稳定地运行。

最后，通过本地部署方案进一步优化了系统的响应速度和可靠性，后续我们将通过混合部署方案（边缘计算）进一步有效地降低了因地域分布而带来的网络延时问题。这一部署方案，不仅满足了当前的业务需求，也为未来的扩展和优化提供了广阔的空间。

在转转，物联网技术正推动着"智慧工厂"的崛起。物联网实现了生产设备的互联互通，使得生产过程更加透明化、自动化。未来，物联网还将深化与人工智能、机器人技术的融合，开创智能制造的新篇章。

5 参考链接

• https://mqtt.org
• https://www.emqx.io
• https://www.sciencedirect.com/science/article/pii/S1389128621003364
• https://www.kepuchina.cn/article/articleinfo?business_type=100&classify=2&ar_id=455497

---

关于作者

温筠庭，来自转转研发中心-履约技术部后端团队，负责转转质检自动化项目后端开发工作。

转转研发中心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。
关注公众号「转转技术」（综合性）、「大转转FE」（专注于FE）、「转转QA」（专注于QA），更多干货实践，欢迎交流分享~