前言

在車聯(lián)網(wǎng)生態(tài)中，TSP(Telematics Service Provider)平臺在產(chǎn)業(yè)鏈中居于核心地位，上接汽車、車載設(shè)備制造商與網(wǎng)絡(luò)運營商，下接內(nèi)容提供商，是主機廠車輛與服務的核心數(shù)據(jù)連接平臺。隨著智能汽車的發(fā)展和車主用戶對應用場景需求的不斷提升，主機廠對TSP平臺的設(shè)備與應用承載能力需求將不斷增加。

在之前的文章《??車聯(lián)網(wǎng)場景中的MQTT協(xié)議??》我們提到，在車載設(shè)備與TSP平臺數(shù)據(jù)交互協(xié)議選擇上，MQTT以其輕量化、易擴展、多種消息質(zhì)量保證(QoS)，以及通過發(fā)布訂閱模式實現(xiàn)數(shù)據(jù)產(chǎn)生與數(shù)據(jù)消費系統(tǒng)解偶等優(yōu)勢成為了目前各大主機廠的新一代TSP平臺的首選協(xié)議。

本文我們將介紹在車聯(lián)網(wǎng)TSP平臺搭建過程中，如何進行MQTT消息主題設(shè)計。

車聯(lián)網(wǎng)TSP場景中對消息通道的需求

車聯(lián)網(wǎng)TSP場景中，MQTT協(xié)議作為「車-平臺-應用」之間的業(yè)務消息通道，不僅要保證車與應用之間消息可以雙向互通互聯(lián)，而且需要通過一定規(guī)則將不同類型的消息識別與分發(fā)。而MQTT協(xié)議中的主題就是這些消息的標簽，也可以看作是業(yè)務通道。

在車聯(lián)網(wǎng)場景中，可以把消息分為從車-平臺-應用的數(shù)據(jù)上行通道以及應用-平臺-車的數(shù)據(jù)下行通道;對于車聯(lián)網(wǎng)TSP平臺，不同數(shù)據(jù)方向意味著不同的業(yè)務類型，需要通過MQTT主題進行明確的區(qū)分與隔離。

(1)從車端角度看：

在TSP平臺中車輛數(shù)據(jù)上報是上行數(shù)據(jù)的主要業(yè)務類型。隨著車聯(lián)網(wǎng)業(yè)務的不斷豐富，如T-box等車載系統(tǒng)計算能力與通訊能力不斷增強，車輛數(shù)據(jù)上報的業(yè)務場景、數(shù)據(jù)量及頻率也不斷增加?；跇I(yè)務隔離、實時性與安全等需求，從車聯(lián)網(wǎng)早期的一車一主題逐漸向一車多消息通道發(fā)展。

(2)從應用側(cè)角度看：

平臺應用作為車輛數(shù)據(jù)接收與消費方，同時也會作為數(shù)據(jù)下發(fā)，指令下發(fā)的消息發(fā)送方。根據(jù)業(yè)務需求不同，消息發(fā)送類型也可以分為：

一對一消息：針對一些如車控?關(guān)鍵業(yè)務與高安全性要求的業(yè)務，需要針對每輛車提供一對一的消息通道。

一對多消息：對于某一類業(yè)務或者某一種車型，可以通過相同主題通道向車機設(shè)備進行指令與數(shù)據(jù)下發(fā)。

消息廣播：針對大規(guī)模的消息通知，配置更新場景，可以向平臺所連設(shè)備發(fā)送大規(guī)模的消息廣播。

什么是MQTT協(xié)議的主題

基礎(chǔ)概念

在MQTT協(xié)議通信機制中有三個角色：消息發(fā)布者(publisher)、代理服務器(broker)和消息訂閱者(subscriber)。消息從發(fā)布者發(fā)送到代理服務器，然后被訂閱者接收，而主題就是發(fā)布者與訂閱者之間約定的消息通道。

