近年來，汽車產業向「電氣化、智慧化、網聯化、共享化」快速演進，「軟體定義汽車」模式和 SOA 理念在汽車研發和設計領域逐漸深入。無論是作為智慧網聯汽車雲端底座的 TSP 平臺、基於單車智慧 ADAS 的自動駕駛體系，還是實現軟體定義汽車的 SOA 框架，均需要更加靈活的軟體開發、迭代、複用和執行架構保障。

雲原生技術的快速發展和落地，大大改變了車聯網應用傳統的開發和執行方式。以其靈活、彈性、敏捷、自動化、高可用、易擴充套件等特性，為汽車行業智慧網聯和自動駕駛相關軟體的開發和執行，提供了平臺層面的助力，解決了車聯網平臺在新趨勢下面臨的上述挑戰。

> **雲原生：** 在 CNCF（雲原生計算基金會）的定義中，雲原生技術有利於各組織在公有云、私有云和混合雲等新型動態環境中，構建和執行可彈性擴充套件的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和宣告式 API。

本文旨在深入分析雲原生技術如何作用於車聯網物聯網基礎設施構建，基於體系中最關鍵的車端訊息採集、移動、處理和分析領域，結合 EMQ 相關資料基礎設施軟體，實現雲原生的車聯網基礎設施架構。

## 傳統車聯網平臺構建的挑戰

傳統車聯網的訊息處理框架在構建底層資源和執行平臺端的整體框架時，往往採用本地資料中心虛擬機器/物理機或雲服務商虛擬機器進行部署。此種模式在聯網車輛快速增多、車端上傳資料愈加複雜的場景下，通常會面臨如下的痛點和挑戰：

1. 各大主機廠若想將在私有資料中心提供車聯網服務的模式轉變為透過公有云提供車聯網服務，傳統的以虛擬機器為應用承載方式的架構會過於沉重，無法平滑實現車聯網混合雲遷移需求和混合雲的部署模式；
2. 隨著智慧化和網聯化的快速發展，車聯網系統對於訊息處理平臺的軟體迭代能力要求逐漸提高，傳統的軟體迭代模式無法應對智慧網聯對於車聯網系統敏捷、靈活和快速的能力要求，針對紛繁複雜的訊息處理需求和軟體迭代也無法響應；
3. 車聯網系統作為主機廠同終端客戶最重要的實時溝通系統，需要具備極高的可靠性、可用性和可支撐性。訊息處理平臺作為核心應用元件，應具備彈性的資源獲取能力和自動化伸縮、運維等運營支撐能力。傳統的巨石型應用架構和虛擬機器部署模式無法滿足訊息處理平臺彈性和自復位的能力要求。

## 雲原生技術賦能新一代車聯網訊息處理

CNCF（Cloud Native Computing Foundation）旗下專案中以容器編排系統 Kubernetes 最為核心和基礎。Kubernetes 透過將應用程式的容器組合成邏輯單元，以便於管理與服務發現，其為開源系統，可以自由地部署在企業內部、私有云、混合雲或公有云，方便使用者做出自由選擇。

