关于物联网:车联网-TSP-平台场景中的-MQTT-主题设计

本文作者：田桢，前上汽公众平台架构师，现为中科创达汽车云技术负责人

前言

在车联网生态中，TSP（Telematics Service Provider）平台在产业链中居于外围位置，上接汽车、车载设施制造商与网络运营商，下接内容提供商，是主机厂车辆与服务的外围数据连贯平台。随着智能汽车的倒退和车主用户对利用场景需要的一直晋升，主机厂对 TSP 平台的设施与利用承载能力需要将一直减少。

在之前的文章《车联网场景中的 MQTT 协定》咱们提到，在车载设施与 TSP 平台数据交互协定抉择上，MQTT 以其轻量化、易扩大、多种音讯质量保证（QoS），以及通过公布订阅模式实现数据产生与数据生产零碎解偶等劣势成为了目前各大主机厂的新一代 TSP 平台的首选协定。

本文咱们将介绍在车联网 TSP 平台搭建过程中，如何进行 MQTT 音讯主题设计。

车联网 TSP 场景中对音讯通道的需要

车联网 TSP 场景中，MQTT 协定作为「车 - 平台 - 利用」之间的业务音讯通道，不仅要保障车与利用之间音讯能够双向互通互联，而且须要通过肯定规定将不同类型的音讯辨认与散发。而 MQTT 协定中的主题就是这些音讯的标签，也能够看作是业务通道。

在车联网场景中，能够把音讯分为从车 - 平台 - 利用的数据上行通道以及利用 - 平台 - 车的数据上行通道；对于车联网 TSP 平台，不同数据方向意味着不同的业务类型，须要通过 MQTT 主题进行明确的辨别与隔离。

• 从车端角度看：

  在 TSP 平台中车辆数据上报是上行数据的次要业务类型。随着车联网业务的不断丰富，如 T-box 等车载零碎计算能力与通信能力一直加强，车辆数据上报的业务场景、数据量及频率也一直减少。基于业务隔离、实时性与平安等需要，从车联网晚期的一车一主题逐步向一车多音讯通道倒退。

• 从利用侧角度看：

  平台利用作为车辆数据接管与生产方，同时也会作为数据下发，指令下发的音讯发送方。依据业务需要不同，音讯发送类型也能够分为：

  1. 一对一音讯：针对一些如车控㩐要害业务与高安全性要求的业务，须要针对每辆车提供一对一的音讯通道。
  2. 一对多音讯：对于某一类业务或者某一种车型，能够通过雷同主题通道向车机设备进行指令与数据下发。
  3. 音讯播送：针对大规模的音讯告诉，配置更新场景，能够向平台所连设施发送大规模的音讯播送。

什么是 MQTT 协定的主题

根底概念

在 MQTT 协定通信机制中有三个角色：音讯发布者（publisher）、代理服务器（broker）和音讯订阅者（subscriber）。音讯从发布者发送到代理服务器，而后被订阅者接管，而主题就是发布者与订阅者之间约定的音讯通道。

发布者指定的主题发送音讯，订阅者从指定的主题订阅接管音讯，而 Broker 则起到依照主题承受并散发音讯的代理人。在车联网 TSP 平台场景中，车载设施、挪动终端与业务利用都能够被看作是 MQTT 客户端。依据业务不同与数据方向不同，车载设施、挪动终端与业务利用的角色也会在发布者与订阅者之间切换。

主题的定义与标准

MQTT 协定中规定了主题是一段 UTF-8 编码的字符串，主题须要满足以下规定：

• 所有的主题名和主题过滤器必须至多蕴含一个字符。
• 主题名和主题过滤器是大小写敏感的。如：ACCOUNTS 和 Accounts 是不同的主题名。
• 主题名和主题过滤器能够蕴含空格字符。如：Accounts payable 是非法的主题名
• 主题名或主题过滤器以前置或后置斜杠 / 辨别。如：/finance 和 finance 是不同的。
• 只蕴含斜杠 / 的主题名或主题过滤器是非法的。
• 主题名和主题过滤器不能蕴含 null 字符 (Unicode U+0000)。
• 主题名和主题过滤器是 UTF-8 编码字符串，除了不能超过 UTF-8 编码字符串的长度限度之外，主题名或主题过滤器的层级数量没有其它限度。

主题层级

MQTT 协定主题能够通过斜杠（“/”U+002F）将主题宰割成多个层级；作为音讯通道，客户端能够通过定义主题层级来实现对音讯类型的细分；

例如：一个主机厂有多个车型，每个车型上面有多个车联网业务，咱们在定义车机向对某个车型业务零碎发消息时能够向 < 车型 A >/ < 车辆惟一标识 >/< 业务 X > 主题发消息；

当然在 MQTT 世界中主题能够有很多层（MQTT 协定中没有限度层级数量），比方：< 车型 A >/< 车辆惟一标识 (车架号)>/< 业务 X >/< 子业务 1 >

这样，咱们在定义车联网分层级的业务通道的时候能够按主题层级来设计。

