從去年開始（可能更早），SOA的概念在汽車軟件行業逐漸蔓延開來，很多公眾號都發過講汽車SOA的文章，很多車廠都要開始（或者已經在）搞SOA。但我覺得吧，在開搞新技術之前，是不是先花點時間弄明白這個技術到底是什么，它解決的是什么樣的問題，然后再談架構，再談開發，很多時候我們連問題是什么都沒整明白，就急著去做解決方案，最后的結果只能是一地雞毛。

對個人來說，要搞SOA開發，需要夯實哪些基礎知識，看了很多SOA文章，卻很少有人梳理這些，這段時間我陸續思考了一些，盡管可能不全面（更偏向SOC開發涉及的技術點），但仍然試圖寫出來，以期逐步構建出自己的領域知識體系（詳見下篇）~

那么，先來理一理關于SOA：

軟件定義汽車，E/E架構是關鍵

汽車電子電氣架構（簡稱E/E架構）是指整車電子電氣系統的總布置方案。在智能網聯汽車產業大變革背景下，軟件定義汽車理念已成為共識。傳統汽車采用的分布式E/E架構因計算能力不足、通訊帶寬不足、不便于軟件升級等瓶頸，已經不能滿足現階段汽車發展的需求，E/E架構的變革已成為智能網聯汽車發展的關鍵，其升級主要體現在硬件架構、軟件架構、通信架構三個方面：

硬件架構升級：由分布式ECU向域控制/中央集中架構方向發展，汽車E/E架構的升級路徑表現為分布式（模塊化→集成化）、域集中（域控制集中→跨域融合）、中央集中式（車載電腦→車-云計算）。好處在于：提升算力利用率，減少算力設計總需求；數據統一交互，實現整車功能協同；縮短線束，降低故障率，減輕質量。

圖片來自網絡

軟件架構升級：通過 AutoSAR 等軟件架構提供標準的接口定義，模塊化設計，促使軟硬件解耦分層，實現軟硬件設計分離；Classic AutoSAR架構逐步向Classic AutoSAR+Adaptive AutoSAR混合式架構發展。好處在于：可實現軟件/固件 OTA 升級、軟件架構的軟實時、操作系統可移植；采集數據信息多功能應用，有效減少硬件需求量，真正實現軟件定義汽車。

通信架構升級：車載網絡骨干由 LIN/CAN 總線向以太網方向發展。好處在于：滿足高速傳輸、高通量、低延遲等性能需求，同時也可減少安裝、測試成本。

中央計算單元——E/E架構的核心

中央計算單元是E/E架構中最關鍵的部分，不管是按區域的架構，還是以后的純中央計算平臺，其硬件構型從根本上決定了軟件架構的設計方向。中央計算單元可以分為以下三種形態：

圖片來自網絡

SOC分離式：將多個不同的芯片集成到一個中央計算單元上去，每個運行不同的操作系統，只是在形態上集中到了一起，各單元依然獨立的完成各自任務；

硬件隔離式：在統一的計算平臺上采用虛擬化方案，同時運行多個操作系統，但是各個系統依然在硬件上進行隔離，每個系統都有自己的專屬硬件資源；

軟件虛擬式：在統一的計算平臺上采用虛擬化方案，同時運行多個操作系統，每個操作系統所使用的硬件資源，由Hypervisor層動態調配，每個系統并沒有專屬的硬件資源。

硬件隔離式和軟件虛擬式，都采用了虛擬化方案，唯一不同點在于硬件資源是否專屬，如果是專屬的，就意味著資源無法動態調配，容易產生資源浪費。虛擬化方案最大的好處是，硬件上的可拓展性，如果中央計算單元采用刀片式的設計結構，可以很方便地拓展計算單元的算力，而不用替換整個計算單元。