[![](http://img.blog.itpub.net/blog/2022/09/06/4697fe20b1cb408c.jpeg?x-oss-process=style/bb)](https://www.emqx.com/zh/blog/cloud-native-smart-connected-car-messaging)

越來越多的主機廠在業務平臺的生產交付場景中，採用雲原生技術打造以下能力，助力智慧網聯汽車的應用演進和發展。

- **統一部署**：提供遮蔽底層資源型基礎設施差異，一次構建，多處使用的能力
- **易於實施**：提供 CaaI(Config as an Infrastructure)，即配置即設施的能力，達到配置即執行時效果的能力
- **彈性擴容**：根據業務使用情況進行資源型資源的快速彈性伸縮，提供執行時伸縮，業務應用無感知的能力
- **監控告警**：提供完善的監控告警體系，滿足生產環境後期維護的可控效能力
- **版本迭代可控**：提供風險可控的版本變更手段，包括版本追溯與回滾的能力

## 基於 Operator 的 EMQX 雲原生框架

早期 EMQ 產品雲原生部署採用的是 Helm 部署方式，Operator 模式的出現為實現自定義資源提供了標準的解決方案，解決了通用 Kubernetes 基礎模型元素無法支撐不同業務領域下複雜自動化場景的痛點，為實現更加簡單、高效的 EMQX 部署提供了全新的方式。

簡單來說，Operator 模式是一組自定義控制器的集合以及由這些控制器所管理的一系列自定義資源，我們將不再關注於 Pod（容器）、ConfigMap 等基礎模型元素，而是將它們聚合為一個應用或者服務。Operator 透過控制器的協調迴圈來使自定義應用達到我們期望的狀態，我們只需要關注該應用的期望狀態，透過自定義控制器協調迴圈邏輯來達到 7*24 小時不間斷的應用或者服務的宣告週期管理。基於 Operator 的 EMQX 雲原生框架，使得使用者可以輕鬆基於 Kubernetes 的模式部署和運維 EMQX 叢集。

### Operator VS Helm

Operator 的管理不僅限於 Pod，也可以是多個資源（比如 SVC 域名等）。從這個角度上來說，Operator 跟 Helm 一樣，也是具有編排能力的。從編排角度來看，Helm 與 Operator 有非常多的共性，很難對兩者的作用進行區分。Helm 也可以完成分散式系統的部署。

那麼 Operator 跟 Helm 又有什麼樣的區別呢？

- Helm 的側重點在於多種多個的資源管理，而對生命週期的管理主要包括建立更新和刪除，Helm 透過命令驅動整個的生命週期。
- Operator 對於資源的管理則不僅是建立和交付。由於其可以透過 watch 的方式獲取相關資源的變化事件，因此可以實現高可用、可擴充套件、故障恢復等運維操作。因此 Operator 對於生命週期的管理包括建立、故障恢復、高可用、升級、擴容縮容、異常處理以及最終的清理等等。
- 如果把 Helm 比作 RPM，那麼 Operator 就是 systemd。RPM 負責應用的安裝、刪除，而 systemd 則負責應用的啟動、重啟等等操作。

### Operator 工作原理

Operator 使用自定義資源（CR）管理應用及其元件的自定義 Kubernetes 控制器，自定義資源 Kubernetes 中 API 擴充套件，自定義資源配置 CRD 會明確 CR 並列出 Operator 使用者可用的所有配置，Operator 監視 CR 型別並且採取特定於應用的操作，確保當前狀態與該資源的理想狀態相符。

[![](http://img.blog.itpub.net/blog/2022/09/06/d28685c61d0687ef.png?x-oss-process=style/bb)](https://www.emqx.com/zh/blog/cloud-native-smart-connected-car-messaging)

Operator 中主要有以下幾種物件：

- CRD：自定義資源的定義，Kubernetes API 伺服器會為你所指定的每一個 CRD 版本生成 RESTful 的資源路徑。一個 CRD 其實就是定義自己應用業務模型的地方，可以根據業務的需求，完全定製自己所需要的資源物件，如 EMQX Broker、EMQX Enterprise 等這些都是可以被 Kubernetes 直接操作和管理的自定義的資源物件。
- CR：自定義資源，即 CRD 的一個具體例項，是具體的可管理的 Kubernetes 資源物件，可以對其進行正常的生命週期管理，如建立、刪除、修改、查詢等，同時 CR 物件一般還會包含執行時的狀態，如當前的 CR 的真實的狀態是什麼，用於觀察和判斷，CR 物件的真正所處於的狀態。
- Controller：其實就是控制器真正的用武之地了，它會迴圈處理工作佇列中的動作，按照邏輯協調應用當前狀態至期望狀態。如觀察一個CR 物件被建立了之後，會根據實現的邏輯來處理 CR，讓 CR 物件的狀態以及 CR 物件所負責的業務邏輯慢慢向期望的狀態上靠近，最終達到期望的效果。舉例來說：如果定義了一個 EMQX Broker 的 Operator，那在建立 EMQX Broker 的時候，就會一直協調和觀察 EMQX Broker 真正的叢集是否已建立好，以及每個節點的狀態和可用性是否健康。一旦發現不符合期望的狀態就會繼續協調，始終保持基於事件的機制不斷檢查和協調，以保證期望的狀態。

## EMQX 在車聯網場景中的雲原生實踐

基於 Operator 模式，我們提供了 [EMQX Operator](https://www.emqx.com/zh/emqx-kubernetes-operator) 來幫助客戶在 Kubernetes 的環境上快速構建和管理 EMQX 叢集。

EMQX Operator 是一個用來幫助使用者在 Kubernetes 的環境上快速建立和管理 EMQX 叢集的工具。 它可以大大簡化部署和管理 EMQX 叢集的流程，將其變成一種低成本的、標準化的、可重複性的能力。

[![](http://img.blog.itpub.net/blog/2022/09/06/8272b32539b69142.png?x-oss-process=style/bb)](https://www.emqx.com/zh/blog/cloud-native-smart-connected-car-messaging)

作為車聯網的核心底層支撐元件，EMQX 可以透過 Kubernetes Operator 進行部署、管理和運維。透過基於雲原生的訊息處理平臺，為車聯網場景中的客戶開發和運維部署帶來了諸多好處：

- 無感和滾動更新：以雲原生技術構建的車聯網訊息處理框架，可以輕鬆實現車聯網應用的灰度釋出，使得車聯網系統升級迭代過程中無需中斷服務，讓車聯網應用的使用者完全無感知，實現無感迭代和滾動更新，提升使用者體驗；
- 統一監控：基於雲原生技術，車聯網系統的運維者可輕鬆進行應用叢集和節點的監控和管理。透過與 Prometheus 等監控工具的整合，可以輕鬆獲取車聯網中最重要的訊息處理平臺的執行資訊，從而更直觀清晰地瞭解業務執行情況，進行相應的業務迭代；
- 快速部署：雲原生技術可以讓車聯網開發和運維人員快速部署和調整應用，無論是基於公有云還是私有云環境，均可以輕鬆部署相應的 EMQX 叢集，實現對業務的支撐；
- 標準化映象：EMQX 基於雲原生環境提供了標準化的官方容器映象，當使用者系統透過映象來進行 EMQX 的部署和構建時，可基於標準化映象進行相應的工作，對於車聯網環境中的快速釋出和多次構建等需求提供了很好的支撐；
- 彈性伸縮：隨著車聯網應用的深入，整個訊息處理框架所需要對接的應用逐步擴充套件和車聯網規模的增大，訊息處理平臺對資源的彈效能力要求也越來越高，透過 Kubernetes 彈性靈活的資源支撐模式，可以針對應用的使用量進行資源獲取、增加和釋放，從而節省資源，降低運營成本；
- 快速迭代：基於雲原生框架構建的車聯網應用，可利用持續整合和持續交付流水線實現應用的即時更新和釋出，支撐業務對於車聯網快速迭代的需求；

## 結語

隨著雲原生理念在各行業的深入，我們相信雲原生也將為車聯網領域的平臺構建與應用開發模式注入新的動力。未來 EMQ 將圍繞對 EMQX 新版本特性的支援，不斷完善迭代 EMQX Operator，致力於在雲原生模式下提供更加豐富可靠的資料基礎設施能力，服務於車聯網行業。

## 本系列中的其它文章

- [車聯網平臺搭建從入門到精通 01 | 車聯網場景中的 MQTT 協議](https://www.emqx.com/zh/blog/mqtt-for-internet-of-vehicles)
- [車聯網平臺搭建從入門到精通 02 | 千萬級車聯網 MQTT 訊息平臺架構設計](https://www.emqx.com/zh/blog/mqtt-messaging-platform-for-internet-of-vehicles)
- [車聯網平臺搭建從入門到精通 03 | 車聯網 TSP 平臺場景中的 MQTT 主題設計](https://www.emqx.com/zh/blog/mqtt-topic-design-for-internet-of-vehicles)
- [車聯網平臺搭建從入門到精通 04 | MQTT QoS 設計：車聯網平臺訊息傳輸質量保障](https://www.emqx.com/zh/blog/mqtt-qos-design-for-internet-of-vehicles)
- [車聯網平臺搭建從入門到精通 05 | 車聯網平臺百萬級訊息吞吐架構設計](https://www.emqx.com/zh/blog/million-level-message-throughput-architecture-design-for-internet-of-vehicles)
- [車聯網平臺搭建從入門到精通 06 | 車聯網通訊安全之 SSL/TLS 協議](https://www.emqx.com/zh/blog/ssl-tls-for-internet-of-vehicles-communication-security)
- [車聯網平臺搭建從入門到精通 07 | 國密在車聯網安全認證場景中的應用](https://www.emqx.com/zh/blog/application-of-gmsm-in-internet-of-vehicles-security-authentication-scenario)

>版權宣告： 本文為 EMQ 原創，轉載請註明出處。
>
>原文連結：[https://www.emqx.com/zh/blog/cloud-native-smart-connected-car-messaging](https://www.emqx.com/zh/blog/cloud-native-smart-connected-car-messaging)

雲原生賦能智慧網聯汽車訊息處理基礎框架構建

相關文章