通配符

MQTT 协定中订阅者的订阅的主题过滤器能够蕴含非凡的通配符，容许客户端一次订阅多个主题。

• 多层通配符

  \# 字符号（“#”U+0023）是用于匹配主题中任意层级的通配符。多层通配符示意它的父级和任意数量的子层级。如：订阅者能够通过订阅 < 车型 A >/# 接管到：

  < 车型 A >

  < 车型 A >/< 车架号 1 >

  < 车型 A >/< 车架号 1 >/< 业务 X >

  这几类主题的音讯。

• 单层通配符

  加号 (“+”U+002B) 用于单个主题层级匹配的通配符。如：订阅者能够通过订阅 < 车型 A >/+ 来接管

  < 车型 A >/< 车架号 1 >

  < 车型 A >/< 车架号 2 >

  不同于多层通配符，应用单层通配符的时候无奈匹配子层级的主题，比方：< 车型 A >/< 车架号 1 >/< 业务 X > 的主题音讯就无奈接管到。

车联网 TSP 平台主题设计准则最佳实际

前文中咱们提到在车联网场景中 MQTT 主题定义了业务与数据的通道，主题定义的外围是辨别业务场景。如何正当的定义主题，须要依据肯定准则来设计。咱们能够从以下几个维度来设计与定义主题：

依据业务数据方向辨别

首先，数据的上下行方向不同决定了数据由谁产生，被谁生产。在车联网场景中，车载设施到平台的数据上行通道与平台利用到车的上行数据须要通过主题离开。通过对上行、上行主题的设计辨别，能够帮忙设计、运维及业务人员疾速定位场景、问题及相干干系方。

有些业务可能会同时用到上下行主题，比方车辆申请数据下发后平台下发数据，以及平台申请车辆下班数据后车辆上报数据。这种状况下，因为 MQTT 协定的异步通信机制，也须要对一个整体业务的上下行主题别离定义。

依据车型辨别

在车联网场景中，不同车型意味着车辆产生的数据不完全相同，车机能力不完全相同同，对接的业务利用也不尽相同。咱们能够依据车型型号对差异化的车辆数据以及业务进行主题上的辨别。当然，同一个主机厂下的不同车型也会有雷同的业务和数据，这些业务能够通过跨车型的主题来定义。

依据车辆辨别

在车联网场景中，如车控等安全等级较高的业务场景往往须要一对一的主题作为数据通通道。一方面通过主题来隔离车辆与车辆之间的业务信息，另一方面保证数据能够点对点的交互。在主题设计中，有时须要将车辆的惟一标识符作为主题的一部分来实现一对一的音讯通道。常见的计划有应用车辆 VIN 码作为主题的一部分。

依据用户辨别

在理论应用场景中，也存在须要依据用户（而不是车辆）实现车云的一对一的音讯通道，此类需要常常产生在用户促销、经营、ToB 业务等场景中。在主题设计时，常见的计划有两种，一是应用用户 ID 作为主题的一部分；二是通过人 - 车关系转换成车辆级主题，但因为音讯时效性、车内用户登录状态等起因，此计划下生产端及生产端均须要增加额定的设计及解决，绝对简单。

依据研发环境辨别

从我的项目工程施行角度登程，个别在主题设计时同时会增加环境变量，通过配置实现不同研发环境下的资源复用以及正确性查看。

依据数据吞吐量辨别

因为业务的不同，不论是上行数据还是上行数据，数据的发送频率与报文大小都不尽相同。不同的数据吞吐量会影响到生产端的解决以及架构设计，比方咱们在解决高频的车辆数据上报业务时往往要思考应用层的生产能力，这时候可能要借助相似 Kafka 之类的高吞吐音讯队列来进行数据缓冲，避免利用生产不及时造成数据积压与数据失落。所以在 MQTT 主题定义上，咱们往往也须要对不同数据吞吐量的业务进行辨别。

MQTT 协定主题设计在车联网场景中的利用

车辆数据被动上报

车载设施（T-box，车机等）作为车辆运行数据的收集者，基于固定频率将车内各类控制器、传感器等数据打包发送到平台端。此类数据个别能够依照上报数据的车型、车架号、业务数据类型等多个层级进行设计。

例如在用户批准的前提下，车辆在行驶过程中会将地位、车速、电量等信息依照固定频率上报云平台，云端利用基于这些数据，提供地位查找、超速揭示、电量揭示、天文围栏服务给终端用户应用。

平台申请下发后车辆数据上报

当云平台须要获取车辆的最新状态及信息时，能够被动下发命令要求车辆上报数据。此类场景个别能够依照车架号、业务类型等层级进行主题设计。

例如在诊断场景下，平台通过 MQTT 下发诊断命令至车辆，当车内各设施实现诊断操作后，会将诊断数据打包后上报至云平台，车辆诊断工程师将依据采集到的诊断数据对于车况进行整体的剖析及问题定位。

平台指令下发

