前言
在之前的文章中，我们提到了车联网 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 百万级吞吐车联网平台：
- 如果公共云商提供的负载均衡产品，可以转发前端车机的连接和消息作为域名转发。 TLS/DTLS 云上可以建立四个安全认证 HAProxy/Nginx 服务器作为证书卸载和负载均衡使用。
- 采用 10 台 EMQX 组满足高可用场景需求的同时，形成一个大集群，节点10万消息，满足高可用场景的需求。
- 如果需要离线/消息缓存，可以选择 Redis 存储数据库。
- Kafka 作为总体消息队列，EMQX 通过规则引擎将所有消息转发给后端 Kafka 集群中。
- 后端 TSP 平台/OTA 通过订阅等应用 Kafka 业务平台的控制指令和推送消息可以通过主题接收相应的消息 Kafka/API 发送的方式 EMQX。
总体架构图
在这个方案架构中，EMQX 作为消息中间件，它具有以下优点，可以满足场景的需要：
- 支持数百万车辆连接和数百万新闻吞吐量。
- 分布式集群架构稳定可靠，支持动态扩展。
- 规则引擎和数据桥接能力强，持久性强，支持百万级新闻吞吐处理。
- 拥有丰富 API 能与认证等系统顺利对接。
验证百万吞吐场景
为了验证上述结构的吞吐量，如果条件允许，我们可以通过以下配置构建数百万的新闻吞吐量测试场景。可选择压力测试工具 Benchmark Tools、JMeter 或 XMeter 测试平台。共模拟 100 万台设备，每台设备都有自己的主题，每台设备每秒发送一次信息，持续压力测量 12 小时。
压力测量架构图如下：
部分性能测试结果呈现：
EMQX 集群 Dashboard 统计
EMQX 每个节点的速度都可以在规则引擎中看到 10 10000/秒的处理速度，10000 个节点总共 100 速度为1000/秒。
EMQX 规则引擎统计
在 Kafka 每秒都能看到 100 万的写入速度，并且一直持续存储。
Kafka 管理界面统计
EMQX InfluxDB 构建百万级吞吐车联网平台
架构设计
采用 EMQX 时序数据库的架构也可以构建百万级新闻吞吐平台。在本文中，我们使用它 InfluxDB 以时序数据库为例。
InfluxDB 广泛应用于存储系统的控数据的高性能时序数据库，IoT 行业实时数据等场景。它从时间维度记录信息，具有很强的写入和存储性能，适用于大数据和数据分析。分析后的数据可以为后台应用程序系统提供数据支持。
通过这个架构 EMQX 规则引擎转发消息，InfluxDB 对接后端大数据和分析平台，可以更方便地为时序分析服务。
- 前端设备造商的负载均衡产品用于域名转发和负载均衡。
- 本次采用 1 台 EMQX 作为测试，在后续需要时可以使用多节点形成相应的集群方案(测试 100 万可以部署 10 台 EMQX 集群）。
- 如有离线离线/消息缓存需求，可选用 Redis 存储数据库。
- EMQX 通过规则引擎将所有信息转发给后端InfluxDB持久存储数据。
- 通过后端大数据平台 InfluxDB 接收相应的信息，分析大数据，然后通过分析 API 将所需信息传输到 EMQX。
总体架构图
场景验证
如测试架构图所示，XMeter 压力机模拟 10 万 MQTT 客户端向 EMQX 启动连接，新连接速率为每秒 1万，客户端心跳间隔(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