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

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

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

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

SOA設計原則

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

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

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

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

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

一、抽象化

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

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

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

二、正式合約

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

三、低耦合

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

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

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

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

四、可復用性

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

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

五、獨立性

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

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

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

六、可組合性

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

七、可發(fā)現(xiàn)性

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

SOA設計舉例

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

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

一、方案一

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

服務接口描述：

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

二、方案二

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

三、方案比較

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

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

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

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

SOA功能分配

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

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

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

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

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

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

寫在最后

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

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

SOA的開發(fā)不能一蹴而就，在各家不斷的開發(fā)實踐中，不斷地優(yōu)化現(xiàn)有的架構以及系統(tǒng)設計方案，直至誕生汽車行業(yè)大一統(tǒng)的指導思想及設計原則。






審核編輯：劉清