车辆近程管制是车联网业务中最常见、最典型的场景，各主机厂均在手机 App 中提供各种远控性能，例如近程启动、近程开车门、近程闪灯鸣笛等等。此类场景下，手机 App 发送管制命令至云平台，平台利用通过权限查看、安全检查等一系列操作后，通过 MQTT 将命令下发至车辆执行，车辆端执行胜利后，异步告诉平台执行后果。

此类场景个别能够依照上行上行、车架号、业务类型、操作类型等多个层级进行主题设计。

车辆客户端申请后平台数据下发

在 SDV（软件定义汽车）的大背景下，车内很多配置是能够做到动态变化的，例如数据采集规定、平安拜访规定，所以车辆在点火启动后，会被动申请平台最新的相干配置，若两侧配置不统一，平台侧会下发最新的配置信息至车辆，车辆侧实时失效。

此类场景个别能够依照上行上行、车架号、业务类型等多个层级进行主题设计。

应用 EMQX 进行车联网 TSP 平台主题设计

EMQX 作为寰球当先的 MQTT 物联网消息中间件，基于分布式集群、大规模并发连贯、疾速低延时的音讯路由等突出个性，可能无效解决车联网场景中高时效性业务需要，大幅度缩短端到端时延，为大规模车联网平台疾速部署提供规范的 MQTT 服务。

EMQX 在车联网场景下的劣势

海量主题反对

随着车联网场景中的业务一直减少，承载业务通道的主题数量也一直减少，尤其是包含车控场景所须要的一车一主题、一车多主题需要越来越大。在这种背景下，MQTT 服务器的主题数承载能力就成为了 TSP 平台的重要评估指标。

EMQX 在一开始的底层设计中就布局了对海量设施连贯与海量主题反对的能力。常见的 16 核 32G 内存的 3 节点 EMQX 集群能够反对百万级主题同时运行，为 TSP 平台主题设计提供了灵便的设计空间。

弱小规定引擎

EMQX 提供了内置的规定引擎，基于规定引擎能够提供对不同主题数据的查找、过滤、数据分拆以及对音讯从新路由。应用规定引擎，咱们能够在已有车载设施与利用主题建设好的场景下，通过创立新的路由规定与数据预处理规定对已有主题中的数据进行再解决。在车辆上市后，通过在平台侧定义新规定实现对新业务利用的反对。

在 EMQX 企业版中，规定引擎提供了数据长久化对接能力，能够通过规定引擎中的配置将不同主题中的数据间接对接不同长久化计划。比方对数据吞吐量比拟高的数据能够通过规定引擎对接 Kafka、Apache Pulsar 等高吞吐音讯队列进行数据缓冲；而车辆报警等小吞吐低时延主题数据能够间接对接利用，实现数据的疾速路由生产。

代理订阅性能

EMQX 提供了代理订阅性能，客户端在连贯建设时，不须要发送额定的 SUBSCRIBE 报文，便能主动建设用户预设的订阅关系。这样能够让平台侧间接治理车载设施的主题订阅关系，不便平台侧进行对立治理。

丰盛的主题监控与慢订阅统计

EMQX 企业版提供了以主题为监控维度的运行数据监控，能够在 EMQX 可视化 Dashboard 中清晰看到主题下音讯流入流出、抛弃的总数和以后速率。

自 4.4 版本起，EMQX 提供了对慢订阅的统计。该性能会追踪 QoS1 和 QoS2 音讯达到 EMQX 后，实现音讯传输全流程的工夫耗费，而后采纳指数挪动均匀算法，计算该订阅者的均匀音讯传输时延，之后依照时延高下对订阅者进行统计排名。

通过在 TSP 平台经营过程中一直监控各种主题的数据接管与生产状况，平台运营者就能够依据业务变动一直调整平台业务设计与利用设计，实现平台的一直优化扩大。

须要留神的事项

咱们在应用 EMQX 作为车联网 TSP 平台 MQTT Broker 时，在设计主题的过程中须要留神以下几个问题：

• 通配符应用与主题数层级

  因为 EMQX 采纳主题树的数据结构对主题进行过滤匹配。在应用通配符来匹配多个主题的场景下，如果主题层级十分多，就会对 EMQX 产生比拟大的资源耗费。所以在主题设计时，不倡议层级太多，个别不倡议超过 5 层。

• 主题与内存的耗费

  因为在 EMQX 中主题数与主题长度次要与内存相干，咱们在承载大量主题的同时也要重点监控 EMQX 集群内存的用量。

总结

随着 MQTT 协定在车联网业务中的宽泛遍及，车联网 TSP 平台的 MQTT 音讯主题设计将是各主机厂与 TSP 平台计划供应商必须面对的课题。本文是咱们联合多年 TSP 平台建设教训，针对车联网业务从多维度总结的 MQTT 主题设计思路，心愿可能在平台后期设计与业务扩大阶段给行业同仁一些帮忙与启发。

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

原文链接：https://www.emqx.com/zh/blog/mqtt-topic-design-for-internet-of-vehicles