前言

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

在之前的文章《??車聯網場景中的 MQTT 協議??》我們提到，在車載設備與 TSP 平臺數據交互協議選擇上， MQTT 以其輕量化、易擴展、多種消息質量保證(QoS)，以及通過發布訂閱模式實現數據產生與數據消費系統解偶等優勢成為了目前各大主機廠的新一代 TSP 平臺的首選協議。

本文我們將介紹在車聯網 TSP 平臺搭建過程中，如何進行 MQTT 消息主題設計。

車聯網 TSP 場景中對消息通道的需求

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

在車聯網場景中，可以把消息分為從車-平臺-應用的數據上行通道以及應用-平臺-車的數據下行通道;對于車聯網 TSP 平臺，不同數據方向意味著不同的業務類型，需要通過 MQTT 主題進行明確的區分與隔離。

(1) 從車端角度看：

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

(2) 從應用側角度看：

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

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

什么是 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 協議中訂閱者的訂閱的主題過濾器可以包含特殊的通配符，允許客戶端一次訂閱多個主題。

(1) 多層通配符

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

• <車型A>
• <車型A>/<車架號1>
• <車型A>/<車架號1>/<業務X>

這幾類主題的消息。

(2) 單層通配符

加號 (“+” 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 在車聯網場景下的優勢

(1) 海量主題支持

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

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

(2) 強大規則引擎

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

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

(3) 代理訂閱功能

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

(4) 豐富的主題監控與慢訂閱統計

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

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

通過在 TSP 平臺運營過程中不斷監控各種主題的數據接收與消費情況，平臺運營者就可以根據業務變化不斷調整平臺業務設計與應用設計，實現平臺的不斷優化擴展。

需要注意的事項

我們在使用 EMQX 作為車聯網 TSP 平臺 MQTT Broker 時，在設計主題的過程中需要注意以下幾個問題：

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

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

(2) 主題與內存的消耗

由于在 EMQX 中主題數與主題長度主要與內存相關，我們在承載大量主題的同時也要重點監控 EMQX 集群內存的用量。

總結

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