在中央計算單元中，只需要兩個操作系統即可，用于自動駕駛、車控、網關的RTOS，以及用于娛樂的普通OS（如Android、Linux）。用于娛樂的OS完全可以通過虛擬機的方式運行，用于自動駕駛、車控、網關的RTOS，可以直接運行在Hypervisor層，既能兼顧實時計算的要求，也能獲得豐富的娛樂系統功能。

SOA——解決軟件定義汽車中服務間通信的分布式架構

在軟件定義汽車中，應用間跨進程或跨核的通信，必然成為軟件架構設計中一個需要去解決的問題。SOA在互聯網已經應用了很長時間，但在汽車行業中，算是比較新的概念。鑒于汽車的應用場景和通信需求有其特殊性，很多互聯網的SOA技術，并不能照搬過來。

雖然Adaptive AutoSAR采用了SOA作為通信架構（ARA：：COM架構如下圖），但是Adaptive AutoSAR的應用可以說還沒有普及，應該說整個行業就沒什么標準的SOA中間件解決方案，幾乎沒有專業做中間件研發的公司，可能在國內這種慢工出細活的東西很難有什么成長的空間和土壤吧。所以，對于汽車SOA，還有很多值得我們去做的研究和嘗試~

摘自《Introduction of ARA：：COM as common communication middleware》April， 2018 by GENIVI

SOA，Service-Oriented Architecture（面向服務的架構），是一種架構思想，實施者可以根據實際情況設計SOA的技術實現。為什么要面向服務？以前用得好好的面向信號或者面向消息的通信架構怎么就不香了？面向服務的通信架構，它的優勢到底在哪里，如果不能很好地理解這點，可能很難從過去面向信號的思維轉變過來，也就無法體會引入SOA的價值和意義。

這有點悖論哈，不去用，無法感受其奧義，但又因為沒用過，對它保有質疑，過往的再擰巴，也是千錘百煉了，從零開始，談何容易。因此，我覺得短時間內不太可能全面鋪開做整車SOA，可能會在安全等級不高的域比如智能座艙先嘗試SOA。

本質上SOA就是服務的集合。在SOME/IP 協議介紹一文中，我寫過對于“服務”的理解。以智能座艙域為例（如下圖），可以把“服務”分為兩類：

基礎服務和應用服務，基礎服務的功能可能包括：總線消息的解析和路由（如車身數據服務）、直接與硬件相關的邏輯處理（如音頻服務）、上層應用有共同需求的一些基礎設施（如日志服務）；

應用服務的功能相對復雜些，可能需要由多個基礎服務提供數據支撐，也可能需要應用服務之間相互協同，實現業務邏輯（如導航服務）。

SOA分層架構視圖（僅作舉例）

這只是一個很簡單的例子，想表達的是，每個服務將自己的功能，以接口的方式提供，基于這些服務和接口，便可以設計出應用場景，以滿足各種用戶需求，提升駕車體驗。可以想象，應用場景的需求一定是豐富且變化的，面向信號的話，新增一個需求，可能要等上一年，但如果服務也能夠方便地進行開發、擴展和更新，是不是好多了，是不是挺有價值呢~

個人覺得，汽車SOA的設計難點，主要在于以下幾點：

服務的定義和劃分，要把業務需求分析透徹，從中提煉出服務的功能，數據流向理清，定義服務的邊界，把握服務的粒度，怎么做到“低耦合，高內聚”，我以前很討厭研究需求，覺得那些不過就是些業務，沒啥技術含量，后來才慢慢認識到，這種想法很危險啊，脫離需求的軟件設計不可能很好地滿足需求，如果不能很好地服務于產品功能，那么再牛逼的技術都沒有機會實現它應有的價值，事實上，能夠把需求文檔轉化為可實施的軟件設計，也是一種能力；

不同系統中，要實現中間件框架或者底層通信基礎設施，Adaptive AutoSAR有ARA：：COM組件，Android有Framework，但不能跨域，QNX/Linux就不用說了。要實現一個中間件框架，本身并不是件容易的事，需要比較強的技術實力，一旦出了問題一般都是重大問題；