發(fā)布者指定的主題發(fā)送消息，訂閱者從指定的主題訂閱接收消息，而Broker則起到按照主題接受并分發(fā)消息的代理人。在車聯(lián)網(wǎng)TSP平臺場景中，車載設(shè)備、移動終端與業(yè)務應用都可以被看作是MQTT客戶端。根據(jù)業(yè)務不同與數(shù)據(jù)方向不同，車載設(shè)備、移動終端與業(yè)務應用的角色也會在發(fā)布者與訂閱者之間切換。

主題的定義與規(guī)范

MQTT協(xié)議中規(guī)定了主題是一段UTF-8編碼的字符串，主題需要滿足以下規(guī)則：

所有的主題名和主題過濾器必須至少包含一個字符。

主題名和主題過濾器是大小寫敏感的。如：ACCOUNTS和Accounts是不同的主題名。

主題名和主題過濾器可以包含空格字符。如：Accounts payable是合法的主題名

主題名或主題過濾器以前置或后置斜杠/區(qū)分。如：/finance和finance是不同的。

只包含斜杠/的主題名或主題過濾器是合法的。

主題名和主題過濾器不能包含null字符(Unicode U+0000)。

主題名和主題過濾器是UTF-8編碼字符串，除了不能超過UTF-8編碼字符串的長度限制之外，主題名或主題過濾器的層級數(shù)量沒有其它限制。

主題層級

MQTT協(xié)議主題可以通過斜杠(“/” U+002F)將主題分割成多個層級;作為消息通道，客戶端可以通過定義主題層級來實現(xiàn)對消息類型的細分;

例如：一個主機廠有多個車型，每個車型下面有多個車聯(lián)網(wǎng)業(yè)務，我們在定義車機向?qū)δ硞€車型業(yè)務系統(tǒng)發(fā)消息時可以向<車型A>/<車輛唯一標識>/<業(yè)務X>主題發(fā)消息;

當然在MQTT世界中主題可以有很多層(MQTT協(xié)議中沒有限制層級數(shù)量)，比如：<車型A>/<車輛唯一標識(車架號)>/<業(yè)務X>/<子業(yè)務1>；

這樣，我們在定義車聯(lián)網(wǎng)分層級的業(yè)務通道的時候可以按主題層級來設(shè)計。

通配符

MQTT協(xié)議中訂閱者的訂閱的主題過濾器可以包含特殊的通配符，允許客戶端一次訂閱多個主題。

(1)多層通配符

/#字符號(“#”U+0023)是用于匹配主題中任意層級的通配符。多層通配符表示它的父級和任意數(shù)量的子層級。如：訂閱者可以通過訂閱<車型A>/#接收到：

<車型A>

<車型A>/<車架號1>

<車型A>/<車架號1>/<業(yè)務X>

這幾類主題的消息。

(2)單層通配符

加號(“+”U+002B)用于單個主題層級匹配的通配符。如：訂閱者可以通過訂閱<車型A>/+來接收：

<車型A>/<車架號1>

<車型A>/<車架號2>

不同于多層通配符，使用單層通配符的時候無法匹配子層級的主題，比如：<車型A>/<車架號1>/<業(yè)務X>的主題消息就無法接收到。

車聯(lián)網(wǎng)TSP平臺主題設(shè)計原則最佳實踐

前文中我們提到在車聯(lián)網(wǎng)場景中MQTT主題定義了業(yè)務與數(shù)據(jù)的通道，主題定義的核心是區(qū)分業(yè)務場景。如何合理的定義主題，需要根據(jù)一定原則來設(shè)計。我們可以從以下幾個維度來設(shè)計與定義主題：

根據(jù)業(yè)務數(shù)據(jù)方向區(qū)分

