軟體正在吞噬汽車！當數字化、智能化逐漸滲透汽車時，也給傳統車企帶來了諸多的技術挑戰。在此背景下，本文作者對雲邊協同及車聯網的衆多特性展開深入研究，并進行了基于微服務與容器化，深入的車雲實踐。
作者 |蔣彪 王函 趙偉 責編 | 唐小引
出品 |新程式員
傳統車企在車聯網中面臨的挑戰
近年來，随着大資料、新能源、智能網聯、自動駕駛等現代科技、創新生态在汽車行業的迅猛發展，汽車與人們日常生活的聯系正變得更加緊密。如何實作“以産品為中心”向“以使用者為中心”轉換的業務目标，如何快速響應、探索、挖掘、引領使用者的需求，如何與使用者形成觸點、了解使用者、與使用者進行有效溝通，是當下傳統車企進行數字化轉型的根本立足點。面對新事物、新科技、新理念所帶來的沖擊，傳統車企向數字化、智能化與網聯化的轉型已迫在眉睫，但在這個過程中，也面臨着衆多技術挑戰。
首先如何加速企業零售、技術、生産、品質等部門的資料融合，聯通各個業務領域的“資料孤島”，建立統一的資料視圖，最大程度確定企業層面的資料共享？
其次，如何實作智能網聯？雲邊協同是關鍵。在雲端和車端之間，需要用邊緣計算來解決分布式基礎設施資源、計算資源、安全政策、資料政策、應用管理等方面的協同。然而，根據姚建铨院士（中國科學院院士）于2020年12月在報告《邊緣計算理論科學問題初探》裡指出的：邊緣計算目前仍存在兩個方面的問題亟須落實，一是類似PC的軟硬體解耦、SDN（軟體定義網絡）中的資料平面和控制平面解耦、雲與資料中心解耦，進而實作動态自适應地支撐各種粒度的邊緣虛拟化融合，以及在邊緣硬體上實作網絡面、資料面和業務面的充分融合；二是強調異構場景下邊緣技術棧統一，研究通用軟硬體技術，充分實作IT（Internet Technology，網際網路技術）-CT（Communication Technology，通信技術）-OT（Operational Technology，營運技術）的邊緣融合。
第三，車聯網的資料特點除了資料量大、類型多、價值密度低、速度快，同時具備專業性、關聯性和時序性。如何在雲端實作存儲資源的有效利用、彈性擴容，實作工業大資料的冷熱分離和資料容災？這是車企雲端服務在設計和實施中需要考慮的問題。
最後，傳統車企對雲計算缺乏理性認知，雲端設計和資料中心的建設經驗匮乏。在多雲服務商公有雲和私有雲混雜的情景下，如何建立統一的雲端安全防範政策和防禦措施？如何集中管控雲端應用的一緻性，屏蔽雲端IaaS和PaaS的異構性？如何平衡公有雲資源的計算優勢和私有雲的安全優勢，合理規劃資料資源的存儲和遷移？
福特中國的架構實踐
架構理念和全景設計有人說架構是藝術—語言的藝術或者取舍的藝術，我更覺得架構是世界觀的邏輯泛化。以下我們嘗試用準邏輯化的術語來勾畫出架構思想。首先，我們提出如下架構定理1：
定理1. 架構是産品的骨架，理念是架構的準則(Principle)！
就好像大廈不能沒有鋼筋骨架，橋梁不能沒有墩柱墊石，一個産品沒有正确的架構，必然是失敗的。但什麼才能決定架構是否正确？正如TOGAF（開放組體系結構架構）之類的架構方法論指出的，準則是架構的靈魂，理念是架構的準則。
我們在架構實踐中發現，很多傳統主機廠在數字化轉型過程中最大的問題，不是沒有技術或産品，而是沒有理念。不知道自己是誰、從哪來、到哪去。有些主機廠習慣從Tier1供應商的角度看汽車，或從雲廠商的角度看汽車，還有從硬體廠商的角度看汽車，但是很少從汽車的角度看汽車。也就是說，大部分都沒有認識到，汽車架構中最核心的理念其實是做一台好車。
那麼，什麼樣的架構理念才是正确的呢？我們接下來提出定理2：
定理2. 軟體定義汽車，服務定義軟體
軟體定義汽車的概念大家都很清楚，我在此不再贅述。我想指出的是，對于主機廠而言，怎麼定義“軟體”？很多人講到軟體就想到車内SOA（面向服務的架構）生态，把車内生态和雲生态割裂開來。但是，車無法脫離雲生态而存在，如果脫離了，那主機廠和代工廠又有什麼差別？
那麼，如果我們把“車内SOA+雲生态”看成一個整體夠不夠？答案還是不夠，因為很多車聯功能極度依賴于傳統IT系統。例如，使用者在提車前需要從移動網際網路入口進行使用者偏好設定，在這個環節中最大的問題不是車端硬體如何FOTA（無線固件更新），也不是雲如何下發，而是制造系統什麼時候下發車輛中繼資料。是以，主機廠需要從全局看待軟體，即要站在服務的視角，用服務定義軟體。
如何在具體實操層面傳遞（Delivery）服務定義軟體這個理念？我們提出如下定義1：
定義1 SDN（Service Delivery Network）跨多種通信網絡（廣域網/車内以太網/邊緣網絡）向車聯網中的生産者和消費者提供服務，以及流量路由、車輛中繼資料、鑒權與熔斷等多種基礎能力。
SDN是概念上的服務傳遞網絡，其概念有點類似于中台，但又有很大不同。我們常見的中台有資料中台、業務中台、技術中台等，但它們都有一個特點——站在雲的角度看待整體業務。而主機廠很多情況下恰恰相反，需要站在端，而且是異構多端的角度梳理業務。
正如圖1所示的邏輯圖，我們在SDN中用通道連結端和雲，站在主機廠的角度定義軟體産品，從真正意義上實作軟體定義汽車，而非軟體嫁接汽車。
圖1 用通道連結雲和端
進一步地，又該如何定義服務？服務的邊界是什麼？服務到底是邏輯單元還是實體單元？為此我們提出了定義2：
定義2 服務（Service）是基于邏輯實體（Entity）的部署單元（Deployment Unit），以API的方式對外提供服務，可以跨硬體進行異構計算。
這裡首先強調了服務的基石是邏輯實體，如車輛中繼資料就是個典型的邏輯實體。這裡需要注意的是，沒有強調邏輯實體的顆粒度，如果要求顆粒度細到不可切分，那麼這裡的服務就很類似于微服務（Microservices）概念。但在汽車軟體中，并不要求所有的服務都有統一的顆粒度，因為同樣的邏輯實體在不同硬體和環境下，算力資源和分布式環境各有不同，不适合一刀切。
其次，這裡的服務要求以API形式對外提供服務，并且不僅僅通信協定，還可以是Socket接口、RESTful，也可以基于Message broker（消息代理）。但是會要求具備統一的接口Uniform Resource Name、統一的安全機制、基于JSON的資料結構、統一的Error Code。
最後也是最重要的，要求可以跨硬體計算，這是為了邊緣計算或者混合雲做準備。對于主機廠而言，保證算力的自由排程，将資料搬運到計算節點上是非常關鍵的一個核心能力，為了達成這個目的，可以采用Docker、WebAssembly等容器技術。
基于容器的混合雲模式
混合雲政策是将公共雲和私有雲環境結合在一起，使企業能夠将兩者的優點結合起來。公有雲的優勢在于可根據企業需求按需付費、彈性擴充；私有雲為企業提供敏感資料的環境隔離，保障企業資料安全。為了有效利用各個雲服務廠商網絡資源整合、垂直領域發展、流量推廣等各方面的優勢，也避免被單個雲服務廠商深度綁定，企業在公有雲的合作上往往會對接多個公有雲提供商。
盡管混合雲內建了公有雲和私有雲的優勢，但也帶來了更多的安全防範成本，雲之間的資料互動控制和設計帶來了更大異構資源管理的複雜性。僅僅從應用管理的角度來，混合雲的背景下，運用容器化技術來實作應用層的抽象，并利用大規模分布式資源和服務管理工具來對接不同的雲服務廠商，屏蔽IaaS層的異構性是非常有必要的（見圖2）。
圖2 混合雲架構設計
建立抽象層屏蔽雲服務差異:
雲服務廠商的Serverless功能，通常以相同的方式工作，具體場景上存在特定的差别。類似Cloud Foundry的BOSH引擎，可以通過建立對IaaS資源的抽象，解耦應用與服務管理層和下層資源管理層的依賴差異。資源抽象層的核心功能有：
對接雲服務廠商的雲平台接口。通過內建服務廠商的資源管理接口，向上提供統一的資源管理API，屏蔽資源層的異構性。
提供資源運作狀态的監視資料，對每個雲提供商的VM進行統一的異常檢測、自動恢複及告警通知。
提供統一的資源管理入口。對IaaS層資源進行抽象的描述，同時就可以提供統一的資源管理界面和管理API。
基于容器的平台無關性實踐:
容器能提供比虛拟機更輕量的隔離技術，類似Docker和Cloud Foundry的Garden。在汽車行業逐漸進行以使用者為中心的數字化變革背景條件下，一套基于容器化的分布式服務治理體系對車企非常重要，主要展現在以下幾個方面：
主流的雲服務廠商都支援容器技術。容器技術給車企帶來的環境适配性是不可替代的，車企可以集中在自身的業務發展和開發上，無需擔心具體雲平台的捆綁問題。
容器技術屏蔽了系統環境的差異，使得開發、測試和運維人員僅關注應用和服務的鏡像部署、測試和釋出，簡化了溝通和環境成本。
容器生态系統完善，開放容器倡議（OCI）就制定了關于容器運作環境和容器鏡像格式這兩個核心部分的規範。
最後，容器技術結合Kubernetes編排工具，可以進一步提高應用的資源使用率，簡化部署提升擴充性。
基于容器和微服務的車雲協同計算
随着汽車智能化的逐漸推廣，汽車已經從單純的交通工具轉變為承擔着越來越多功能的載體。如最近比較流行的智能座艙、無人駕駛等概念，不管是智能座艙主打的人機互動體驗、實時安全提醒、智能AR導航等功能，還是無人駕駛L2~L5的各項能力，背後都需要衆多服務和計算去支撐。是否能夠快速将這些服務能力傳遞給客戶使用，就成了一個主機廠需要迫切解決的問題。
對于傳統的車輛開發來說，通常都需要一個較長的周期。要将一項功能部署到車輛上，從設計到生産通常需要3~4年的時間，這就導緻車輛上的硬體規格相對較為保守。此外，受限于成本和能耗因素，硬體算力可能不足以達到要求，特别是在無人駕駛場景下，需要大量基于計算機視覺或雷達資料的路況實時分析等服務。是以，将這些服務遷移到雲端的想法便很自然地産生了。這樣不僅可以大幅降低車輛的制造成本，且基于雲端高性能、可擴充的計算能力，還可以做很多車端勝任不了的計算任務。
但雲端計算存在時延問題。自動駕駛對于智能決策的時延要求非常高，如果移到雲端去計算，勢必會造成時延的增加，這将帶來嚴重影響。例如，車輛在高速公路上以120公裡/小時的速度行駛，每秒鐘就能行駛三十多米，時延增大就可能會引發嚴重的交通事故。由此就出現了為解決時延問題的邊緣計算解決方案，即把雲端那些計算任務移到路側的邊緣計算平台上來進行，進而輔助車輛進行實時的智能提醒和決策。它帶來了三個好處：第一，計算能力大幅提升，有利于提高準确度；第二，不需要占用過多的核心網或骨幹網絡帶寬；第三，可以有效降低延遲時間，車輛通過基站就可以連接配接路上的終端，縮短了資料傳輸路徑，取消了從網際網路到無線核心網再到無線接入網的時間。
這裡出現了車、雲、邊緣計算等多種部署位置。如果為每個場景都單獨開發，必然會帶來巨大的成本和不便性。是以，通過容器建構一個統一的運作時環境就成了必然選擇。一個服務根據場景的需求，可以運作在車、雲或邊緣節點上，使用統一的技術棧既能減小部署成本，也可以根據實際情況進行調整，為主機廠帶來了非常大的發揮空間。
另外，車聯網的資料有着資料量大、類型多、速度快等特點，而這些正是微服務架構所擅長的。通過微服務容易水準擴充的特性，可以跨多個伺服器和基礎架構進行部署，進而很好地支援高并發連接配接數和高吞吐量的需求。同時，利用微服務架構也能解耦不同業務，降低系統的複雜性，使其更加易于部署。
通過容器和微服務的結合，主機廠可以快速将服務部署到需要的位置上，也能從容面對日益增長的客戶數量和需求，由此可見這是一種十分合适的解決方案。
基于吞吐的彈性擴縮容和異地雙活
一個車型的銷量通常都會經曆一段發展過程，如果在開始時建設大量的雲基礎設施，将會産生巨大的财務成本，基于容器化技術的快速擴容和動态調整可以顯著降低成本。例如，在前期車輛數量不多時部署少量容器，在銷量擴大後根據實際的吞吐量去部署相應的服務，就可以減少不必要的成本浪費，降低财務壓力。
并且，因為容器的建立十分快速，能夠根據吞吐量的變化快速擴張或收縮節點的數量，可以更進一步地節約成本。
“以使用者為中心”的車企最需要考慮的是雲服務的連續性和可用性，展現在技術上就是異地雙活。基于Kubernetes管理的容器平台可以通過聯邦的管控能力，來達成多機房多地域多叢集的單元化架構，在一些複雜的場景中為業務提供統一的釋出管控和容災應急能力。
聯邦具有如下特性：
簡化管理多個聯邦叢集的Kubernetes API資源。
在多個叢集之間分散工作負載（容器），以提升應用（服務）的可靠性。
在不同叢集中，能更快速、更容易地遷移應用（服務）。
跨叢集的服務發現，服務可以就近通路，以降低延遲。
實作多雲（Multi-cloud）或混合雲（Hybird Cloud）的部署。
通過利用這些特性，我們可以協調各叢集資源、應用和配置，以實作應用變更管控、分組釋出、鏡像管理、流量調撥、中繼資料管理、叢集資源管理等功能，進而降低運維成本。但任何技術都不是萬能的，這裡我們必須認識到幾個問題：
異地多活是有成本的，包括開發成本和維護成本。需要實作異地多活的業務越多，投入的設計開發時間也會越多。同時也會提高維護成本，需要更多的機器、帶寬。
并非所有業務都一定适用于異地雙活，比較典型的有強資料一緻性的業務，因為資料同步需要時間，可能出現不一緻的問題。
是以，在考慮異地多活時，需要從業務和使用者角度出發，識别出核心和關鍵業務，明确哪些業務是必須實作異地多活，哪些可以不需要異地多活，哪些是不能實作異地多活的。例如“登入”要實作異地多活，“修改使用者資訊”和“注冊”不一定要實作異地多活。
總結
最後，随着技術不斷進步，特别是無人駕駛技術逐漸投入使用，汽車行業必然會出現一個大變局。人們在汽車出行上越來越友善，享受越來越多個性化的服務，汽車會從一個單純的交通工具演變成為人們移動的家。如何快速地為使用者提供這些服務成為了主機廠們必須要面對的問題，這也是軟體定義汽車的由來。而基于微服務和容器化的車雲實踐，正是我們通向未來、更貼近使用者的一個探索。
—END—
本文出自《新程式員002：新資料庫時代&軟體定義汽車》，由60餘位專家傾力創作。随書附贈《2021資料庫全景圖V1.0》和《2021汽車技術與産業生态全景圖V1.0》，同時内含《2021年度資料庫發展研究報告》和《2021年度軟體定義汽車研究報告》，圖文與視訊多媒體呈現。
本書高屋建瓴的産業分析和趨勢預判适合中高端從業人員參考決策。同時，多位專家親曆的入門和實踐之旅也為初學者提供了可借鑒的專業路徑。