前言

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

在之前的文章《??車聯(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īng)用」之間的業(yè)務(wù)消息通道，不僅要保證車與應(yīng)用之間消息可以雙向互通互聯(lián)，而且需要通過一定規(guī)則將不同類型的消息識別與分發(fā)。而 MQTT 協(xié)議中的主題就是這些消息的標(biāo)簽，也可以看作是業(yè)務(wù)通道。

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

(1) 從車端角度看：

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

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

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

• 一對一消息：針對一些如車控?關(guān)鍵業(yè)務(wù)與高安全性要求的業(yè)務(wù)，需要針對每輛車提供一對一的消息通道。
• 一對多消息：對于某一類業(yè)務(wù)或者某一種車型，可以通過相同主題通道向車機設(shè)備進行指令與數(shù)據(jù)下發(fā)。
• 消息廣播：針對大規(guī)模的消息通知，配置更新場景，可以向平臺所連設(shè)備發(fā)送大規(guī)模的消息廣播。

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

基礎(chǔ)概念

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

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

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

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

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

通配符

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

(1) 多層通配符

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

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

這幾類主題的消息。

(2) 單層通配符

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

平臺指令下發(fā)

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

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

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

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

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

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

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

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

(1) 海量主題支持

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

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è)備與應(yīng)用主題建立好的場景下，通過創(chuàng)建新的路由規(guī)則與數(shù)據(jù)預(yù)處理規(guī)則對已有主題中的數(shù)據(jù)進行再處理。在車輛上市后，通過在平臺側(cè)定義新規(guī)則實現(xiàn)對新業(yè)務(wù)應(yīng)用的支持。

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

(3) 代理訂閱功能

EMQX 提供了代理訂閱功能，客戶端在連接建立時，不需要發(fā)送額外的 SUBSCRIBE 報文，便能自動建立用戶預(yù)設(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ù)和當(dāng)前速率。

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

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

需要注意的事項

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