首先，數(shù)據(jù)的上下行方向不同決定了數(shù)據(jù)由誰產(chǎn)生，被誰消費。在車聯(lián)網(wǎng)場景中，車載設(shè)備到平臺的數(shù)據(jù)上行通道與平臺應用到車的下行數(shù)據(jù)需要通過主題分開。通過對上行、下行主題的設(shè)計區(qū)分，可以幫助設(shè)計、運維及業(yè)務人員快速定位場景、問題及相關(guān)干系方。

有些業(yè)務可能會同時用到上下行主題，比如車輛申請數(shù)據(jù)下發(fā)后平臺下發(fā)數(shù)據(jù)，以及平臺請求車輛上班數(shù)據(jù)后車輛上報數(shù)據(jù)。這種情況下，由于MQTT協(xié)議的異步通訊機制，也需要對一個整體業(yè)務的上下行主題分別定義。

根據(jù)車型區(qū)分

在車聯(lián)網(wǎng)場景中，不同車型意味著車輛產(chǎn)生的數(shù)據(jù)不完全相同，車機能力不完全相同同，對接的業(yè)務應用也不盡相同。我們可以根據(jù)車型型號對差異化的車輛數(shù)據(jù)以及業(yè)務進行主題上的區(qū)分。當然，同一個主機廠下的不同車型也會有相同的業(yè)務和數(shù)據(jù)，這些業(yè)務可以通過跨車型的主題來定義。

根據(jù)車輛區(qū)分

在車聯(lián)網(wǎng)場景中，如車控等安全等級較高的業(yè)務場景往往需要一對一的主題作為數(shù)據(jù)通通道。一方面通過主題來隔離車輛與車輛之間的業(yè)務信息，另一方面保證數(shù)據(jù)可以點對點的交互。在主題設(shè)計中，有時需要將車輛的唯一標識符作為主題的一部分來實現(xiàn)一對一的消息通道。常見的方案有使用車輛VIN碼作為主題的一部分。

根據(jù)用戶區(qū)分

在實際使用場景中，也存在需要根據(jù)用戶(而不是車輛)實現(xiàn)車云的一對一的消息通道，此類需求經(jīng)常發(fā)生在用戶促銷、運營、ToB業(yè)務等場景中。在主題設(shè)計時，常見的方案有兩種，一是使用用戶ID作為主題的一部分;二是通過人-車關(guān)系轉(zhuǎn)換成車輛級主題，但由于消息時效性、車內(nèi)用戶登錄狀態(tài)等原因，此方案下生產(chǎn)端及消費端均需要添加額外的設(shè)計及處理，相對復雜。

根據(jù)研發(fā)環(huán)境區(qū)分

從項目工程實施角度出發(fā)，一般在主題設(shè)計時同時會添加環(huán)境變量，通過配置實現(xiàn)不同研發(fā)環(huán)境下的資源復用以及正確性檢查。

根據(jù)數(shù)據(jù)吞吐量區(qū)分

由于業(yè)務的不同，不管是上行數(shù)據(jù)還是下行數(shù)據(jù)，數(shù)據(jù)的發(fā)送頻率與報文大小都不盡相同。不同的數(shù)據(jù)吞吐量會影響到消費端的處理以及架構(gòu)設(shè)計，比如我們在處理高頻的車輛數(shù)據(jù)上報業(yè)務時往往要考慮應用層的消費能力，這時候可能要借助類似Kafka之類的高吞吐消息隊列來進行數(shù)據(jù)緩沖，防止應用消費不及時造成數(shù)據(jù)積壓與數(shù)據(jù)丟失。所以在MQTT主題定義上，我們往往也需要對不同數(shù)據(jù)吞吐量的業(yè)務進行區(qū)分。

MQTT協(xié)議主題設(shè)計在車聯(lián)網(wǎng)場景中的應用

車輛數(shù)據(jù)主動上報

車載設(shè)備(T-box，車機等)作為車輛運行數(shù)據(jù)的收集者，基于固定頻率將車內(nèi)各類控制器、傳感器等數(shù)據(jù)打包發(fā)送到平臺端。此類數(shù)據(jù)一般可以按照上報數(shù)據(jù)的車型、車架號、業(yè)務數(shù)據(jù)類型等多個層級進行設(shè)計。

