車聯網平臺百萬級訊息吞吐架構設計

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

前言

在之前的文章中，我們提到車聯網 TSP 平臺擁有很多不同業務的主題，並介紹瞭如何根據不同業務場景進行 MQTT 主題設計。車輛會持續不斷產生海量的訊息，每一條通過車聯網上報的資料都是非常珍貴的，其背後蘊藏著巨大的業務價值。因此我們構建的車輛 TSP 平臺也通常需要擁有千萬級主題和百萬級訊息吞吐能力。

傳統的網際網路系統很難支撐百萬量級的訊息吞吐。在本文中，我們將主要介紹如何針對百萬級訊息吞吐這一需求進行新一代車聯網平臺架構設計。

車聯網場景訊息吞吐設計的關聯因素

車聯網的訊息分為上行和下行。上行訊息一般是感測器及車輛發出的告警等訊息，把裝置的資訊傳送給雲端的訊息平臺。下行訊息一般有遠端控制指令集訊息和訊息推送，是由雲端平臺給車輛傳送相應的指令。

在車聯網訊息吞吐設計中，我們需要重點考慮以下因素：

訊息頻率

車在行駛過程中，GPS、車載感測器等一直不停地在收集訊息，為了收到實時的反饋資訊，其上報接收的訊息也是非常頻繁的。上報頻率一般在 100ms-30s 不等，所以當車輛數量達到百萬量級時，平臺就需要支援每秒百萬級的訊息吞吐。

訊息包大小

訊息是通過各種感測器來採集自身環境和狀態資訊（車聯網場景常見的有新能源國標資料和企標資料）。整個訊息包大小一般在 500B 到幾十 KB 不等。當大量訊息包同時上報時，需要車聯網平臺擁有更強的接收、傳送大訊息包的能力。

訊息延時

車輛在行駛過程中，訊息資料只能通過無線網路來進行傳輸。在大部分車聯網場景下，對車輛的時延要求是 ms 級別。平臺在滿足百萬級吞吐條件下，還需要保持低延時的訊息傳輸。

Topic 數量和層級

在考慮百萬級訊息吞吐場景時，還需要針對訊息 Topic 數量和 Topic 樹層級進行規範設計。

Payload 編解碼

當訊息包比較大的時候，需要重點考慮訊息體的封裝。單純的 JSON 封裝在訊息解析時不夠高效，可以考慮採用 Avro、Protobuf 等編碼格式進行 Payload 格式化封裝。

對於百萬級訊息吞吐場景，基於 MQTT 客戶端共享訂閱訊息或通過規則引擎實時寫入關係型資料庫的傳統架構顯然無法滿足。目前主流的架構選型有兩種：一種是訊息接入產品/服務+訊息佇列（Kafka、Pulsar、RabbitMQ、RocketMQ 等），另外一種是訊息接入產品/服務+時序資料庫（InfluxDB、TDengine、Lindorm等）來實現。

接下來我們將基於上述的關聯因素和客戶案例的最佳實踐，以雲原生分散式物聯網訊息伺服器 EMQX作為訊息接入層，分別介紹這兩種架構的實現方式。

EMQX+Kafka 構建百萬級吞吐車聯網平臺

架構設計

Kafka 作為主流訊息佇列之一，具有持久化資料儲存能力，可進行持久化操作，同時可通過將資料持久化到硬碟以及 replication 防止資料丟失。後端 TSP 平臺或者大資料平臺可以批量訂閱想要的訊息。

由於 Kafka 擁有訂閱釋出的能力，既可以從南向接收，把上報訊息快取起來；又可以通過北向的連線，把需要傳送的指令通過介面傳輸給前端，用作指令下發。

我們以 Kafka 為例，構建 EMQX+Kafka 百萬級吞吐車聯網平臺：

