目前我國車聯網行業處於與 5G 技術的深度融合時期，隨著 5G 與 V2X 技術的發展成熟，未來的車聯網產業必將開啟新的成長空間。
車聯網是物聯網技術在交通系統領域的典型應用，車聯網行業所涉及的相關技術領域的融合佈局與協同發展在某種程度上與物聯網一脈相通。作為一家開源物聯網資料基礎設施軟體供應商，EMQ 多年來也為車聯網領域的眾多客戶提供了雲邊端協同的物聯基礎設施軟體，實現對人、車、路、雲的統一連線，為整車製造商、T1 供應商、後市場服務商、出行服務公司等打造智慧網聯、自動駕駛和 V2X 等場景解決方案。
在本專題系列文章中，我們將根據 EMQ 在車聯網領域的實踐經驗，從協議選擇等理論知識，到平臺架構設計等實戰操作，與大家分享如何搭建一個可靠、高效、符合行業場景需求的車聯網平臺。
前言
MQTT 協議早已是物聯網領域當之無愧的主流協議，其憑藉輕巧高效、可靠安全、雙向通訊等特性在諸多行業物聯網平臺搭建中得到了廣泛的應用。那麼 MQTT 協議在車聯網場景中的應用情況如何呢？
本文將從 EMQ 車聯網行業使用者實際案例經驗出發，對比不同物聯網通訊協議在車聯網平臺搭建應用中的利弊，分享企業該如何基於自身情況選擇合適的 MQTT 訊息接入產品與服務，以及當前在資料傳輸安全、資料整合等方面的最熱門技術方案。
MQTT 協議適合車聯網嗎？
整個車聯網業務架構複雜，涉及多個通訊環節，在本文中我們討論的是車聯網平臺主要負責的雲-端訊息接入模組。
MQTT 是基於釋出/訂閱模式的物聯網通訊協議，具有簡單易實現、支援 QoS、報文小等特點，佔據了物聯網協議的半壁江山。在車聯網場景中，MQTT 依然能夠勝任海量車機系統靈活、快速、安全接入，並保證複雜網路環境下訊息實時性、可靠性， 其主要應用優勢如下：
- 開放訊息協議，簡單易實現。市場上有大量成熟的軟體庫與硬體模組，可以有效降低車機接入難度和使用成本；
- 提供靈活的釋出訂閱和主題設計，能夠通過海量的 Topic 進行訊息通訊，應對各類車聯網業務；
- Payload 格式靈活，報文結構緊湊，可以靈活承載各類業務資料並有效減少車機網路流量；
- 提供三個可選的 QoS 等級，能夠適應車機裝置不同的網路環境；
- 提供線上狀態感知與會話保持能力，方便管理車機線上狀態並進行離線訊息保留。
綜上，如果配以具備海量車端連線、軟實時、高併發資料吞吐以及多重安全保障能力的訊息中介軟體產品，MQTT 協議無疑是將為車聯網平臺的搭建帶來便利。
相比於 MQTT，其他協議差在哪裡？
目前為止大多數車聯網客戶首選的都是 MQTT 協議，我們也遇到過一些客戶曾選擇其他諸如私有 TCP、HTTP 協議，但從最終結果來看，MQTT 都是車聯網場景下的最佳選擇。
在沒有接觸過 MQTT 協議之前，華南某大型主機廠採用了私有化的 TCP 協議（ACP 協議）構建車聯網服務平臺。經過長週期的協議規範設計和開發，基本實現了車聯網平臺的主要功能。但隨著車聯網業務場景的不斷增加和車機數量的不斷增長，私有化的 TCP 的弊端逐漸凸顯：協議私有化定義與版本維護困難、所有的協議功能（如保活、斷線重連、離線訊息等）都需要定製開發，私有的協議也導致終端硬體適配都需要定製開發，成本高、週期長，更新迭代慢等問題突出。隨著 MQTT 協議生態不斷完善和在車聯網平臺通訊協議選型中被廣泛採用，該主機廠在新一代車聯網平臺的開發中開始採用 MQTT 協議，基於 EMQX 物聯網接入平臺為其提供的完善 MQTT 協議支援，不僅降低了開發成本、縮短了開發週期，同時實現了更多的功能場景和運維手段。
華東某大型主機廠現有一百多萬的存量車機，之前的車聯網平臺採用私有的 TCP 協議構建，面對百萬車機海量的訊息通訊，私有化的 TCP 協議維護成本高，訊息可靠性無保障，日常系統維護和功能擴充套件開發工作量大。隨著 MQTT 協議在集團內部車聯網平臺廣泛採納，該主機廠也開始啟動 MQTT 協議的改造升級工作，目前針對部分車型已經通過 OTA 升級的方式完成了升級，未來他們計劃分階段逐步完成所有車型的升級改造工作。
還有一個車企客戶早期與我們接觸過，但考慮到初期業務比較簡單以及自身技術選型問題，最終使用了自建 HTTP 服務的形式接入車機。隨著業務發展，傳統的請求-響應模式通訊已經無法滿足新增業務需求，同時隨著功能與終端數量增多，整個平臺通訊量成倍增加，使用 HTTP 接入出現了效能瓶頸。該客戶最終還是選擇了 MQTT 作為接入協議，使用 EMQX 提供的資料接入方案很好地解決了之前的業務難題。
總體來看，私有協議具有封閉性、排他性等特點，在制定初期是為了解決特定的問題而設計導致缺乏靈活性，往往在業務調整之後難以滿足新的需求，企業不得不在協議中加入更多的特性；又或者因為接入量的增多，私有協議 Server 端過早達到了效能和擴充套件性的瓶頸。以上種種原因最終導致使用者工作的重心從業務開發轉移到接入層、中介軟體的開發，無形中增加了平臺專案成本。因此 MQTT 協議順理成章地成為最適合車聯網領域的主流協議。
如何選擇 MQTT 訊息接入產品/服務？
平臺設計中，系統架構設計與產品選型是一個嚴謹的過程。使用者首先要結合應用場景，評估產品功能是否滿足業務需求，效能與可擴充套件效能否能夠支撐平臺短期的設計容量以及未來可能的增長；產品使用成本也是一個重要的考量，產品本身的成本、IaaS 基礎設施、開發整合和維護工作這些都會影響客戶的總體擁有成本；此外還應當結合產品全球化能力進行評估，對於有海外業務的專案，產品能否支援全球部署、是否滿足各個地區的合規性、能否避免雲端計算提供商鎖定這些都是選擇產品的依據。
EMQ 的車聯網客戶在選型過程中經常會與雲端計算提供商的物聯網訊息接入 SaaS 服務進行對比。相比之下 EMQX 的優勢主要在於私有部署和標準化能力 —— 支援私有部署到任意雲平臺，無平臺鎖定，提供標準 MQTT 協議，這也是車聯網客戶普遍看重的一點。
避免雲端計算供應商鎖定有助於企業使用者獲得競價優勢，可以減少企業與雲端計算供應商中止合作關係而帶來的影響。另一方面多雲支援也可以充分使用不同雲端計算提供商的技術與商業優勢，比如一些全球運營的企業可以在國內和海外選擇不同的雲端計算提供商。
此外還有相當一部分客戶看中 EMQX 較低的使用成本，根本原因是由於計費方式不同，往往業務規模越大，雲端計算提供商的接入服務成本越高。
不過從成本考量也有例外。之前曾有車企使用者評估了雲提供商的接入服務和 EMQX 後，考慮到自身的運維成本和風險後最終放棄私有部署，選擇了雲提供商的接入服務。而隨著 EMQ 的全託管 MQTT 訊息服務 - EMQX Cloud 的上線，這個問題也得到解決。通過 EMQX Cloud，現在使用者可以在免除基礎設施管理維護負擔的同時，保持了同私有部署一致的成本預算清晰可控、跨雲跨平臺等優勢，沒有後顧之憂地開展車聯網平臺建設。
對於有私有部署需求的客戶，EMQX 也有其獨有的優勢。EMQX 提供全球性的商業支援，較高的產品效能可帶來海量連線和吞吐能力，規則引擎與資料橋接則提供快速整合能力。同時針對車聯網領域，高可靠和易擴充套件架構能力以及雲邊一體的 V2X 資訊互動能力也讓 EMQX 在支援私有部署的同類產品中脫穎而出。
2018 年上汽大眾在設計研發新一代車聯網系統時，SC 部門考慮到新型車聯網大併發、低時延、高吞吐的場景需求，參考了國內外主流新型車聯網系統架構，最終採用了基於 MQTT 協議建設新一代車聯網平臺。
該專案中，MQTT 的特性與 EMQX 強大規則引擎資料整合能力和通用型匯流排能力有效滿足了客戶對複雜網路下訊息實時性可靠性的要求，並解決了專案時間緊、任務重，需要快速開發對接的需求。
檢視客戶成功故事：上汽大眾聯合 EMQ 打造新一代智慧車聯網系統
大家都在使用什麼技術方案？
作為訊息中介軟體，EMQX 提供了豐富且靈活的整合能力，且每個功能都提供了不同的技術方案以供使用者選擇，經過長期使用總結，比較熱門的技術方案如下：
安全保障
在傳輸鏈路層上我們均推薦使用者啟用 TLS 加密傳輸，但是多數雲端計算提供商的負載均衡產品不支援 TLS 終結，生產部署時需要額外部署 HAProxy 等元件來解除安裝 TLS 證書。另外有部分客戶需要國密演算法 TLS 加密傳輸，我們也專門定製提供了方案。
TBox 接入最常見的是使用證書認證，EMQX 提供可擴充套件的認證鏈，支援第三方認證平臺擴充套件（如 PKI 系統），基於使用者名稱/密碼的外接資料來源和內部資料庫認證其次。
此外絕大部分使用者都啟用了 EMQX 鑑權功能，為不同 TBox 終端分配相應的釋出、訂閱許可權以有效保護資料安全。
資料整合
將流經 EMQX 的海量車聯網資料與業務系統連線是客戶最重視的能力，EMQX 內建了規則引擎和資料橋接能力，可以將 MQTT 資料流式傳輸到 Kafka、各類 SQL / NoSQL / 時序資料庫中，而實際專案中絕大多數客戶都使用 Kafka 作為後端流處理元件。
Kafka 專注於資料的儲存和讀取，而 EMQX 則側重於客戶端和伺服器之間的通訊，EMQX 用來快速接收和處理來自大量物聯網裝置的訊息，Kafka 可以收集並儲存這些資料並將其傳送給後端程式來分析和處理，這個架構是目前應用最廣的資料整合方案。
寫在最後
目前汽車電子發展迅速，助推車聯網行業技術升級，智慧交通及汽車行業未來市場前景可觀，可以預見有更多的車主消費者和騎車廠家將從中收益。基於完善的 MQTT 協議和 EMQX 強大的產品能力可以幫助車聯網平臺開發者快速構建健壯、靈活的車聯網平臺。EMQ 也將緊跟行業發展趨勢，推進訊息傳輸和邊緣計算相關的技術發展和落地，為自動駕駛、車輛協同、車聯網使用者提供更快、更好、更智慧的訊息服務基礎設定。