例如在用戶同意的前提下，車輛在行駛過程中會將位置、車速、電量等信息按照固定頻率上報云平臺，云端應用基于這些數(shù)據(jù)，提供位置查找、超速提醒、電量提醒、地理圍欄服務給終端用戶使用。

平臺請求下發(fā)后車輛數(shù)據(jù)上報

當云平臺需要獲取車輛的最新狀態(tài)及信息時，可以主動下發(fā)命令要求車輛上報數(shù)據(jù)。此類場景一般可以按照車架號、業(yè)務類型等層級進行主題設(shè)計。

例如在診斷場景下，平臺通過MQTT下發(fā)診斷命令至車輛，當車內(nèi)各設(shè)備完成診斷操作后，會將診斷數(shù)據(jù)打包后上報至云平臺，車輛診斷工程師將根據(jù)采集到的診斷數(shù)據(jù)對于車況進行整體的分析及問題定位。

平臺指令下發(fā)

車輛遠程控制是車聯(lián)網(wǎng)業(yè)務中最常見、最典型的場景，各主機廠均在手機App中提供各種遠控功能，例如遠程啟動、遠程開車門、遠程閃燈鳴笛等等。此類場景下，手機App發(fā)送控制命令至云平臺，平臺應用經(jīng)過權(quán)限檢查、安全檢查等一系列操作后，通過MQTT將命令下發(fā)至車輛執(zhí)行，車輛端執(zhí)行成功后，異步通知平臺執(zhí)行結(jié)果。

此類場景一般可以按照上行下行、車架號、業(yè)務類型、操作類型等多個層級進行主題設(shè)計。

車輛客戶端請求后平臺數(shù)據(jù)下發(fā)

在SDV(軟件定義汽車)的大背景下，車內(nèi)很多配置是可以做到動態(tài)變化的，例如數(shù)據(jù)采集規(guī)則、安全訪問規(guī)則，所以車輛在點火啟動后，會主動請求平臺最新的相關(guān)配置，若兩側(cè)配置不一致，平臺側(cè)會下發(fā)最新的配置信息至車輛，車輛側(cè)實時生效。

此類場景一般可以按照上行下行、車架號、業(yè)務類型等多個層級進行主題設(shè)計。

使用EMQX進行車聯(lián)網(wǎng)TSP平臺主題設(shè)計

EMQX作為全球領(lǐng)先的MQTT物聯(lián)網(wǎng)消息中間件，基于分布式集群、大規(guī)模并發(fā)連接、快速低延時的消息路由等突出特性，能夠有效處理車聯(lián)網(wǎng)場景中高時效性業(yè)務需求，大幅度縮短端到端時延，為大規(guī)模車聯(lián)網(wǎng)平臺快速部署提供標準的MQTT服務。

EMQX在車聯(lián)網(wǎng)場景下的優(yōu)勢

(1)海量主題支持

隨著車聯(lián)網(wǎng)場景中的業(yè)務不斷增加，承載業(yè)務通道的主題數(shù)量也不斷增加，尤其是包括車控場景所需要的一車一主題、一車多主題需求越來越大。在這種背景下，MQTT服務器的主題數(shù)承載能力就成為了TSP平臺的重要評估指標。

EMQX在一開始的底層設(shè)計中就規(guī)劃了對海量設(shè)備連接與海量主題支持的能力。常見的16核32G內(nèi)存的3節(jié)點EMQX集群可以支持百萬級主題同時運行，為TSP平臺主題設(shè)計提供了靈活的設(shè)計空間。

(2)強大規(guī)則引擎

