共计 6011 个字符，预计需要花费 16 分钟才能阅读完成。
在本专题系列文章中，咱们将依据 EMQ 在车联网畛域的实践经验，从协定抉择等理论知识，到平台架构设计等实战操作，与大家分享如何搭建一个牢靠、高效、合乎行业场景需要的车联网平台。
前言
随着整个汽车出行畛域新四化（电气化、智能化、网联化和共享化）的推动，各个汽车制造厂商正逐渐构建以智能驾驶和智能网联为外围的车联网零碎。新一代的车联网零碎对于底层音讯采集、传输和解决的平台架构提出了更高的要求。
本系列专题的上篇文章《车联网场景中的 MQTT 协定》中咱们曾经提到，MQTT 协定是目前最适宜车联网场景数据平台搭建的通信协议。基于此，本文中咱们将持续探讨车联网场景中的 MQTT 音讯采集与传递，以及如何构建一个千万级车联网 MQTT 音讯平台，以期为正在进行车联网业务的企业用户提供平台架构设计参考。
车联网的根底：音讯采集与传递
车联网传输协定的演进
家喻户晓，车联网（vehicle-to-everything，V2X）是指车与云、车与网、车与车、车与路、车与人、车与传感设施等交互，实现车辆与公众网络通信的动静挪动通信零碎，是为了满足与车无关的每一个环节中的效率、平安、治理等元素而建设起的异构通信网络。而运行于其中的通信协议就成为车联网零碎建设的要害和外围。
在车联网倒退的历程中，次要有两种支流的通信技术，对车联网整体倒退起到了推动作用：
DSRC（DeDICated Short Range CommunICation，专用短程通信）：1992 年由美国资料试验学会 ASTM 针对 ETC 的业务场景研发而出，后经多年欠缺和迭代，演变为 IEEE(802.1X) 车联网通信技术标准。在相当长的一段时间里，DSRC 技术是国内汽车支流生产和消费市场应用的支流车联网通信协议。
C-V2X（Cellular Vehicle to Everything，蜂窝车联网通信）：C-V2X 依靠现有的蜂窝基站，除了反对 PC5 的直连通信，RSU、车辆均可通过 4/5G 信道（采纳 Uu 接口）与 V2X 平台相连，实现车路协同通信。较之 DSRC，C-V2X 技术上更优，它加强通信的安全性与保密性，反对高网络容量，可反对高带宽和大数据量需要。
DSRC 和 C-V2X 技术的竞争十分强烈，两者都心愿可能成为支流车联网通信规范。目前，我国领有最欠缺的 5G 通信网络的基础设施，因而更偏向于采纳 C-V2X(LTE-V、5G-V2X) 通信技术，通过 V2X 车路零碎 + 单车智能零碎的体系化建设，实现基于主动驾驶的新一代车联网架构。
音讯平台建设对于车联网的意义
在车联网建设高速倒退的明天，所有的主机厂业已造成了一个共识: 车联网建设的目标不是为了联网而联网，也不是为了车载娱乐而联网，联网是为了数据。有了车联网，就有了数据。有了数据，辅以残缺的数据治理和利用体系，就有了所有。
而这个业务的指标数据，也不仅仅限于车端的相干数据。在 V2X 框架中，须要解决车与车（V2V）、车与路（V2R）、车与网（V2I）、车与云（V2C）、车与人（V2H）等的互联互通，实现针对车、路、云、网、人的全面数据采集和剖析。基于 5G 的 C-V2X 协定和通信形式，为整个零碎的建设提供根底能力保障。
从传统的 OTA 利用到智能座舱、高精地图适配、厘米级定位、车机端长连贯、手机端音讯采集、车路云图、车路协同等泛滥新型智能利用场景，车联网业务对于音讯平台和数据处理系统的需要已从原始的车云扩大为人 - 车 - 路 - 网 - 云的整体架构建设，也因而对整个音讯平台的建设提出了更高的要求。
如何建设一个海量连贯、高并发吞吐、低时延的音讯通信和传输零碎架构，来保障整个零碎的泛在性、便利性、高可用性、可靠性、安全性和高并发性，就成为了基于主动驾驶和车路协同场景下新一代车联网零碎建设的关键所在。
千万级车联网音讯平台架构设计
接下来咱们将以 EMQ 的车联网音讯平台和数据处理整体解决方案为例，介绍如何构建一个千万级的车联网音讯平台。
业务挑战
车机、路测单元和手机端系统安全接入
车端须要涵盖车机数据上报、POI 下发、推送文件、下发配置、推送音讯、经营关心等全新车联业务，产生的海量音讯 Topic 须要更加平安稳固的接入与传输实现音讯订阅和公布。路端须要实现路侧 RSU 的平安接入，音讯采集和传输、地图数据的传输等。
大并发消息传递的实时性和可靠性
高精地图、厘米级定位、车路协同等利用场景均须要解决海量车路图音讯的毫秒级低延时和高牢靠的传输能力保障，须要音讯解决平台具备高性能、低延时、高牢靠反对千万连贯和百万并发业务场景的能力。
丰盛的利用场景集成
在以主动驾驶为外围的车联网零碎中，须要应用音讯平台对接各种基于人、路、图、云相干的利用对接。将车端数据通过音讯平台同高精地图、厘米级定位、车路协同、手机端连贯等利用场景进行连贯，通过音讯平台保障利用的生产供应，并提供高性能、低延时和高牢靠的数据架构。
海量数据存储、解决和散发
来自于人、车、路、云、图、网的海量物联网数据被采集后，须要针对这些大规模实时数据流的接入、存储、解决、散发等环节进行全生命周期治理，为利用提供针对动静间断数据流的数据库撑持，反对利用深度应用车联网数据服务于消费者，进行商业决策。
整体解决方案
在计划中咱们次要采纳 EMQ 旗下的云原生分布式物联网接入平台 – EMQX，实现车联网零碎中车端和人、路端的数据连贯、挪动和解决。EMQX 一体化的分布式 MQTT 音讯服务和弱小的 IoT 规定引擎，可为高牢靠、高性能的物联网实时数据挪动、解决和集成提供根底能力底座，助力企业疾速构建要害业务的 IoT 平台与利用。
针对车端的音讯解决
EMQX 采纳 MQTT 协定接入车联零碎。车机端通过负载平衡与 EMQX 分布式集群进行连贯，EMQX 的横向扩大能力可实现千万级车机连贯和百万并发响应的数据通信能力。通过规定引擎，可一站式实现海量音讯桥接音讯队列、长久化入库、离线音讯存储等能力，同时提供丰盛的 API 原子能力北向集成。
在平安方面，EMQX 不仅反对 TLS/DTLS 或国密 GMSSL 平安协定，保障系统牢靠与稳固；还提供心跳监测、遗嘱音讯、QoS 等级等多重保障机制，通过离线音讯存储实现在简单的网络环境下实时、平安、牢靠的车机音讯通信。
针对人、路端的音讯解决
EMQX 为人、路端提供针对手机 APP、RSU 等终端的音讯采集和解决平台。基于 5G 网络切片能力，通过集体终端和路侧单元的就近接入，实现超低时延的交通信息服务。通过 MQTT 等协定将人端、路侧设施感知到的路况信息推送到云控平台，通过云控平台交融 V2X 算法实现路线协同感知知、平安揭示、近程协同管制等智能交通场景。
在平安方面，反对国际标准的 TLS/DTLS 加密或国密算法 GMSSL 加密，通过扩大基于 PKI/CA 证书认证体系保障人车路信息系协同的平安通信。
千万音讯接入框架模型
针对新一代车联网场景，EMQ 千万级连贯规模和百万级并发的整体音讯接入和数据处理平台参考架构如下：
- 业务场景 ：车联网体系中的车辆、手机 APP 端、路侧 RSU 等设施等通过 MQTT 接入，实现对千万量级的以上终端的并发接入能力。
- 零碎架构： 终端设备通过 MQTT、HTTP 等协定接入，通过负载平衡组件连贯至分布式音讯平台 EMQ X。通过分布式多集群部署满足千万并发连贯需要，依照百万级音讯吞吐能力，通过规定引擎对接 Kafka 集群实现数据的转发。车联网服务平台、高精地图服务、V2X 云控服务、定位服务和其余车辆网相干利用能够间接通过订阅 Kafka 数据进行生产，同时 EMQ 提供了 REST、MQTT 和 MQ 音讯队列三种南向接口服务实现对车控（近程管制）音讯的双向通信。
通过以上参考框架，EMQ 通过 EMQX 云原生分布式物联网接入平台可实现车联网场景下的千万连贯、百万并发吞吐的业务需要。
千万级音讯接入测试
测试环境和目标
某车企打算在车联网场景下，基于测试环境验证 EMQX 集群的以下能力，为后续业务增长做相应的技术架构和能力撑持筹备：
- 可撑持 1000 万并发连贯，同时反对每秒 10 万～15 万、payload 为 100 字节的 QoS 0 音讯通过规定引擎桥接到 Kafka；
- 1000 万并发连贯订阅、生产 OTA 播送主题；
- 300 万用户同时连贯不会造成集群雪崩，并测试连贯所需工夫。
另外，在实现上述所有测试后，持续摸索在目前配置下 1000 万并发的同时可反对的最高音讯发送并桥接转发至 Kafka 的吞吐量 (依据 EMQX 集群资源应用状况进步客户端音讯发送频率)，以及测试在 1000 万连贯下满足 QoS 为 2 且均匀响应工夫在 50 毫秒内的最高音讯吞吐。
测试筹备
客户端通过 TLS 加密连贯负载平衡 ELB，而后在 HAProxy 对客户端进行 TLS 终结，最初通过 TCP 连贯至 EMQX 集群。通过在 HAProxy 上终结 TLS 的形式能够进步 EMQX 集群的反对能力，在这种部署模式下 EMQX 的解决能力和客户端间接通过 MQTT TCP 连贯是完全一致的。另一方面，相比 MQTT TCP 连贯，客户端通过 TLS 连贯也须要耗费更多的资源，而本次测试规模为千万级，所需的测试机数量泛滥，为了缩小所需测试资源的同时不影响对 EMQX 集群的测试指标，本次测试将间接应用 TCP 连贯。
| 服务 | 数量 | 版本 | OS | 实例规格 | CPU | RAM | 网卡 | 端口 |
|---|---|---|---|---|---|---|---|---|
| 负载平衡云服务 | 1 | 网络型 / 大型 II | 18083/1883/8081 | |||||
| EMQX 节点 | 10 | V4.3.4 | Centos7.8 | c6.16xlarge.2 一般块存储 | 64C | 128G | 1 | 18083/1883/8081/8883 |
| Kafka 云服务 | 4 | 2.3.0 | Centos7.8 | c6.4xlarge.2 超高 IO 块存储 | 16 | 32G | 1 | 9092 |
| XMeter 压力测试管制节点 | 2 | 3.0 | Centos7.8 | c6.4xlarge.2 | 16 | 32G | 1 | 443/80/3000/8086 内网放通 |
| XMeter 压力测试节点 | 43 | 3.0 | Centos7.8 | c6.4xlarge.2 | 16 | 32G | 5 | 内网放通 |
测试场景
| 序号 | 场景名称 | 形容 | 冀望后果 |
|---|---|---|---|
| 1 | 千万连贯 + 音讯吞吐 | 1000 万 MQTT TCP 并发连贯，心跳距离 200s。其中 700 万为背景连贯 (只连贯不发送音讯)，300 万沉闷用户，每个用户每隔 15S 上报一条 QOS 0 的音讯，payload 为 100B。音讯通过规定引擎桥接到 Kafka。先测试 1 小时，通过后进行 24 小时稳定性测试 | 内网测试成功率为 100%，无消 息积压，CPU 和内存在测试期间体现安稳，没有大幅度的抖动。 |
| 2 | 音讯播送 | 1000 万 MQTT TCP 并发连贯，所有连 接均订阅同一个 OTA 播送主题 (QoS 0，payload 为 100B)。模仿一个 MQTT 客户端每隔 10 分钟向该主题广 播一条音讯，测试 30 分钟 | 内网测试成功率为 100%，所有订阅客户端胜利生产 3 条音讯 |
| 3 | 300 万并发刹时连贯 | 300 万 MQTT 客户端同时发动连贯，测试所有连贯实现所需工夫 | 300 万客户端都胜利连贯，集群不会雪崩 |
| 4 | 1000 万连贯下最高音讯吞吐摸索 | 现有配置及 1000 万连贯且桥接 kafka 下可达到的音讯最高吞吐率 (Qos 0，payload 100B/1kB) | 最高音讯吞吐率达到后测试 2 小时，内网测试成功率为 100%，无音讯积压，CPU 和内 存在测试期间体现安稳，没有大幅度的抖动 |
| 5 | 均匀响应工夫下的 TPS | 1000 万连贯下，音讯为 QoS2、payload 100B，均匀响应工夫在 50 毫米内反对的最高音讯 TPS | 可能达到不少于 20 万 TPS 的吞吐能力 |
测试后果
以下是本次测试的后果出现：
| 序号 | 场景 | 均匀响应工夫 | EMQX 节点 CPU 使用率 | EMQX 节点 CPU IDLE | EMQX 节点内存应用 (G) | LB 所需带宽 (MB) |
|---|---|---|---|---|---|---|
| 1 | 1 千万连贯 +20 万音讯吞 吐，QoS 0，payload 100B | 1.5ms | 31%~48% 均匀 47% | 37%~54% 均匀 47% | Used: 27.7~42 Free: 78.2~92.5 | 45 |
| 2 | 1 千万连贯下的音讯播送 | 100ms | 最高 21% | 最低 69% | Used 最高 32.3 Free 最低 87.9 | 200 |
| 3 | 300 万客户端刹时连贯 | 3 分钟实现连贯 | 最高 25% | 最低 63% | Used 最高 14.7 Free 最低 108.2 | 400 |
| 4 | 摸索最高吞吐：1 千万连 接 +120 万音讯吞吐，QoS 0，payload 1kB | 164.3ms | 23%~64% 均匀 46% | 20%~64% 均匀 43% | Used: 33~38 Free: 81.3~87.1 | 1350 |
| 5 | 1 千万连贯 +QoS2 20 万消 息吞吐，payload 100B | 51.4ms | 3%~51% 均匀 41% | 31%~53% 均匀 43% | Used: 22.2~29 Free:91~98 | 95 |
小结
如以上后果所示，在目前的部署架构下，能够满足该车企对于千万并发连贯 +20 万音讯桥接至 Kafka、音讯播送及 300 万刹时并发连贯的验证需要。在摸索测试中，1000 万连贯下测试到最高 120 万音讯 TPS(QoS 0、payload 1kB)，测试继续 10 小时 EMQX 集群稳固，CPU idle 最低至 20%，内存应用安稳。
由以上可知，EMQX 在车联网场景下反对千万连贯性能体现突出，架构稳固牢靠。
压力测试工具简介和应用
本次测试因为所需测试机数量多，治理简单，故应用 EMQ 旗下商业版测试软件 XMeter 性能测试平台和 JMeter-MQTT 插件进行。
XMeter 是基于开源测试工具 JMeter 扩大的性能测试平台。针对物联网具备的接入规模大、弹性扩大要求、多种接入协定、混合场景等特点，XMeter 对 JMeter 进行了革新，能够反对大规模、高并发的性能测试，比方实现千万级别的 MQTT 并发连贯和音讯吞吐测试。除了测试 MQTT 协定之外，还能够反对 HTTP/HTTPS 等支流的利用的测试。
JMeter-MQTT 插件是由 XMeter 实现的开源 MQTT 性能测试插件，在泛滥的我的项目中失去了应用，目前是 JMeter 社区中风行度最高的 MQTT 插件。
写在最初
通过本文，咱们介绍了基于云原生分布式物联网接入平台 EMQX 的千万级车联网 MQTT 音讯平台架构设计，并验证了该架构在千万级并发连贯场景环境下的性能体现，为车联网零碎的音讯数据平台建设提供了一种可能的设计参考。
EMQ 作为寰球当先的物联网数据基础设施软件提供商，致力于构建高性能、低延时、高可用、高牢靠的产品，为新一代车联网体系提供音讯采集、挪动、解决和剖析的整体解决方案，为整车制造商、T1 供应商、后市场服务商、出行服务公司和政府管理机构的主动驾驶、智能网联汽车业务提供基础设施服务保障，实现人、车、路、云的智能连贯。
对于作者
樊荣杰，EMQ 解决方案架构总监。领有丰盛的 IT 基础架构畛域教训，多年深耕于企业数字化转型与物联网架构构建、数据平台建设、麻利开发、精益运维和 DevOps 理念等畛域，致力于将先进的云计算、物联网产品技术和服务推向市场。
本系列的其它文章
- 车联网场景中的 MQTT 协定
版权申明：本文为 EMQ 原创，转载请注明出处。
原文链接：https://www.emqx.com/zh/blog/mqtt-messaging-platform-for-internet-of-vehicles