前端車機的連線與訊息可通過公有云商提供的負載均衡產品用作域名轉發，如果採用了 TLS/DTLS 的安全認證，可在雲上建立四臺 HAProxy/Nginx 伺服器作為證書解除安裝和負載均衡使用。
採用 10 臺 EMQX 組成一個大叢集，把一百萬的訊息吞吐平均分到每個節點十萬訊息吞吐，同時滿足高可用場景需求。
如有離線離線/訊息快取需求，可選用 Redis 作為儲存資料庫。
Kafka 作為總體訊息佇列，EMQX 把全量訊息通過規則引擎，轉發給後端 Kafka 叢集中。
後端 TSP 平臺/OTA 等應用通過訂閱 Kafka 的主題接收相應的訊息，業務平臺的控制指令和推送訊息可通過 Kafka/API 的方式下發到 EMQX。

車聯網架構圖

總體架構圖

在這一方案架構中，EMQX 作為訊息中介軟體具有如下優勢，可滿足該場景下的需求：

支援千萬級車輛連線、百萬級訊息吞吐能力。
分散式叢集架構，穩定可靠，支援動態水平擴充套件。
強大的規則引擎和資料橋接、持久化能力，支援百萬級訊息吞吐處理。
擁有豐富 API 與認證等系統能順利對接。

百萬吞吐場景驗證

為了驗證上述架構的吞吐能力，在條件允許的情況下，我們可以通過以下配置搭建百萬級訊息吞吐測試場景。壓測工具可以選用 Benchmark Tools、JMeter 或 XMeter 測試平臺。共模擬 100 萬裝置，每個裝置分別都有自己的主題，每個裝置每秒傳送一次訊息，持續壓測 12 小時。

壓測架構圖如下：

車聯網壓測架構圖

效能測試部分結果呈現：

EMQX 叢集 Dashboard 統計

EMQX 規則引擎中可以看到每個節點速度為 10 萬/秒的處理速度，10 個節點總共 100 萬/秒的速度進行。

EMQX 規則引擎統計EMQX 規則引擎統計

EMQX 規則引擎統計

在 Kafka 中可以看到每秒 100 萬的寫入速度，並且一直持續儲存。

Kafka 管理介面

Kafka 管理介面統計

EMQX+InfluxDB 構建百萬級吞吐車聯網平臺

架構設計

採用 EMQX+ 時序資料庫的架構，同樣可以構建百萬級訊息吞吐平臺。在本文我們以 InfluxDB 時序資料庫為例。

InfluxDB 是一個高效能的時序資料庫，被廣泛應用於儲存系統的監控資料、IoT 行業的實時資料等場景。它從時間維度去記錄訊息，具備很強寫入和儲存效能，適用於大資料和資料分析。分析完的資料可以提供給後臺應用系統進行資料支撐。

此架構中通過 EMQX 規則引擎進行訊息轉發，InfluxDB 進行訊息儲存，對接後端大資料和分析平臺，可以更方便地服務於時序分析。

前端裝置的訊息通過雲上雲廠商的負載均衡產品用作域名轉發和負載均衡。
本次採用 1 臺 EMQX 作為測試，後續需要時可以採用多節點的方式，組成相應的叢集方案（測試 100 萬可以部署 10 臺 EMQX 叢集）。
如有離線離線/訊息快取需求，可選用 Redis 作為儲存資料庫。
EMQX 把全量訊息通過規則引擎轉發給後端InfluxDB進行資料持久化儲存。
後端大資料平臺通過 InfluxDB 接收相應的訊息，對其進行大資料分析，分析後再通過 API 的方式把想要的資訊傳輸到 EMQX。

百萬級吞吐車聯網平臺

總體架構圖

場景驗證

如測試架構圖中所示，XMeter 壓力機模擬 10 萬 MQTT 客戶端向 EMQX 發起連線，新增連線速率為每秒 10000，客戶端心跳間隔(Keep Alive)300 秒。所有連線成功後每個客戶端每秒傳送一條 QoS 為 1、Payload 為 200B 的訊息，所有訊息通過 HTTP InfluxDB 規則引擎橋過濾篩選並持久化發至 InfluxDB 資料庫。

車聯網測試