EMQX提供了內(nèi)置的規(guī)則引擎，基于規(guī)則引擎可以提供對不同主題數(shù)據(jù)的查找、過濾、數(shù)據(jù)分拆以及對消息重新路由。使用規(guī)則引擎，我們可以在已有車載設(shè)備與應用主題建立好的場景下，通過創(chuàng)建新的路由規(guī)則與數(shù)據(jù)預處理規(guī)則對已有主題中的數(shù)據(jù)進行再處理。在車輛上市后，通過在平臺側(cè)定義新規(guī)則實現(xiàn)對新業(yè)務應用的支持。

在EMQX企業(yè)版中，規(guī)則引擎提供了數(shù)據(jù)持久化對接能力，可以通過規(guī)則引擎中的配置將不同主題中的數(shù)據(jù)直接對接不同持久化方案。比如對數(shù)據(jù)吞吐量比較高的數(shù)據(jù)可以通過規(guī)則引擎對接Kafka、Apache Pulsar等高吞吐消息隊列進行數(shù)據(jù)緩沖;而車輛報警等小吞吐低時延主題數(shù)據(jù)可以直接對接應用，實現(xiàn)數(shù)據(jù)的快速路由消費。

(3)代理訂閱功能

EMQX提供了代理訂閱功能，客戶端在連接建立時，不需要發(fā)送額外的SUBSCRIBE報文，便能自動建立用戶預設(shè)的訂閱關(guān)系。這樣可以讓平臺側(cè)直接管理車載設(shè)備的主題訂閱關(guān)系，方便平臺側(cè)進行統(tǒng)一管理。

(4)豐富的主題監(jiān)控與慢訂閱統(tǒng)計

EMQX企業(yè)版提供了以主題為監(jiān)控維度的運行數(shù)據(jù)監(jiān)控，可以在EMQX可視化Dashboard中清晰看到主題下消息流入流出、丟棄的總數(shù)和當前速率。

自4.4版本起，EMQX提供了對慢訂閱的統(tǒng)計。該功能會追蹤QoS1和QoS2消息到達EMQX后，完成消息傳輸全流程的時間消耗，然后采用指數(shù)移動平均算法，計算該訂閱者的平均消息傳輸時延，之后按照時延高低對訂閱者進行統(tǒng)計排名。

通過在TSP平臺運營過程中不斷監(jiān)控各種主題的數(shù)據(jù)接收與消費情況，平臺運營者就可以根據(jù)業(yè)務變化不斷調(diào)整平臺業(yè)務設(shè)計與應用設(shè)計，實現(xiàn)平臺的不斷優(yōu)化擴展。

需要注意的事項

我們在使用EMQX作為車聯(lián)網(wǎng)TSP平臺MQTTBroker時，在設(shè)計主題的過程中需要注意以下幾個問題：

(1)通配符使用與主題數(shù)層級

由于EMQX采用主題樹的數(shù)據(jù)結(jié)構(gòu)對主題進行過濾匹配。在使用通配符來匹配多個主題的場景下，如果主題層級非常多，就會對EMQX產(chǎn)生比較大的資源消耗。所以在主題設(shè)計時，不建議層級太多，一般不建議超過5層。

(2)主題與內(nèi)存的消耗

由于在EMQX中主題數(shù)與主題長度主要與內(nèi)存相關(guān)，我們在承載大量主題的同時也要重點監(jiān)控EMQX集群內(nèi)存的用量。

總結(jié)

隨著MQTT協(xié)議在車聯(lián)網(wǎng)業(yè)務中的廣泛普及，車聯(lián)網(wǎng)TSP平臺的MQTT消息主題設(shè)計將是各主機廠與TSP平臺方案供應商必須面對的課題。本文是我們結(jié)合多年TSP平臺建設(shè)經(jīng)驗，針對車聯(lián)網(wǎng)業(yè)務從多維度總結(jié)的MQTT主題設(shè)計思路，希望能夠在平臺前期設(shè)計與業(yè)務擴展階段給行業(yè)同仁一些幫助與啟發(fā)。