簡述面向服務(wù)的架構(gòu)SOA開發(fā)基礎(chǔ)

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

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

那么，先來理一理關(guān)于SOA：

軟件定義汽車，E/E架構(gòu)是關(guān)鍵

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

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

圖片來自網(wǎng)絡(luò)

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

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

中央計算單元——E/E架構(gòu)的核心

中央計算單元是E/E架構(gòu)中最關(guān)鍵的部分，不管是按區(qū)域的架構(gòu)，還是以后的純中央計算平臺，其硬件構(gòu)型從根本上決定了軟件架構(gòu)的設(shè)計方向。中央計算單元可以分為以下三種形態(tài)：

圖片來自網(wǎng)絡(luò)

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

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

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

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

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

SOA——解決軟件定義汽車中服務(wù)間通信的分布式架構(gòu)

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

雖然Adaptive AutoSAR采用了SOA作為通信架構(gòu)（ARA：：COM架構(gòu)如下圖），但是Adaptive AutoSAR的應(yīng)用可以說還沒有普及，應(yīng)該說整個行業(yè)就沒什么標準的SOA中間件解決方案，幾乎沒有專業(yè)做中間件研發(fā)的公司，可能在國內(nèi)這種慢工出細活的東西很難有什么成長的空間和土壤吧。所以，對于汽車SOA，還有很多值得我們?nèi)プ龅难芯亢蛧L試~

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

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

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

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

基礎(chǔ)服務(wù)和應(yīng)用服務(wù)，基礎(chǔ)服務(wù)的功能可能包括：總線消息的解析和路由（如車身數(shù)據(jù)服務(wù)）、直接與硬件相關(guān)的邏輯處理（如音頻服務(wù)）、上層應(yīng)用有共同需求的一些基礎(chǔ)設(shè)施（如日志服務(wù)）；

應(yīng)用服務(wù)的功能相對復(fù)雜些，可能需要由多個基礎(chǔ)服務(wù)提供數(shù)據(jù)支撐，也可能需要應(yīng)用服務(wù)之間相互協(xié)同，實現(xiàn)業(yè)務(wù)邏輯（如導(dǎo)航服務(wù)）。

SOA分層架構(gòu)視圖（僅作舉例）

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

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

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

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

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

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

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

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

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

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

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

陳皓，《架構(gòu)整潔之道》推薦序一

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

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

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

編輯：jq