关于物联网:车联网平台百万级消息吞吐架构设计

在本专题系列文章中，咱们将依据 EMQ 在车联网畛域的实践经验，从协定抉择等理论知识，到平台架构设计等实战操作，与大家分享如何搭建一个牢靠、高效、合乎行业场景需要的车联网平台。

前言

在之前的文章中，咱们提到车联网 TSP 平台领有很多不同业务的主题，并介绍了如何依据不同业务场景进行 MQTT 主题设计。车辆会继续一直产生海量的音讯，每一条通过车联网上报的数据都是十分宝贵的，其背地蕴藏着微小的业务价值。因而咱们构建的车辆 TSP 平台也通常须要领有千万级主题和百万级音讯吞吐能力。

传统的互联网零碎很难撑持百万量级的音讯吞吐。在本文中，咱们将次要介绍如何针对百万级音讯吞吐这一需要进行新一代车联网平台架构设计。

车联网场景音讯吞吐设计的关联因素

车联网的音讯分为上行和上行。上行音讯个别是传感器及车辆收回的告警等音讯，把设施的信息发送给云端的音讯平台。上行音讯个别有近程管制指令集音讯和音讯推送，是由云端平台给车辆发送相应的指令。

在车联网音讯吞吐设计中，咱们须要重点思考以下因素：

音讯频率

车在行驶过程中，GPS、车载传感器等始终不停地在收集音讯，为了收到实时的反馈信息，其上报接管的音讯也是十分频繁的。上报频率个别在 100ms-30s 不等，所以当车辆数量达到百万量级时，平台就须要反对每秒百万级的音讯吞吐。

音讯包大小

音讯是通过各种传感器来采集本身环境和状态信息（车联网场景常见的有新能源国标数据和企标数据）。整个音讯包大小个别在 500B 到几十 KB 不等。当大量音讯包同时上报时，须要车联网平台领有更强的接管、发送大音讯包的能力。

音讯延时

车辆在行驶过程中，音讯数据只能通过无线网络来进行传输。在大部分车联网场景下，对车辆的时延要求是 ms 级别。平台在满足百万级吞吐条件下，还须要放弃低延时的音讯传输。

Topic 数量和层级

在思考百万级音讯吞吐场景时，还须要针对音讯 Topic 数量和 Topic 树层级进行标准设计。

Payload 编解码

当音讯包比拟大的时候，须要重点思考音讯体的封装。单纯的 JSON 封装在音讯解析时不够高效，能够思考采纳 Avro、Protobuf 等编码格局进行 Payload 格式化封装。

对于百万级音讯吞吐场景，基于 MQTT 客户端共享订阅音讯或通过规定引擎实时写入关系型数据库的传统架构显然无奈满足。目前支流的架构选型有两种：一种是音讯接入产品 / 服务 + 音讯队列（Kafka、Pulsar、RabbitMQ、RocketMQ 等），另外一种是音讯接入产品 / 服务 + 时序数据库（InfluxDB、TDengine、Lindorm 等）来实现。

接下来咱们将基于上述的关联因素和客户案例的最佳实际，以云原生分布式物联网音讯服务器 EMQX 作为音讯接入层，别离介绍这两种架构的实现形式。

EMQX+Kafka 构建百万级吞吐车联网平台

架构设计

Kafka 作为支流音讯队列之一，具备长久化数据存储能力，可进行长久化操作，同时可通过将数据长久化到硬盘以及 replication 避免数据失落。后端 TSP 平台或者大数据平台能够批量订阅想要的音讯。

因为 Kafka 领有订阅公布的能力，既能够从南向接管，把上报音讯缓存起来；又能够通过北向的连贯，把须要发送的指令通过接口传输给前端，用作指令下发。

咱们以 Kafka 为例，构建 EMQX+Kafka 百万级吞吐车联网平台：

1. 前端车机的连贯与音讯可通过私有云商提供的负载平衡产品用作域名转发，如果采纳了 TLS/DTLS 的平安认证，可在云上建设四台 HAProxy/Nginx 服务器作为证书卸载和负载平衡应用。
2. 采纳 10 台 EMQX 组成一个大集群，把一百万的音讯吞吐平均分到每个节点十万音讯吞吐，同时满足高可用场景需要。
3. 如有离线离线 / 音讯缓存需要，可选用 Redis 作为存储数据库。
4. Kafka 作为总体音讯队列，EMQX 把全量音讯通过规定引擎，转发给后端 Kafka 集群中。
5. 后端 TSP 平台 /OTA 等利用通过订阅 Kafka 的主题接管相应的音讯，业务平台的控制指令和推送音讯可通过 Kafka/API 的形式下发到 EMQX。

