本文作者：田震，原上汽大众平台架构师，现为中科迅雷云技术负责人
前言
在车联网生态系统中，TSP（Telematics Service Provider）平台在产业链中占据核心地位。它连接到汽车、车载设备制造商和网络运营商以及内容提供商。它是OEM车辆和服务之间的核心数据连接。平台。随着智能汽车的发展，以及车主和用户对应用场景需求的不断提升，主机厂对TSP平台的设备和应用承载能力的需求将不断增加。
在上一篇《车联网场景下的MQTT协议》中，我们提到在车载设备与TSP平台的数据交互协议的选择上，MQTT轻量级，易于扩展，多种消息质量保证（QoS )，并通过发布订阅模式实现数据生成和数据消费系统解耦的优势，成为各大主机厂新一代TSP平台的首选协议。
本文将介绍在车联网TSP平台建设过程中如何设计MQTT消息主题。
车联网TSP场景下对消息通道的需求
在车联网的TSP场景中，MQTT协议作为“车-平台-应用”之间的业务消息通道收到无主题信息，不仅保证了车与应用之间的消息可以双向互通，但也需要通过一定的规则来识别和分发不同类型的消息。. MQTT协议中的topic就是这些消息的标签，也可以看成是一个业务通道。
在车联网场景中，消息可以分为来自车辆-平台-应用的数据上行通道和来自应用-平台-车辆的数据下行通道；对于车联网TSP平台来说，不同的数据方向意味着不同的业务类型，需要通过。MQTT 主题被明确区分和隔离。
MQTT协议主体的基本概念有哪些
MQTT协议通信机制中存在三种角色：消息发布者（publisher）、代理服务器（broker）和消息订阅者（subscriber）。消息从发布者发送到代理服务器，然后被订阅者接收，主题是发布者和订阅者约定的消息通道。
发布者指定的主题发送消息，订阅者订阅接收来自指定主题的消息，代理充当代理，根据主题接受和分发消息。在车联网 TSP 平台场景中，车载设备、移动终端和业务应用都可以视为 MQTT 客户端。根据不同的服务和不同的数据方向，车载设备、移动终端和服务应用的角色也会在发布者和订阅者之间切换。
学科定义和规范
MQTT 协议规定主题是 UTF-8 编码的字符串，主题需要满足以下规则：
主题层次结构
MQTT 协议主题可以通过斜线（“/”U+002F）分为多个级别；作为消息通道，客户端可以通过定义主题级别来细分消息类型；
例如：一个OEM有多个车型，每个车型都有多个车联网服务。我们可以在定义车机向某个型号的业务系统发送消息时，向 //subject 发送消息；
当然在 MQTT 世界中，一个主题可以有很多层（MQTT 协议中没有层数限制），例如：///
这样，我们在定义车联网的分层业务渠道时，就可以根据主题层次进行设计。
通配符
MQTT 协议中订阅者订阅的主题过滤器可以包含特殊的通配符，允许客户端一次订阅多个主题。
车联网TSP平台主题设计原则最佳实践
在上一篇文章中，我们提到在车联网场景中，MQTT 主题定义了业务和数据的通道。主题定义的核心是区分业务场景。如何合理界定主题，需要按照一定的原则进行设计。我们可以从以下维度设计和定义主题：
根据业务数据方向区分
首先，数据的上下游不同方向决定了谁产生和消费数据。在车联网场景下，车载设备到平台的数据上行通道和平台应用到汽车的下行数据需要按主题进行分离。通过区分上下游主题的设计，可以帮助设计、运维和业务人员快速定位场景、问题和相关的利益相关者。
有的业务可能会同时使用上下行主题，比如车辆应用数据下发后平台下发的数据，平台请求车辆上班后车辆上报的数据。在这种情况下，由于 MQTT 协议的异步通信机制，一个整体业务的上下游主题也需要单独定义。
按型号区分
在车联网场景下，不同车型意味着车辆产生的数据不一样，车辆的能力不一样，连接的业务应用也不一样。我们可以根据模型模型对差异化的车辆数据和业务进行主题区分。当然，同一个OEM下的不同车型也会有相同的业务和数据，而这些业务可以通过跨车型主题来定义。
按车辆区分
在车联网场景中，车控等安全级别较高的业务场景，往往需要一对一的话题作为数据沟通渠道。一方面，车辆之间的业务信息通过主题进行隔离，另一方面，数据可以点对点交互。在主题设计中，有时需要实现一对一的消息通道，将车辆的唯一标识符作为主题的一部分。一个常见的场景是使用车辆 VIN 号码作为主题的一部分。
按用户区分
在实际使用场景中，还有一对一的消息通道，需要基于用户（而不是车辆）到云端实现。此类需求经常出现在用户推广、运营、ToB服务等场景中。在设计主题时，有两种常见的解决方案。一是使用用户ID作为主题的一部分；另一种是通过人车关系将其转化为车级主题。在该方案下，生产端和消费端都需要增加额外的设计和加工，相对复杂。
根据研发环境
从项目工程实施的角度来看，环境变量一般在主题设计时加入，通过配置可以实现不同研发环境下的资源复用和正确性检查。
根据数据吞吐量进行区分
由于业务不同，无论是上行数据还是下行数据，数据发送频率和包大小都不一样。不同的数据吞吐量会影响消费者的处理和架构设计。例如收到无主题信息，我们在处理高频车辆数据上报服务时，往往需要考虑应用层的消耗能力。这时候我们可能会用到Kafka等高吞吐量的消息队列。缓冲数据，防止应用程序消费不及时造成数据积压和数据丢失。因此，在定义 MQTT 主题时，我们经常需要区分不同数据吞吐量的服务。
MQTT协议主题设计在车联网场景中的应用 车辆数据主动上报
车载设备（T-box、车机等）作为车辆运行数据的采集器，将车内各种控制器和传感器的数据按固定频率打包发送到平台。这类数据一般可以多层次设计，如上报数据的型号、帧号、业务数据类型等。
例如，在用户同意的前提下，车辆在行驶过程中会按照固定频率向云平台上报位置、速度、电量等信息。用户使用。
平台请求发出后的车辆数据报告
当云平台需要获取车辆的最新状态和信息时，可以主动下达指令，要求车辆上报数据。此类场景一般可以根据帧数、业务类型等层次进行主题设计。
例如，在诊断场景中，平台通过MQTT向车辆发送诊断命令。车内各设备完成诊断操作后，将诊断数据打包上报至云平台。车辆诊断工程师将根据收集到的诊断数据进行诊断。整体分析和问题定位。
平台指令发布
车载远程控制是车联网业务中最常见、最典型的场景。各大主机厂均在手机APP中提供各种远程控制功能，如远程启动、远程开门、远程闪灯和喇叭等。在这种情况下，移动应用程序向云平台发送控制命令。平台应用经过权限检查、安全检查等一系列操作后，通过MQTT发送命令到车辆执行。车辆执行成功后，异步通知平台执行结果。
这样的场景一般可以根据上下行、帧数、业务类型、运营类型等多个层次进行设计。
车辆客户端请求后下发平台数据
在 SDV（软件定义车辆）的上下文中，汽车中的许多配置都可以动态更改，例如数据收集规则和安全访问规则。因此，车辆点火后，会主动请求平台最新的相关配置。如果双方配置不一致，平台侧会向车辆发送最新的配置信息，车辆侧实时生效。
这样的场景一般可以根据上下行、帧数、业务类型等多个层次进行设计。
使用 EMQX 进行车联网 TSP 平台的主题设计
作为全球领先的 MQTT 物联网消息中间件，EMQX 基于分布式集群、大规模并发连接、快速低延迟消息路由等突出特性。端到端延迟，为大规模车联网平台的快速部署提供标准的MQTT服务。
EMQX 在车联网场景中的优势 海量话题支持
随着车联网场景业务的不断增加，承载业务渠道的话题也越来越多，尤其是车控场景所需的一车一话题、一车多话题的需求越来越大。在此背景下，MQTT服务器的话题承载能力成为TSP平台的重要评价指标。
EMQX 在最初的底层设计中已经规划了支持海量设备连接和海量话题的能力。一个普通的16核32G内存3节点EMQX集群可以支持百万主题同时运行，为TSP平台的主题设计提供了灵活的设计空间。
强大的规则引擎
EMQX 提供了内置的规则引擎，可以基于规则引擎对不同的主题数据进行搜索、过滤、数据拆分、消息重路由。使用规则引擎，我们可以在现有车载设备和应用主题已经建立的场景下，通过创建新的路由规则和数据预处理规则，对现有主题中的数据进行再处理。车辆上市后，通过在平台端定义新规则，实现对新业务应用的支持。
在 EMQX 企业版中，规则引擎提供了数据持久化对接能力，不同主题的数据可以通过规则引擎中的配置直接对接不同的持久化方案。比如数据吞吐量比较高的数据可以通过规则引擎连接到Kafka、Apache Pulsar等高吞吐量的消息队列中进行数据缓冲；并且可以将车辆报警等小吞吐量、低延迟的话题数据直接接入应用，实现数据的快速路由和消费。
