千万级车联网 MQTT 消息平台架构设计 _车联网

笛里谁知壮士心，沙头空照征人骨。这篇文章主要讲述千万级车联网 MQTT 消息平台架构设计相关的知识，希望能为你提供帮助。
前言随着整个汽车出行领域新四化（电气化、智能化、网联化和共享化）的推进，各个汽车制造厂商正逐步构建以智能驾驶和智能网联为核心的车联网系统。新一代的车联网系统对于底层消息采集、传输和处理的平台架构提出了更高的要求。
本系列专题的上篇文章《车联网场景中的 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 等协议接入，经过负载均衡组件连接至分布式消息平台 EMQX。通过分布式多集群部署满足千万并发连接需求，按照百万级消息吞吐能力，通过规则引擎对接 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 在车联网场景下支持千万连接性能表现突出，架构稳定可靠。
写在最后通过本文，我们介绍了基于云原生分布式物联网接入平台 EMQX 的千万级车联网 MQTT 消息平台架构设计，并验证了该架构在千万级并发连接场景环境下的性能表现，为车联网系统的消息数据平台建设提供了一种可能的设计参考。
【千万级车联网 MQTT 消息平台架构设计】EMQ 作为全球领先的物联网数据基础设施软件提供商，致力于构建高性能、低延时、高可用、高可靠的产品，为新一代车联网体系提供消息采集、移动、处理和分析的整体解决方案，为整车制造商、T1 供应商、后市场服务商、出行服务公司和政府管理机构的自动驾驶、智能网联汽车业务提供基础设施服务保障，实现人、车、路、云的智能连接。
本系列的其它文章