> 在本專題系列文章中，我們將根據 EMQ 在車聯網領域的實踐經驗，從協議選擇等理論知識，到平臺架構設計等實戰操作，與大家分享如何搭建一個可靠、高效、符合行業場景需求的車聯網平臺。

## 前言

隨著整個汽車出行領域新四化（電氣化、智慧化、網聯化和共享化）的推進，各個汽車製造廠商正逐步構建以智慧駕駛和智慧網聯為核心的車聯網系統。新一代的車聯網系統對於底層訊息採集、傳輸和處理的平臺架構提出了更高的要求。

本系列專題的上篇文章《車聯網場景中的 MQTT 協議》中我們已經提到，[MQTT 協議](https://www.emqx.com/zh/mqtt)是目前最適合車聯網場景資料平臺搭建的通訊協議。基於此，本文中我們將繼續討論車聯網場景中的 MQTT 訊息採集與傳遞，以及如何構建一個千萬級車聯網 MQTT 訊息平臺，以期為正在進行車聯網業務的企業使用者提供平臺架構設計參考。

## 車聯網的基礎：訊息採集與傳遞

### 車聯網傳輸協議的演進

眾所周知，車聯網（vehicle-to-everything，V2X）是指車與雲、車與網、車與車、車與路、車與人、車與感測裝置等互動，實現車輛與公眾網路通訊的動態行動通訊系統，是為了滿足與車有關的每一個環節中的效率、安全、管理等元素而建立起的異構通訊網路。而執行於其中的通訊協議就成為車聯網系統建設的關鍵和核心。

在車聯網發展的歷程中，主要有兩種主流的通訊技術，對車聯網整體發展起到了推動作用：

**DSRC（DeDICated Short Range CommunICation，專用短程通訊）**：1992 年由美國材料試驗學會 ASTM 針對 ETC 的業務場景研發而出，後經多年完善和迭代，演變為 IEEE(802.1X) 車聯網通訊技術標準。在相當長的一段時間裡，DSRC 技術是國際汽車主流生產和消費市場使用的主流車聯網通訊協議。

**C-V2X（Cellular Vehicle to Everything，蜂窩車聯網通訊）：**C-V2X 依託現有的蜂窩基站，除了支援 PC5的直連通訊，RSU、車輛均可透過 4/5G 通道（採用 Uu 介面）與 V2X 平臺相連，實現車路協同通訊。較之 DSRC，C-V2X 技術上更優，它增強通訊的安全性與保密性，支援高網路容量，可支援高頻寬和大資料量需求。

DSRC 和 C-V2X 技術的競爭非常激烈，兩者都希望能夠成為主流車聯網通訊標準。目前，我國擁有最完善的 5G 通訊網路的基礎設施，因此更傾向於採用 C-V2X(LTE-V 、5G-V2X)通訊技術，透過 V2X 車路系統+單車智慧系統的體系化建設，實現基於自動駕駛的新一代車聯網架構。

### 訊息平臺建設對於車聯網的意義

在車聯網建設高速發展的今天，所有的主機廠業已形成了一個共識: 車聯網建設的目的不是為了聯網而聯網，也不是為了車載娛樂而聯網，聯網是為了資料。有了車聯網，就有了資料。有了資料，輔以完整的資料治理和應用體系，就有了一切。

而這個業務的目標資料，也不僅僅限於車端的相關資料。在 V2X 框架中，需要解決車與車（V2V）、車與路（V2R）、車與網（V2I）、車與雲（V2C）、車與人（V2H）等的互聯互通，實現針對車、路、雲、網、人的全面資料採集和分析。基於 5G 的 C-V2X 協議和通訊方式，為整個系統的建設提供基礎能力保障。

從傳統的 OTA 應用到智慧座艙、高精地圖適配、釐米級定位、車機端長連線、手機端訊息採集、車路雲圖、車路協同等眾多新型智慧應用場景，車聯網業務對於訊息平臺和資料處理系統的需求已從原始的車雲擴充套件為人-車-路-網-雲的整體架構建設，也因此對整個訊息平臺的建設提出了更高的要求。

如何建設一個海量連線、高併發吞吐、低時延的訊息通訊和傳輸系統架構，來保證整個系統的泛在性、便利性、高可用性、可靠性、安全性和高併發性，就成為了基於自動駕駛和車路協同場景下新一代車聯網系統建設的關鍵所在。

## 千萬級車聯網訊息平臺架構設計

接下來我們將以 [EMQ](https://www.emqx.com/zh) 的車聯網訊息平臺和資料處理整體解決方案為例，介紹如何構建一個千萬級的車聯網訊息平臺。

### 業務挑戰

**車機、路測單元和手機端系統安全接入**

車端需要涵蓋車機資料上報、POI 下發、推送檔案、下發配置、推送訊息、運營關懷等全新車聯業務，產生的海量訊息 Topic 需要更加安全穩定的接入與傳輸實現訊息訂閱和釋出。路端需要實現路側 RSU 的安全接入，訊息採集和傳輸、地圖資料的傳輸等。

**大併發訊息傳遞的實時性和可靠性**

高精地圖、釐米級定位、車路協同等應用場景均需要解決海量車路圖訊息的毫秒級低延時和高可靠的傳輸能力保障，需要訊息處理平臺具備高效能、低延時、高可靠支援千萬連線和百萬併發業務場景的能力。

**豐富的應用場景整合**

在以自動駕駛為核心的車聯網系統中，需要使用訊息平臺對接各種基於人、路、圖、雲相關的應用對接。將車端資料透過訊息平臺同高精地圖、釐米級定位、車路協同、手機端連線等應用場景進行連線，透過訊息平臺保障應用的消費供給，並提供高效能、低延時和高可靠的資料架構。

**海量資料儲存、處理和分發**

來自於人、車、路、雲、圖、網的海量物聯網資料被採集後，需要針對這些大規模實時資料流的接入、儲存、處理、分發等環節進行全生命週期管理，為應用提供針對動態連續資料流的資料庫支撐，支援應用深度使用車聯網資料服務於消費者，進行商業決策。

### 整體解決方案

在方案中我們主要採用 EMQ 旗下的雲原生分散式[物聯網接入平臺 - EMQX](https://www.emqx.com/zh/products/emqx)，實現車聯網系統中車端和人、路端的資料連線、移動和處理。EMQX 一體化的分散式 MQTT 訊息服務和強大的 IoT 規則引擎，可為高可靠、高效能的物聯網實時資料移動、處理和整合提供基礎能力底座，助力企業快速構建關鍵業務的 IoT 平臺與應用。

**針對車端的訊息處理**

EMQX 採用 MQTT 協議接入車聯絡統。車機端透過負載均衡與 EMQX 分散式叢集進行連線，EMQX 的橫向擴充套件能力可實現千萬級車機連線和百萬併發響應的資料通訊能力。透過規則引擎，可一站式實現海量訊息橋接訊息佇列、持久化入庫、離線訊息儲存等能力，同時提供豐富的API 原子能力北向整合。

在安全方面，EMQX 不僅支援 TLS/DTLS 或國密 GMSSL 安全協議，保障系統可靠與穩定；還提供心跳監測、遺囑訊息、QoS 等級等多重保障機制，透過離線訊息儲存實現在複雜的網路環境下實時、安全、可靠的車機訊息通訊。

[![車聯網架構1](http://img.blog.itpub.net/blog/2022/03/08/936722c5f9b28e62.png?x-oss-process=style/bb "車聯網架構1")](https://www.emqx.com/zh/blog/mqtt-messaging-platform-for-internet-of-vehicles "車聯網架構1")

**針對人、路端的訊息處理**

EMQX 為人、路端提供針對手機 APP、RSU 等終端的訊息採集和處理平臺。基於 5G 網路切片能力，透過個人終端和路側單元的就近接入，實現超低時延的交通訊息服務。透過 MQTT 等協議將人端、路側設施感知到的路況資訊推送到雲控平臺，透過雲控平臺融合 V2X 演算法實現道路協同感知知、安全提醒、遠端協同控制等智慧交通場景。

在安全方面，支援國際標準的 TLS/DTLS 加密或國密演算法 GMSSL 加密，透過擴充套件基於 PKI/CA 證書認證體系保障人車路資訊系協同的安全通訊。

[![車聯網架構2](http://img.blog.itpub.net/blog/2022/03/08/990a2a8e51c168a8.png?x-oss-process=style/bb "車聯網架構2")](https://www.emqx.com/zh/blog/mqtt-messaging-platform-for-internet-of-vehicles "車聯網架構2")

### 千萬訊息接入框架模型

針對新一代車聯網場景，EMQ 千萬級連線規模和百萬級併發的整體訊息接入和資料處理平臺參考架構如下：

[![車聯網千萬訊息接入框架模型](http://img.blog.itpub.net/blog/2022/03/08/3c266f11de8e1fb8.png?x-oss-process=style/bb "車聯網千萬訊息接入框架模型")](https://www.emqx.com/zh/blog/mqtt-messaging-platform-for-internet-of-vehicles "車聯網千萬訊息接入框架模型")

- **業務場景**：車聯網體系中的車輛、手機APP 端、路側 RSU 等裝置等透過 MQTT 接入，實現對千萬量級的以上終端的併發接入能力。
- **系統架構：**終端裝置透過 MQTT、HTTP 等協議接入，經過負載均衡元件連線至分散式訊息平臺 EMQ  X。透過分散式多叢集部署滿足千萬併發連線需求，按照百萬級訊息吞吐能力，透過規則引擎對接 Kafka 叢集實現資料的轉發。車聯網服務平臺、高精地圖服務、V2X 雲控服務、定位服務和其他車輛網相關應用可以直接透過訂閱 Kafka 資料進行消費，同時 EMQ 提供了 REST、MQTT 和 MQ 訊息佇列三種南向介面服務實現對車控（遠端控制）訊息的雙向通訊。

透過以上參考框架，EMQ 透過 EMQX 雲原生分散式物聯網接入平臺可實現車聯網場景下的千萬連線、百萬併發吞吐的業務需求。

## 千萬級訊息接入測試

### 測試環境和目的

某車企計劃在車聯網場景下，基於測試環境驗證 EMQX 叢集的以下能力，為後續業務增長做相應的技術架構和能力支撐準備：

- 可支撐 1000 萬併發連線，同時支援每秒 10 萬～15 萬、payload 為 100 位元組的 QoS 0 訊息透過規則引擎橋接到 Kafka；
- 1000 萬併發連線訂閱、消費 OTA 廣播主題；
- 300 萬使用者同時連線不會造成叢集雪崩，並測試連線所需時間。

另外，在完成上述所有測試後，繼續探索在目前配置下 1000 萬併發的同時可支援的最高訊息傳送並橋接轉發至 Kafka 的吞吐量(根據 EMQX 叢集資源使用情況提高客戶端訊息傳送頻率)，以及測試在 1000 萬連線下滿足 QoS 為 2 且平均響應時間在 50 毫秒內的最高訊息吞吐。

### 測試準備

[![車聯網測試架構](http://img.blog.itpub.net/blog/2022/03/08/f4202723987f46de.png?x-oss-process=style/bb "車聯網測試架構")](https://www.emqx.com/zh/blog/mqtt-messaging-platform-for-internet-of-vehicles "車聯網測試架構")

客戶端透過 TLS 加密連線負載均衡 ELB，然後在 HAProxy 對客戶端進行 TLS 終結，最後透過 TCP 連線至 EMQX 叢集。透過在 HAProxy 上終結 TLS 的方式可以提高 EMQX 叢集的支援能力，在這種部署模式下 EMQX 的處理能力和客戶端直接透過 MQTT TCP 連線是完全一致的。另一方面，相比 MQTT TCP 連線，客戶端透過 TLS 連線也需要消耗更多的資源，而本次測試規模為千萬級，所需的測試機數量眾多，為了減少所需測試資源的同時不影響對  EMQX叢集的測試目標，本次測試將直接使用 TCP 連線。

| **服務**                | **數量** | **版本** | **OS**    | **例項規格**             | **CPU** | **RAM** | **網路卡** | **埠**                 |
| :---------------------- | :------- | :------- | :-------- | :----------------------- | :------ | :------ | :------- | :----------------------- |
| 負載均衡雲服務          | 1        |          |           | 網路型/大型II            |         |         |          | 18083/1883/8081          |
| EMQX 節點               | 10       | V4.3.4   | Centos7.8 | c6.16xlarge.2普通塊儲存  | 64C     | 128G    | 1        | 18083/1883/8081/8883     |
| Kafka 雲服務            | 4        | 2.3.0    | Centos7.8 | c6.4xlarge.2超高IO塊儲存 | 16      | 32G     | 1        | 9092                     |
| XMeter 壓力測試控制節點 | 2        | 3.0      | Centos7.8 | c6.4xlarge.2             | 16      | 32G     | 1        | 443/80/3000/8086內網放通 |
| XMeter 壓力測試節點     | 43       | 3.0      | Centos7.8 | c6.4xlarge.2             | 16      | 32G     | 5        | 內網放通                 |

### 測試場景

| 序號 | 場景名稱                      | 描述                                                         | 期望結果                                                     |
| ---- | ----------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
| 1    | 千萬連線+訊息吞吐             | 1000 萬 MQTT TCP 併發連線，心跳間隔 200s。其中 700 萬為背景連線 (只連線不傳送訊息)，300 萬活躍使用者，每個使用者每隔 15S 上報一條 QOS 0 的訊息，payload 為 100B。訊息透過規則引擎橋接到 Kafka。先測試 1 小時，透過後進行 24 小時穩定性測試 | 內網測試成功率為 100%，無消 息積壓，CPU 和記憶體在測試期間表現平穩，沒有大幅度的抖動。 |
| 2    | 訊息廣播                      | 1000 萬 MQTT TCP 併發連線，所有連 接均訂閱同一個 OTA 廣播主題(QoS 0，payload 為 100B)。模擬一個 MQTT 客戶端每隔 10 分鐘向該主題廣 播一條訊息，測試 30 分鐘 | 內網測試成功率為 100%，所有訂閱客戶端成功消費 3 條訊息       |
| 3    | 300 萬併發瞬時連線            | 300 萬 MQTT 客戶端同時發起連線， 測試所有連線完成所需時間    | 300 萬客戶端都成功連線，叢集不會雪崩                         |
| 4    | 1000 萬連線下最高訊息吞吐探索 | 現有配置及 1000 萬連線且橋接 kafka 下可達到的訊息最高吞吐率 (Qos 0，payload 100B/1kB) | 最高訊息吞吐率達到後測試 2 小時，內網測試成功率為 100%，無訊息積壓，CPU 和內 存在測試期間表現平穩，沒有大幅度的抖動 |
| 5    | 平均響應時間下的TPS           | 1000 萬連線下，訊息為 QoS2、payload 100B，平均響應時間在 50 毫米內支援的最高訊息 TPS | 能夠達到不少於 20 萬 TPS 的吞吐能力                          |

### 測試結果

以下是本次測試的結果呈現：

| **序號** | **場景**                                                     | **平均響應時間** | **EMQX 節點 CPU 使用率** | **EMQX 節點CPU IDLE** | **EMQX 節點記憶體使用(G)**       | **LB所需頻寬(MB)** |
| :------- | :----------------------------------------------------------- | :--------------- | :----------------------- | :-------------------- | :----------------------------- | :----------------- |
| 1        | 1 千萬連線+20 萬訊息吞 吐，QoS 0，payload 100B               | 1.5ms            | 31%~48% 平均 47%         | 37%~54% 平均 47%      | Used: 27.7~42 Free: 78.2~92.5  | 45                 |
| 2        | 1 千萬連線下的訊息廣播                                       | 100ms            | 最高 21%                 | 最低 69%              | Used 最高 32.3 Free 最低 87.9  | 200                |
| 3        | 300 萬客戶端瞬時連線                                         | 3 分鐘完成連線   | 最高 25%                 | 最低 63%              | Used 最高 14.7 Free 最低 108.2 | 400                |
| 4        | 探索最高吞吐：1 千萬連 接+120 萬訊息吞吐，QoS 0，payload 1kB | 164.3ms          | 23%~64% 平均 46%         | 20%~64% 平均 43%      | Used: 33~38 Free: 81.3~87.1    | 1350               |
| 5        | 1 千萬連線+QoS2 20 萬消 息吞吐，payload 100B                 | 51.4ms           | 3%~51% 平均 41%          | 31%~53% 平均 43%      | Used: 22.2~29 Free:91~98       | 95                 |

### 小結

如以上結果所示，在目前的部署架構下，可以滿足該車企對於千萬併發連線 +20 萬訊息橋接至 Kafka、訊息廣播及 300 萬瞬時併發連線的驗證需求。在探索測試中，1000 萬連線下測試到最高 120 萬訊息 TPS(QoS 0、payload 1kB)，測試持續 10 小時 EMQX 叢集穩定，CPU idle 最低至 20%，記憶體使用平穩。

由以上可知，EMQX 在車聯網場景下支援千萬連線效能表現突出，架構穩定可靠。

>**壓力測試工具簡介和使用**
>
>本次測試由於所需測試機數量多，管理複雜，故使用 EMQ 旗下商業版測試軟體 XMeter 效能測試平臺和 JMeter-MQTT 外掛進行。
>
>[XMeter](https://www.emqx.com/zh/products/xmeter) 是基於開源測試工具 JMeter 擴充套件的效能測試平臺。針對物聯網具有的接入規模大、彈性擴充套件要求、多種接入協議、混合場景等特點，XMeter 對 JMeter 進行了改造，可以支援大規模、高併發的效能測試，比如實現千萬級別的 MQTT 併發連線和訊息吞吐測試。除了測試 MQTT 協議之外，還可以支援 HTTP/HTTPS 等主流的應用的測試。
>
>[JMeter-MQTT](https://github.com/xmeter-net/mqtt-jmeter) 外掛是由 XMeter 實現的開源 MQTT 效能測試外掛，在眾多的專案中得到了使用，目前是 JMeter 社群中流行度最高的 MQTT 外掛。

## 寫在最後

透過本文，我們介紹了基於雲原生分散式物聯網接入平臺 EMQX 的千萬級車聯網 MQTT 訊息平臺架構設計，並驗證了該架構在千萬級併發連線場景環境下的效能表現，為車聯網系統的訊息資料平臺建設提供了一種可能的設計參考。

EMQ 作為全球領先的物聯網資料基礎設施軟體提供商，致力於構建高效能、低延時、高可用、高可靠的產品，為新一代車聯網體系提供訊息採集、移動、處理和分析的整體解決方案，為整車製造商、T1 供應商、後市場服務商、出行服務公司和政府管理機構的自動駕駛、智慧網聯汽車業務提供基礎設施服務保障，實現人、車、路、雲的智慧連線。

> **關於作者**
>
> 樊榮傑，EMQ 解決方案架構總監。擁有豐富的 IT 基礎架構領域經驗，多年深耕於企業數字化轉型與物聯網架構構建、資料平臺建設、敏捷開發、精益運維和DevOps 理念等領域，致力於將先進的雲端計算、物聯網產品技術和服務推向市場。

## 本系列的其它文章

- [車聯網場景中的 MQTT 協議](https://www.emqx.com/zh/blog/mqtt-for-internet-of-vehicles)

>版權宣告： 本文為 EMQ 原創，轉載請註明出處。
>
>原文連結：[https://www.emqx.com/zh/blog/mqtt-messaging-platform-for-internet-of-vehicles](https://www.emqx.com/zh/blog/mqtt-messaging-platform-for-internet-of-vehicles)

千萬級車聯網 MQTT 訊息平臺架構設計

相關文章