業界普遍認為，沒有SOA的下一代電子電氣架構是沒有靈魂的。在這樣的價值觀驅動下，汽車行業開始了轟轟烈烈的SOA運動。而伴隨著車載以太網的量產，SOME/IP、DDS等通訊協議的成熟，Adaptive AUTOSAR、ROS等操作系統中間件的不斷優化，SOA在汽車行業落地的土壤也已具備，SOA也由雷聲大的口號階段進入到雨點小的落地階段。 S

OA雖已是互聯網行業中的一位成名英雄，但在汽車行業卻是一個比較新的概念，目前并沒有一個放諸四海而皆準的指導思想。從各家公布的資料來看，SOA被做成馬的也有，被做成騾子的也有，真可謂是千嬌百媚。

但是正如教員所說：實踐是檢驗真理的唯一標準，基于不同的方法、思想實踐出來的結果，如涓涓細流，終將匯成大一統的SOA指導思想。

前文《SOA，得服務者得天下？》已對SOA基礎知識有過介紹，本文在此基礎上，繼續閑聊一下SOA在落地路上的二三事。

SOA設計原則

SOA在其成名領域——互聯網，用的是客戶端——服務器的架構。客戶端通過網絡向服務器發送請求，服務器響應請求，這是客戶端——服務器架構背后的主要邏輯，毫無疑問這也是互聯網有史以來發布最成功的網絡技術之一。

客戶端——服務器架構之上的進一步抽象是面向服務的范式，這是將服務器中的信息組織成服務的模式，這個服務可以被發現、進行交互或用作已知的語義。

這也就意味著該服務具有確定的行為，在給定相同的條件時，總會產生同樣的結果。 這就好比你去麥當勞點餐，麥當勞提供了從“窮鬼”到“地主”級別的不同套餐，這些套餐就是這家麥當勞門店所能提供的服務，然后你為選擇的服務支付費用。

麥當勞生產這個訂單后，員工會按照麥當勞定義好的流程，一個負責炸薯條，另一個負責制作漢堡，有條不紊地做著自己該做的事情。無論是誰、無論何時點的套餐，顧客最終都會得到他想要的食物。麥當勞的這些服務都是具有預先確定的行為和已知的術語，并且會產生可預知的結果。

上述例子可以讓我們對SOA的實現窺探一二，也可以讓我們試著總結SOA在設計時應盡可能遵循的原則。

一、抽象化

抽象化是SOA非常重要的一個設計原則，是指使用抽象層來隱藏網絡拓撲、通信和實現的復雜性。如果不利用抽象化，而讓客戶端知道實現該服務的所有細節，那客戶端使用該服務的方式將會嚴重制約服務的演化。

對于顧客而言，他們并不需要知道麥當勞內部是什么樣的流程機制，里面的員工是如何進行合作分工。他們僅僅需要關心麥當勞能提供什么服務，以及對應的服務結果是什么。

換言之，我們定義服務的接口時（相當于菜單），也僅僅需要把服務接口實現方式（顧客消費方式）和接口調用的結果（食物照片）定義清楚。 為了確保遵循該原則，服務的公開狀態應該盡可能地少。此外，只應規定服務行為的外在表現。

二、正式合約

一個服務之所以被稱為服務，是因為其給公開的功能以及如何實現提供了正規的描述，即正式合約。這其實就是我們做SOA設計時定義的服務接口，每一個接口都應該有明確的定義以及實現方式。

三、低耦合

在面向對象的軟件中，單獨的系統組件指的是被設計成無邊界效應的獨立對象。那些發生在組件之間的相互作用可以被明確地定義和測試。將依賴關系減小到最小程度，也就是低耦合，使修改服務的實現方式時不會帶來意想不到的邊界效應，從而降低風險。

而對于SOA低耦合的設計原則，主要包括兩個方面：

（1）一是服務的實現方式和正式合約應該分離開來。服務的正式合約只要不變或者修改，那不管實現方式如何變化，這都不影響。就像去麥當勞點了一個套餐，只要套餐內容不變，不管麥當勞內部人員怎么分工，是一個人炸薯條再做漢堡，還是分不同的人分別去炸薯條和做漢堡，對于服務使用方來說結果都是一樣的，他并不關心服務是怎么實現。

（2）二是服務的實現過程不要依賴另一個服務的結果。就比如麥當勞A客戶點了套餐A，B客戶點了套餐B，就算套餐B不能完成，那也不會影響套餐A的制作。

四、可復用性

可復用性其實是SOA設計所期望的設計目標。真正的可復用性是讓服務適用于多種不同應用的能力。進行一項服務的設計時，如果沒有進行認真地思考，它可能僅能滿足某種特定的應用。

而經過思考的良好設計，服務可以與具體的實現過程相獨立，這就意味著該服務可以在其它的應用中快速地復制。

五、獨立性

每一個服務與客戶端的狀態應該是相互獨立的，它應該有它內部既有的工作流程，而不依賴于客戶端的狀態。

這樣做的目的是剝離客戶端與服務端的狀態交互，這樣做的目的是無論客戶端來自哪里，在任何時間、任何地點請求同樣的服務，服務端都以同樣的方式響應，從而得到相同的結果。

就像當顧客點了一個漢堡時，麥當勞門店只要按照既有流程去制作就行，期間不用關心該用戶是誰、來自哪里。

六、可組合性

