> 本文作者：田楨，前上汽大眾平臺架構師，現為中科創達汽車雲技術負責人

## 前言

在車聯網生態中，TSP（Telematics Service Provider）平臺在產業鏈中居於核心地位，上接汽車、車載裝置製造商與網路運營商，下接內容提供商，是主機廠車輛與服務的核心資料連線平臺。隨著智慧汽車的發展和車主使用者對應用場景需求的不斷提升，主機廠對 TSP 平臺的裝置與應用承載能力需求將不斷增加。

在之前的文章《[車聯網場景中的 MQTT 協議](https://www.emqx.com/zh/blog/mqtt-for-internet-of-vehicles)》我們提到，在車載裝置與 TSP 平臺資料互動協議選擇上，[MQTT](https://www.emqx.com/zh/mqtt) 以其輕量化、易擴充套件、多種訊息質量保證（QoS），以及透過釋出訂閱模式實現資料產生與資料消費系統解偶等優勢成為了目前各大主機廠的新一代 TSP 平臺的首選協議。

本文我們將介紹在車聯網 TSP 平臺搭建過程中，如何進行 [MQTT 訊息主題](https://www.emqx.com/zh/blog/advanced-features-of-mqtt-topics)設計。

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

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

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

- 從車端角度看：

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

- 從應用側角度看：

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

1. 一對一訊息：針對一些如車控㩐關鍵業務與高安全性要求的業務，需要針對每輛車提供一對一的訊息通道。
  2. 一對多訊息：對於某一類業務或者某一種車型，可以透過相同主題通道向車機裝置進行指令與資料下發。
  3. 訊息廣播：針對大規模的訊息通知，配置更新場景，可以向平臺所連裝置傳送大規模的訊息廣播。

## 什麼是 MQTT 協議的主題

### 基礎概念

在 MQTT 協議通訊機制中有三個角色： 訊息釋出者（publisher）、代理伺服器（broker）和訊息訂閱者（subscriber）。訊息從釋出者傳送到代理伺服器，然後被訂閱者接收，而主題就是釋出者與訂閱者之間約定的訊息通道。

[![車聯網中的 MQTT](http://img.blog.itpub.net/blog/2022/03/14/09da8fc5b0aeb3b1.png?x-oss-process=style/bb "車聯網中的 MQTT")](https://www.emqx.com/zh/blog/mqtt-topic-design-for-internet-of-vehicles "車聯網中的 MQTT")

釋出者指定的主題傳送訊息，訂閱者從指定的主題訂閱接收訊息，而 Broker 則起到按照主題接受並分發訊息的代理人。在車聯網 TSP 平臺場景中，車載裝置、移動終端與業務應用都可以被看作是 [MQTT 客戶端](https://www.emqx.io/zh/mqtt-client)。根據業務不同與資料方向不同，車載裝置、移動終端與業務應用的角色也會在釋出者與訂閱者之間切換。

### 主題的定義與規範

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

- 所有的主題名和主題過濾器必須至少包含一個字元。
- 主題名和主題過濾器是大小寫敏感的。如：ACCOUNTS 和 Accounts 是不同的主題名。
- 主題名和主題過濾器可以包含空格字元。如：Accounts payable 是合法的主題名
- 主題名或主題過濾器以前置或後置斜槓 / 區分。如：/finance 和 finance 是不同的。
- 只包含斜槓 / 的主題名或主題過濾器是合法的。
- 主題名和主題過濾器不能包含 null 字元(Unicode U+0000)。
- 主題名和主題過濾器是 UTF-8 編碼字串，除了不能超過 UTF-8 編碼字串的長度限制之外，主題名或主題過濾器的層級數量沒有其它限制。

### 主題層級

MQTT 協議主題可以透過斜槓（“/” U+002F）將主題分割成多個層級；作為訊息通道，客戶端可以透過定義主題層級來實現對訊息型別的細分；

例如：一個主機廠有多個車型，每個車型下面有多個車聯網業務，我們在定義車機向對某個車型業務系統發訊息時可以向/ /主題發訊息；

當然在 MQTT 世界中主題可以有很多層（MQTT 協議中沒有限制層級數量），比如：///

這樣，我們在定義車聯網分層級的業務通道的時候可以按主題層級來設計。

### 萬用字元

MQTT 協議中訂閱者的訂閱的主題過濾器可以包含特殊的萬用字元，允許客戶端一次訂閱多個主題。

- 多層萬用字元

\#字元號（“#” U+0023）是用於匹配主題中任意層級的萬用字元。多層萬用字元表示它的父級和任意數量的子層級。如：訂閱者可以透過訂閱/# 接收到：

/

//

這幾類主題的訊息。

- 單層萬用字元

加號 (“+” U+002B) 用於單個主題層級匹配的萬用字元。如：訂閱者可以透過訂閱/+ 來接收

/

不同於多層萬用字元，使用單層萬用字元的時候無法匹配子層級的主題，比如：//的主題訊息就無法接收到。

## 車聯網 TSP 平臺主題設計原則最佳實踐

前文中我們提到在車聯網場景中 MQTT 主題定義了業務與資料的通道，主題定義的核心是區分業務場景。如何合理的定義主題，需要根據一定原則來設計。我們可以從以下幾個維度來設計與定義主題：

### 根據業務資料方向區分

首先，資料的上下行方向不同決定了資料由誰產生，被誰消費。在車聯網場景中，車載裝置到平臺的資料上行通道與平臺應用到車的下行資料需要透過主題分開。透過對上行、下行主題的設計區分，可以幫助設計、運維及業務人員快速定位場景、問題及相關干係方。

有些業務可能會同時用到上下行主題，比如車輛申請資料下發後平臺下發資料，以及平臺請求車輛上班資料後車輛上報資料。這種情況下，由於 MQTT 協議的非同步通訊機制，也需要對一個整體業務的上下行主題分別定義。

### 根據車型區分

在車聯網場景中，不同車型意味著車輛產生的資料不完全相同，車機能力不完全相同同，對接的業務應用也不盡相同。我們可以根據車型型號對差異化的車輛資料以及業務進行主題上的區分。當然，同一個主機廠下的不同車型也會有相同的業務和資料，這些業務可以透過跨車型的主題來定義。

### 根據車輛區分

在車聯網場景中，如車控等安全等級較高的業務場景往往需要一對一的主題作為資料通通道。一方面透過主題來隔離車輛與車輛之間的業務資訊，另一方面保證資料可以點對點的互動。在主題設計中，有時需要將車輛的唯一識別符號作為主題的一部分來實現一對一的訊息通道。常見的方案有使用車輛 VIN 碼作為主題的一部分。

### 根據使用者區分

在實際使用場景中，也存在需要根據使用者（而不是車輛）實現車雲的一對一的訊息通道，此類需求經常發生在使用者促銷、運營、ToB 業務等場景中。在主題設計時，常見的方案有兩種，一是使用使用者 ID 作為主題的一部分；二是透過人-車關係轉換成車輛級主題，但由於訊息時效性、車內使用者登入狀態等原因，此方案下生產端及消費端均需要新增額外的設計及處理，相對複雜。

### 根據研發環境區分

從專案工程實施角度出發，一般在主題設計時同時會新增環境變數，透過配置實現不同研發環境下的資源複用以及正確性檢查。

### 根據資料吞吐量區分

由於業務的不同，不管是上行資料還是下行資料，資料的傳送頻率與報文大小都不盡相同。不同的資料吞吐量會影響到消費端的處理以及架構設計，比如我們在處理高頻的車輛資料上報業務時往往要考慮應用層的消費能力，這時候可能要藉助類似 Kafka 之類的高吞吐訊息佇列來進行資料緩衝，防止應用消費不及時造成資料積壓與資料丟失。所以在 MQTT 主題定義上，我們往往也需要對不同資料吞吐量的業務進行區分。

## MQTT 協議主題設計在車聯網場景中的應用

### 車輛資料主動上報

車載裝置（T-box，車機等）作為車輛執行資料的收集者，基於固定頻率將車內各類控制器、感測器等資料打包傳送到平臺端。此類資料一般可以按照上報資料的車型、車架號、業務資料型別等多個層級進行設計。

例如在使用者同意的前提下，車輛在行駛過程中會將位置、車速、電量等資訊按照固定頻率上報雲平臺，雲端應用基於這些資料，提供位置查詢、超速提醒、電量提醒、地理圍欄服務給終端使用者使用。

### 平臺請求下發後車輛資料上報

當雲平臺需要獲取車輛的最新狀態及資訊時，可以主動下發命令要求車輛上報資料。此類場景一般可以按照車架號、業務型別等層級進行主題設計。

例如在診斷場景下，平臺透過 MQTT 下發診斷命令至車輛，當車內各裝置完成診斷操作後，會將診斷資料打包後上報至雲平臺，車輛診斷工程師將根據採集到的診斷資料對於車況進行整體的分析及問題定位。

### 平臺指令下發

車輛遠端控制是車聯網業務中最常見、最典型的場景，各主機廠均在手機 App 中提供各種遠控功能，例如遠端啟動、遠端開車門、遠端閃燈鳴笛等等。此類場景下，手機 App 傳送控制命令至雲平臺，平臺應用經過許可權檢查、安全檢查等一系列操作後，透過 MQTT 將命令下發至車輛執行，車輛端執行成功後，非同步通知平臺執行結果。

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

### 車輛客戶端請求後平臺資料下發

在 SDV（軟體定義汽車）的大背景下，車內很多配置是可以做到動態變化的，例如資料採集規則、安全訪問規則，所以車輛在點火啟動後，會主動請求平臺最新的相關配置，若兩側配置不一致，平臺側會下發最新的配置資訊至車輛，車輛側實時生效。

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

## 使用 EMQX 進行車聯網 TSP 平臺主題設計

[EMQX](https://www.emqx.io/zh) 作為全球領先的 MQTT 物聯網訊息中介軟體，基於分散式叢集、大規模併發連線、快速低延時的訊息路由等突出特性，能夠有效處理車聯網場景中高時效性業務需求，大幅度縮短端到端時延，為大規模車聯網平臺快速部署提供標準的 [MQTT 服務](https://www.emqx.com/zh/cloud)。

### EMQX 在車聯網場景下的優勢

#### 海量主題支援

隨著車聯網場景中的業務不斷增加，承載業務通道的主題數量也不斷增加，尤其是包括車控場景所需要的一車一主題、一車多主題需求越來越大。在這種背景下，[MQTT 伺服器](https://www.emqx.com/zh/blog/mqtt-broker-server)的主題數承載能力就成為了 TSP 平臺的重要評估指標。

EMQX 在一開始的底層設計中就規劃了對海量裝置連線與海量主題支援的能力。常見的 16 核 32G 記憶體的 3 節點 EMQX 叢集可以支援百萬級主題同時執行，為 TSP 平臺主題設計提供了靈活的設計空間。

#### 強大規則引擎

EMQX 提供了內建的規則引擎， 基於規則引擎可以提供對不同主題資料的查詢、過濾、資料分拆以及對訊息重新路由。使用規則引擎，我們可以在已有車載裝置與應用主題建立好的場景下，透過建立新的路由規則與資料預處理規則對已有主題中的資料進行再處理。在車輛上市後，透過在平臺側定義新規則實現對新業務應用的支援。

在 [EMQX 企業版](https://www.emqx.com/zh/products/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](https://www.emqx.com/zh/blog/mqtt-topic-design-for-internet-of-vehicles)

車聯網 TSP 平臺場景中的 MQTT 主題設計

相關文章