总体架构图

在这一计划架构中，EMQX 作为消息中间件具备如下劣势，可满足该场景下的需要：

• 反对千万级车辆连贯、百万级音讯吞吐能力。
• 分布式集群架构，稳固牢靠，反对动静程度扩大。
• 弱小的规定引擎和数据桥接、长久化能力，反对百万级音讯吞吐解决。
• 领有丰盛 API 与认证等零碎能顺利对接。

百万吞吐场景验证

为了验证上述架构的吞吐能力，在条件容许的状况下，咱们能够通过以下配置搭建百万级音讯吞吐测试场景。压测工具能够选用 Benchmark Tools、JMeter 或 XMeter 测试平台。共模仿 100 万设施，每个设施别离都有本人的主题，每个设施每秒发送一次音讯，继续压测 12 小时。

压测架构图如下：

性能测试局部后果出现：

EMQX 集群 Dashboard 统计

EMQX 规定引擎中能够看到每个节点速度为 10 万 / 秒的处理速度，10 个节点总共 100 万 / 秒的速度进行。

EMQX 规定引擎统计

在 Kafka 中能够看到每秒 100 万的写入速度，并且始终继续存储。

Kafka 治理界面统计

EMQX+InfluxDB 构建百万级吞吐车联网平台

架构设计

采纳 EMQX+ 时序数据库的架构，同样能够构建百万级音讯吞吐平台。在本文咱们以 InfluxDB 时序数据库为例。

InfluxDB 是一个高性能的时序数据库，被广泛应用于存储系统的监控数据、IoT 行业的实时数据等场景。它从工夫维度去记录音讯，具备很强写入和存储性能，实用于大数据和数据分析。剖析完的数据能够提供给后盾利用零碎进行数据撑持。

此架构中通过 EMQX 规定引擎进行音讯转发，InfluxDB 进行音讯存储，对接后端大数据和剖析平台，能够更不便地服务于时序剖析。

1. 前端设施的音讯通过云上云厂商的负载平衡产品用作域名转发和负载平衡。
2. 本次采纳 1 台 EMQX 作为测试，后续须要时能够采纳多节点的形式，组成相应的集群计划（测试 100 万能够部署 10 台 EMQX 集群）。
3. 如有离线离线 / 音讯缓存需要，可选用 Redis 作为存储数据库。
4. EMQX 把全量音讯通过规定引擎转发给后端 InfluxDB 进行数据长久化存储。
5. 后端大数据平台通过 InfluxDB 接管相应的音讯，对其进行大数据分析，剖析后再通过 API 的形式把想要的信息传输到 EMQX。

总体架构图

场景验证

如测试架构图中所示，XMeter 压力机模仿 10 万 MQTT 客户端向 EMQX 发动连贯，新增连贯速率为每秒 10000，客户端心跳距离 (Keep Alive)300 秒。所有连贯胜利后每个客户端每秒发送一条 QoS 为 1、Payload 为 200B 的音讯，所有音讯通过 HTTP InfluxDB 规定引擎桥过滤筛选并长久化发至 InfluxDB 数据库。

测试后果出现如下：

EMQX Dashboard 统计

EMQX 规定引擎统计

InfluxDB 数据库收到数据

EMQX Dashboard 音讯数统计

单台 EMQX 服务器实现了单台服务器 10 万 TPS 的音讯吞吐长久化到 InfluxDB 能力。参考 EMQX+Kafka 架构的测试场景，将 EMQX 的集群节点扩大到 10 台，就能够反对 100 万的 TPS 音讯吞吐能力。

结语

通过本文，咱们介绍了车联网场景音讯吞吐设计须要思考的因素，同时提供了两种较为支流的百万级吞吐平台架构设计计划。面对车联网场景下日益减少的数据量，心愿本文可能为相干团队和开发者在车联网平台设计与开发过程中提供参考。

版权申明：本文为 EMQ 原创，转载请注明出处。

原文链接：https://www.emqx.com/zh/blog/million-level-message-throughput-architecture-design-for-internet-of-vehicles