我們在進行服務的設計時，為了低耦合，我們往往把服務設計得小而精。然而在進行汽車的服務架構開發時，整車的系統往往是復雜的。經常會有不同的用戶使用場景，針對不同的使用場景，利用現有的服務，鼓勵可以聚合大的服務，以實現更高級別的應用。比如說漢堡、炸雞、薯條、可樂這些都是屬于小的服務，門店可以自由搭配組合形成新的不同套餐，在價格中形成一定的優惠，以供客戶選擇。應用到車上，氛圍燈、座椅、空調、音樂等屬于小的服務，車企可以根據不同的組合，形成不同的用戶場景，比如休憩模式關閉所有燈光、音樂，座椅和空調調整到舒適位置。

七、可發現性

可發現性指的是用戶可以通過某種特定的方式查詢到該服務，而不是通過靜態編程的方式。例如在高德地圖中輸入麥當勞，你就可以得到附近的門店的位置，而不用在手機中把每個門店的地址記下來。

SOA設計舉例

上文簡單介紹了SOA設計時的七個指導原則，但在真正進行某個子系統的SOA設計時，其實會面臨更多的問題。每一個系統工程師對方案的理解不一樣，都將導致設計出來的架構不一致。

當然這個沒有對錯之分，畢竟通往珠峰的道路也不是只有一條。 下面以控制空調的開和關為例，比較SOA兩種設計方案。

一、方案一

服務端（空調模塊）提供開和關的接口，客戶端（娛樂主機）調用這個服務接口來請求空調的開和關，服務端根據自身的控制邏輯執行空調的開和關。

服務接口描述：

HVAC ON/OFF_Req：客戶端可通過調用這個接口來打開或者關閉空調。 HVAC ON/OFF_Resp：服務端根據自身的邏輯，收到請求后反饋給客戶端執行結果，如果正常執行就反饋“執行成功”。如果不執行，就反饋“執行失敗”且會攜帶失敗的原因，比如“執行失敗，整車未上高壓或者發動機未啟動”。

二、方案二

服務端（娛樂主機）發布空調開和關的請求事件，客戶端（空調模塊）訂閱這個事件接口，當該接口為空調開或者關請求時，用戶根據自身的控制邏輯執行空調的開和關。

三、方案比較

從結果上分析，兩種方案對用戶的體驗實際上是一樣的，都能實現對空調的開和關，但是細究下來還是有不少差異的。

方案一的優勢是服務端提供統一的接口，客戶端可以根據自身的需求調用。服務端可以不關注客戶端是誰，只要根據自身的內部邏輯進行空調的狀態跳轉。

方案二其實細看就像上一代面向信號的架構，只是把之前的信號重新包裝成服務的形式在以太網上傳輸，相當于脫褲子放屁。基本可以用現有的軟件架構，把接口名字改改就可以上車，開發的代價最小，但是沒有任何擴展性可言。如果有其他的APP想控制空調，那就需要重新發布一個接口，客戶端（空調模塊）需要重新訂閱該新的接口，從而實現另一種控制方式。

從短期來看，方案二是實現所謂的SOA代價最小的方案。但是作為要面向下一個十年甚至二十年的架構設計來說，方案一才是主流的方案。雖說在開發過程中還會遇到其他問題，但是總體的架構思路和方向是對的。

SOA功能分配

上面介紹的是SOA某個服務的架構設計方案，在進行系統的詳細設計時，比如說具體到SOA的功能分配，就又面臨另一個問題。 還是上文空調控制舉例，比如在進行空調的控制時，需要判斷車輛狀態，當整車處于高壓或者發動機啟動時才能開啟空調。

方案一中如果把對車輛狀態的判斷放在客戶端，那么意味著每一個客戶在控制空調時，都要先獲取車輛的狀態，只有滿足車輛處于高壓或者發動機啟動時，才能調用空調的控制接口。服務端收到空調的控制器指令，執行相應的動作。

這么做的好處是服務端提供的接口內部邏輯可以做的很簡單，不會隨著前置條件的變化而變化，把控制的前置條件判斷上移到客戶端。壞處是對每個客戶端提出了更嚴苛的調用條件，如果該服務僅僅針對內部軟件的團隊進行開發，那相對來說是可控的，可以通過設計文檔審核以及測試進行把控，不會出現客戶端在前置條件不滿足時就調用服務端的空調控制接口的情況。

然而如果這個接口開源的，那顯然這樣的設計方案不合理，因為對于開源的接口，不可能要求每個開發者嚴格按照規則去做，一旦有某位開發者開發的APP沒有判斷前置條件就直接調用空調的控制接口，那有極大的概率出現小電池被耗盡電的問題，除非有智能補電功能。

方案一中如果把對車輛的狀態判斷放在服務端，對于客戶端來說，就可以很簡單，只要想控制空調，那就調用服務端的接口，至于能不能開啟，服務端會根據車輛的狀態反饋給客戶端。

這僅僅是針對單一車型，對于不同的車型以及應用場景，可能開啟空調的前提條件不同，所以在進行服務的接口定義時，先定義和開放適用于大部分應用場景的接口，至于特殊的需求，經過評估后再確認是否需要定義新的接口。 這里要闡述一個觀點，服務并不是一成不變，且不要想著一個服務接口就可以覆蓋用戶所有的使用場景。

寫在最后

SOA在互聯網行業的成熟經驗可參考，但也僅供參考，如果是拿來主義，那注定是不會成功。要想把這個概念用到汽車行業，且用得好，無論是使得軟件復雜度減少，亦或者為將來的功能拓展帶來便利性，這些都需要進行深刻的理論分析以及實踐應用。

SOA的系統設計也是這幾年剛剛興起，每一家的架構以及系統方案都不一樣，但從筆者的拙見來看，SOA目前的收益其實并沒有宣傳的那么大，投入產出比嚴重不平衡。

SOA的開發不能一蹴而就，在各家不斷的開發實踐中，不斷地優化現有的架構以及系統設計方案，直至誕生汽車行業大一統的指導思想及設計原則。






審核編輯：劉清