服務接口標準化，接口描述語言化（IDL），能夠通過工具自動生成RPC樁的代碼（最好能夠關聯整車通信矩陣，e.g. ARXML-》C++ API），能夠跨平臺，支持多語言，畢竟UI層可能不是C++寫的，時至今日，沒幾個應用愿意去解析原始消息，遠程調用接口不香嘛~；

如何兼容一些沒有與時俱進的設備和模塊，如何兼容舊的傳輸通道，如何盡可能復用以前的業務邏輯，理論上任何兼容都是可以實現的，抽象一層不夠，那就再來一層，但兼容得越多，系統就越復雜，出問題的概率就越大，維護起來就越費勁，這意味著成本的升高，質量卻不見得變好；

評估性能影響，怎么保證安全性，……，如果是基于開源項目，可能還要做二次開發，來滿足這些非功能性質的需求~；

所以，汽車SOA真不是SOME/IP，也不是DDS，更不是Adaptive AutoSAR，這些都是汽車SOA技術棧中的一環，并不是全部。

很多時候，純技術的部分并不是最難的，新的架構方案要達成共識，要真正落地，需要博弈和取舍，需要天時地利人和。作為一名工程師，心態是極為重要的，要分清理想與現實，技術與工作，所以在這里我只想談技術，本來打算梳理一下做汽車SOA開發的基礎知識體系，以后公眾號的內容大致也會圍繞著這個體系去寫，沒想到寫著寫著這么長了，于是分成上下篇了，下面先開個頭吧。

SOA是架構，做SOA的設計和開發，其實也是做架構的設計和開發，在這里我想引用陳皓老師為《架構整潔之道》作的推薦序里的一段話，我常想起這段話，挺有鞭策的功效，分享給每個不想成為PPT架構師的工程師，以共勉：

問題：如果你要成為一名架構師，你需要明確地區分幾組詞語，否則你不可能成為一名合格的工程師或架構師。這幾組詞語是簡單vs.簡陋、平衡vs.妥協、迭代vs.半成品。如果你不能很清楚地定義出其中的區別，那么你將很難做出正確的決定，也就不可能成為一名優秀的工程師或架構師。

陳皓，《架構整潔之道》推薦序一

之前很長一段時間，我經常感到焦慮，一方面不想成為PPT黨，開會黨，另一方面，除了工作還要生（帶）活（娃），留給學習的時間并不多，而想學的知識又如同汪洋大海，今天想好好梳理一下某個技術點，明天搜到某個開源項目蠻感興趣想寫個Demo跑跑看，年輕的時候覺得日子一天天刷刷地過去，也不是什么事兒，現在愈發有種緊迫感。在做了一些架構方面的設計和開發工作以后，更是深刻體會到構建個人的領域知識體系，尤其是一些基礎技術，真的非常重要。

今年伊始，聽了李運華老師關于“如何打好基礎”的講座，核心觀點是：“基礎≠底層，基礎≠源碼，基礎≠不變”，很是醍醐灌頂~結合個人實際情況，我覺得可以這么去構建我的領域知識體系：首先，定義出哪些是與我工作相關的領域知識（比如現階段是SOA）；其次，進一步細化要學習的知識范圍，也就是下篇要梳理的SOA相關知識；

最后，分別從廣度和深度（根據工作內容去判別學習的深度），有針對性地學習，并在實際工作和項目中把知識和技術串起來，從而系統性地提升技術能力。就像前面說的，要分清理想與現實，因為這個世界從來都不是我所能想象的，很多PPT黨開會黨，基礎不扎實甚至很水，設計出焦油坑一樣的架構，坑自己，坑別人，坑項目，也不耽誤他們升職加薪跳槽。但是“世界上只有一種英雄主義，那就是認清生活的真相后依然熱愛它”，不是么，于是才有了寫公眾號的初心和決心。

編輯：jq