自動駕駛軟件架構之中間件與SOA介紹

3.3.5 服務代理

車載軟件發(fā)展了幾十年，有大量的穩(wěn)定成熟的既有代碼。車內廣泛使用的網絡總線也有Can、 Lin、 FlexRay 等很多種，連接在這些網絡上的ECU 很難去支持服務發(fā)現、發(fā)布訂閱等機制。對于這些成熟的既有系統(tǒng)，可以為它們增加一個代理服務。代理服務仍然按照原有的方式(如:Can 總線)跟既有系統(tǒng)進行通訊。但是代理服務對外可以以獨立SOA服務的方式呈現，提供標準的訪問接口， 接口暴露既有系統(tǒng)可以開放的部分能力。下圖在SOA架構風格上增加了服務代理風格。



圖3. 10客戶-服務器-狀態(tài)分布-服務發(fā)現-發(fā)布訂閱-代理

服務代理還帶來另一個好處。被代理的軟件模塊被隱藏在代理服務后面，可以單獨進化。比如采用不同的技術路線網絡總線重新實現。

但是服務代理作為額外的間接層會降低效率和用戶可察覺的性能。所以服務代理暴露出哪些原有軟件模塊的功能需要仔細選擇。比如，被代理的模塊是一個實時性要求很高動力系統(tǒng)ECU，那就沒必要把該ECU的高實時要求的控制信號暴露出來，只應該暴露出實時性要求不高的狀態(tài)發(fā)布的等信息接口。

3.3.6 服務裝配

在進行服務劃分的時候，我們希望把每個服務設計得盡可能功能單一，這樣服務簡單，方便開發(fā)、測試和復用。但是會造成服務數量變大。

在服務可以執(zhí)行之前，它必須被加載到應用程序（操作系統(tǒng)進程）的地址空間中。如果每個服務一個進程，如果有上百個服務，就會造成操作系統(tǒng)中運行著上百個進程，爭搶系統(tǒng)資源。相當與把服務調度的工作交給了操作系統(tǒng)，讓操作系統(tǒng)的進程調度代為執(zhí)行服務的調度。我們知道，操作系統(tǒng)的進程切換是開銷非常大的操作，也無法保證調度的精確性。比如，我們希望一個服務每秒鐘執(zhí)行30次（軟實時），當有上百個繁忙的進程在系統(tǒng)中執(zhí)行時，操作系統(tǒng)的進程調度策略是無法保證這個服務的調度要求的。

我們可以把多個相關的服務裝配到同一個服務容器進程中，由服務容器來對這些服務進行調度。這樣可以在用戶空間而不是內核空間進行服務切換，避免了大部分進程切換的系統(tǒng)開銷。同時可以自定義調度算法以滿足服務的需要的調度要求。

如果服務裝配策略(哪些服務裝配到一個進程里)是在開發(fā)早期就做出了決策，這個時間開發(fā)人員往往并不知道服務搭配或部署的最佳方式，一旦決策有誤，再變更難度就很大。此外，對“最佳”配置的定義，很可能會隨著計算環(huán)境的變化而變化。 如果服務的實現與其初始配置緊密耦合，則修改服務可能會對其它服務產生不利影響，比如會導致其它服務需要被重新編譯和部署。

解決問題較好的辦法是動態(tài)服務裝配機制。每個服務開發(fā)時并不是被預設為單獨的進程，而是一個可以被動態(tài)加載的模塊。(如：動態(tài)鏈接庫Windows 上的DLL或Linux 上的 SO 文件）。在服務部署時才決定哪些服務被裝配到同一個進程中。也可以在運行時才根據需要的加載服務，并在利用完成后卸載。甚至可以讓服務在不同進程、不同操作系統(tǒng)中遷移(從一個進程中卸載，在另一個進程中裝載)。



圖3. 11客戶-服務器-狀態(tài)分布-服務發(fā)現-發(fā)布訂閱-代理-裝配

每個服務聲明自己的調度要求(執(zhí)行的頻次，要求完成的時間等)，由服務容器的調度算法來滿足，不能滿足時也能獲知并收到告警。圖3. 11將服務裝配加入了我們的SOA架構風格。

“服務容器”本身也可以被設計成SOA服務，提供服務管理接口，用于加載、管理其它服務。所以圖中“服務容器”繼承自“服務器”，多個“服務器”又可以裝配到“服務容器”。

從“關注點分離”的角度看，服務裝配分離了“服務實現”與“服務部署”兩個關注點?！胺諏崿F”時優(yōu)先關注功能的定義與實現，而部署決策可以被延遲指定。

服務裝配還帶來另一個優(yōu)點，就是為服務之間的數據交互提供了優(yōu)化的空間。雖然我們默認采用通過網絡進行數據交換。但是當兩個服務部署在一個進程內時，顯然有更合適的數據交換通道。后文會進一步討論這個問題。

3.3.7 服務監(jiān)督

對系統(tǒng)中的服務進行監(jiān)督管理是必要的。比如，Linux 系統(tǒng)的系統(tǒng)管理守護進程“Systemd”就是用于對Linux 系統(tǒng)服務進行監(jiān)督管理。它會根據預定的配置在合適時間啟動服務，并監(jiān)督服務進程，如果進程消失，會自動重新啟動。Systemctl 命令就是用來與 Systemd 服務進行交互的命令行接口。

對SOA服務而言，我們需要對服務的“生命周期”、服務的“健康狀態(tài)”還有“服務質量”進行監(jiān)督管理。

?

圖3. 12 SOA：客戶-服務器-狀態(tài)分布-服務發(fā)現-發(fā)布訂閱-代理-裝配-監(jiān)督

管理服務的“生命周期”是指要決定什么時候加載、啟動服務，什么時候關閉、卸載服務。當系統(tǒng)中只有少數服務的時候這個問題可能不是很嚴重，簡單的系統(tǒng)就是啟動時所有服務都起來。但是當部署了幾十上百個互相依賴的服務后，服務的“生命周期”問題就很重要了。

尤其車載ECU需要對功耗進行控制，當前場景不需要的服務應該盡可能不啟用。比如，泊車場景需要使用環(huán)視攝像頭的圖像識別車位線，當判斷車輛行駛在高速公路上是，車位線識別的算法服務顯然沒必要加載。當車輛到達導航的目的地附近時，車位線識別服務可以被預先加載，但是不激活(執(zhí)行算法識別)，當用戶啟用泊車功能時，算法服務開始工作，泊車過程結束，算法服務停止計算。

服務“健康狀態(tài)”的監(jiān)督包括確定服務是否異常退出，服務所依賴的資源是否不可用而導致服務狀態(tài)不正確。尤其是多個服務相互依賴時，服務的“健康狀態(tài)”問題會順著依賴鏈進行傳播。在車載系統(tǒng)中，這跟故障診斷和功能安全密切相關。

即便服務在持續(xù)工作，但是它的“服務質量”是否滿足要求也是需要被監(jiān)督的。服務質量包括其響應時間，系統(tǒng)資源占用等等。對于檢測出來的問題，“監(jiān)督服務”需要決定處置措施，比如：重啟、告警、功能降級等等。

圖3. 12是在我們的SOA架構風格中增加的“服務監(jiān)督”風格。監(jiān)督服務本身也是一個SOA服務，只是有自己定義的標準化服務監(jiān)督接口。所以圖中“監(jiān)督服務”繼承自“服務器”。監(jiān)督服務與服務容器和其它SOA服務通過監(jiān)督接口進行交互。

3.3.8 RESTful API

對于互聯(lián)網行業(yè)的開發(fā)人員來說，REST 以及 RESTful API 是司空見慣的事情。REST設計風格以及基于REST的HTTP協(xié)議是互聯(lián)網軟件架構基礎。REST 是一個龐大話題，參考資料[23]中有詳述，這里不多介紹。RESTful API 是基于REST 的原理，基于Http 協(xié)議實現的API 設計原則，遵循這些原則，可以設計出清晰簡潔易于維護的API接口。

更為重要的是，各種異構系統(tǒng)，如果能夠對外提供基于 HTTP 實現的RESTful API，就可以在更大范圍內做應用系統(tǒng)的集成。比如各大云服務提供商(AWS,阿里,百度等)，都為它們的各種云基礎設施提供了 RESTful API接口，我們就可以很方便的使用程序去管理我們的云端資源（如創(chuàng)建一臺云主機，讀取或更新數據庫）。



圖3. 13 SOA：客戶-服務器-狀態(tài)分布-服務發(fā)現-發(fā)布訂閱-代理-裝配-監(jiān)督-Restful

現代智能網聯(lián)汽車會與互聯(lián)網有非常多的數據交互，這些交互不像車內通訊要求有很高的實時性，但是外部系統(tǒng)確有復雜的多樣性，我們可以為某些服務提供RESTful API，以便能更好的與外部系統(tǒng)集成。圖3. 12在 SOA架構風格中增加了RESTful API 約束。

RESTful API 設計有一些指導原則，可以參見 MicrosoftREST API Guidelines。這里做一些簡要的說明。 設計RESTful API 首先要做好URI 的規(guī)劃，需要把服務中的概念映射成合適的URI。比如我們給娛樂系統(tǒng)的音量設計一個 URI 來表示，那就可以對這個 URI使用 HTTP 的GET 和 PUT 方法來讀取和設置音量值。

HTTP協(xié)議的操作方法很少，只有9個。RESTful API 最常用的方法主要是 GET、PUT、POST、DELETE，使用這幾個方法就可以完成常見的CURD操作(create，update,read, delete)。這些操作方法如何映射到 SOA 服務的方法有一些基本的原則，這里結合SOME/IP 來做一些說明。

HTTP 的GET方法有一個要求，就是它不應該改變被調用的服務的狀態(tài)，它只是讀取一個URI的值，而不會改變它。PUT 方法有一個特點，其任意多次執(zhí)行所產生的影響均與一次執(zhí)行的影響相同，數學上管這個叫“冪等”(GET/PUT/DELETE 方法都是“冪等”的,但只有 GET不改變狀態(tài))。SOME/IP 協(xié)議中與之對應有同樣特性的是Field。所以對于服務中的 Field 字段應該映射為 RESTful 的GET/PUT 方法進行操作。

SOME/IP 中的 Method 應該映射為對某個 URI 的POST 操作。RESTful推薦用良好的 URI 規(guī)劃來更準確的表達領域的語義。所以比較合適的方式是每個Method有其URI，Method的參數和返回值體現在 POST 方法的提交數據和響應結果上。

SOME/IP 的 Event 映射為RESTful API 時比較麻煩，因為HTTP1.1協(xié)議是不支持向客戶端主動通知的，不過有變通的WebSocket 方案，HTTP/2 是可以支持的，都需要由客戶端向服務器發(fā)起GET 請求，服務器有需要向下通知的數據時就返回數據內容。

這些就是SOA 服務轉換為 RESTfulAPI 的基本映射方式。一般來說并不需要為所有服務設計RESTful API，只為需要與外部系統(tǒng)集成的服務提供RESTful API即可。

3.3.8 可選的其它風格

“虛擬機/解釋器”風格

這里的“虛擬機”指的是受控的代碼執(zhí)行環(huán)境，比如 JavaScript 虛擬機，Lua腳本解釋器等。服務器向客戶端下發(fā)一段代碼，客戶端在嚴格受控的執(zhí)行環(huán)境中執(zhí)行代碼。這個受控的環(huán)境只能訪問指定的資源，對資源的訪問權限被限制在預定義的范圍內。

對車載應用來說，對這種方式的需求往往出現在與云端有交互的場景。因為“虛擬器/解釋器”可以先部署到車上，易變的需求可以后續(xù)由云端下發(fā)代碼來滿足，這在車載娛樂系統(tǒng)中會很常見。我們舉一個為自動駕駛服務的數據采集場景來說明。

自動駕駛的很多算法以及測試場景非常依賴對數據的收集，相對于專業(yè)的采集車，量產汽車可以提供更為真實的數據案例，更廣的覆蓋范圍。采集并上傳哪些數據需要一些規(guī)則進行控制，否則沒有針對性的大量數據上傳會對帶寬占用、數據存儲、數據分析帶來不利的影響。

可以在車輛量產時內置數據采集和上傳的能力，以及檢查采集規(guī)則的規(guī)則引擎。具體的采集規(guī)則由云端根據需要下發(fā)。比如視覺算法需要改進對雨霧天氣的識別效果，就對出現雨霧天氣的區(qū)域車輛下發(fā)采集規(guī)則的更新。車輛數據采集服務接收規(guī)則本地執(zhí)行，觸發(fā)數據采集事件。這樣采集的數據內容可以根據需要隨時調整，帶來了較好的靈活性。這時規(guī)則引擎就相當與一個受限的解釋器，下發(fā)的規(guī)則內容就是被執(zhí)行的代碼。

“遠程求值”風格

“遠程求值”風格跟“虛擬機/解釋器”風格正好相反，是客戶端把代碼送到服務端執(zhí)行。同樣，這種方式的需求也出現在與云端有交互的場景。之所以把代碼送到服務端執(zhí)行，是因為執(zhí)行所需要的數據在服務端。這些數據或者是因為數據量大不便傳輸，或者是因為數據安全或數據隱私的原因，不能被下發(fā)給客戶端?？蛻舳丝梢詫⒋a發(fā)送到服務端執(zhí)行，利用數據，取回結果。

這種方式在智能網聯(lián)汽車的“車路云協(xié)同”上是有應用場景的。根據需要，聯(lián)網的路側單元至少可以保存道路沿線一定距離內的道路、車輛等信息，云端的服務器可以保存更大范圍內的交通狀況數據。這些數據都不方便直接發(fā)送給行駛中的車輛。當然路側單元和云端服務器都可以根據自己保存的數據提供一些預定義的服務，供車端調用。但是更靈活的方式，是開放執(zhí)行環(huán)境，由車端上傳代碼來決定如何利用數據。當然被執(zhí)行代碼的權限也會被限制，執(zhí)行環(huán)境也會是一個受限的沙箱。

這種方式優(yōu)點是能夠定制服務器組件的服務，這改善了可擴展性和可定制性；代碼直接在服務端執(zhí)行，減少了服務器與客戶端的交互能夠得到更好的效率。由于客戶端發(fā)送代碼而不是標準化的查詢，因此缺乏可見性。服務器如何信任客戶端，如何控制執(zhí)行環(huán)境的安全性也需要考慮。這會對服務的部署帶來難度。

3.3.9 小結

這一節(jié)通過對SOA架構風格的推導，闡述了車載軟件的SOA 風格并不是一個單一的架構風格，是一系列軟件架構風格的組合。

對于車載軟件，我們首先考慮的是如何降低其復雜性，劃分為依賴性盡可能小的多個服務，是一種化整為零的方法。為了讓服務盡可能簡單，需要考慮服務的狀態(tài)分布，強狀態(tài)依賴的功能集中在特定服務，讓其它服務以盡量以無狀態(tài)的方式設計，以利于整體系統(tǒng)的開發(fā)、測試、復用。服務發(fā)現用來簡化大量服務的配置，基于事件的發(fā)布訂閱讓服務之間的通訊偶合性降低。服務裝配用于更好管理服務的部署，服務監(jiān)督讓服務的可靠性得到保障。

RESRful API 增強車內服務與外部系統(tǒng)的互操作性。 這些軟件架構風格很多都是在各個領域得到了廣泛應用，以各種不同的形式存在。針對特定的應用場景，選擇不同風格的組合，發(fā)揮各自的優(yōu)勢，往往能產生1+1>2 的效果。

3.4 SOA 的架構元素

前文3.1.1節(jié)提到，軟件架構由三個方面組成，架構元素，架構的組成形式，和一些形成架構的基本原則。前文SOA推導時每一步都對此三個方面有一些體現。這里我們再從整體上來對架構元素的區(qū)分以及其組成形式做一些分析。 架構元素分為“處理元素”、“數據元素”、“連接元素”。

SOA 的“數據元素”比較容易識別，無論是RPC調用還是消息的發(fā)布訂閱，都是數據在不同服務之間傳遞。深入理解這一點最好的方式是與面向對象的分布式系統(tǒng)做對比。面向對象的核心概念之一是“封裝”，其關鍵含義在于將數據以及操作數據的方法封裝在對象實例中，對象私有數據對外不可見。這可以理解為將“數據元素”與“處理元素”封裝在了一起。面向對象的軟件設計就更關注如何將領域概念轉換成合適的對象模型，定義對象的行為和操作，以及對象之間的組成結構。

與面向對象的方法對比，SOA 架構中“數據元素”和“處理元素”的耦合度就低很多。基于消息的發(fā)布訂閱完全是從數據的視角看世界，基本不關心數據如何被處理，只關注數據之間的供需關系。RPC請求可以被理解為“一對一”的數據供給與需求關系。

尤其在無狀態(tài)服務中，多個RPC請求之前沒有狀態(tài)上的關聯(lián)性，SOA服務的數據處理能力就更為“純粹”(函數式編程的中的概念，也稱作無副作用)。大型系統(tǒng)在設計時，考慮問題的視角就是如何尋找合適的數據邊界以界定服務邊界，而不是對領域進行對象建模，這與分布式對象系統(tǒng)是完全不同的設計理念。與分布式對象的對比，在3.5.1節(jié)中還有進一步的討論。

開發(fā)SOA架構中的“處理元素”是某個具體SOA服務的開發(fā)人員的職責，我們希望開發(fā)人員專注于這個具體數據處理的實現，比如某個AI算法，某個數據集的MapReduce過程。而數據從哪來，到哪去，開發(fā)人員不需要關心，這由SOA的“連接元素”來負責。

在實際工程實踐中，SOA服務的開發(fā)者并不會完成全部的從數據處理到數據通訊的全部工作，而是要借助分布式中間件系統(tǒng)來實現。中間件提供Runtime庫，IDL規(guī)范，程序語言特定的代碼生成工具。使用IDL定義出數據通訊協(xié)議后，再用工具根據IDL生成代碼。用戶編寫“處理元素”，使用IDL生成的代碼與外部通訊。這時候，IDL生成的代碼和中間件Runtime 就扮演了“連接元素”的角色。它從通訊通道接收數據傳遞給“處理元素”，將處理的結果發(fā)送給需求者。

一個SOA系統(tǒng)在整體設計時，架構師要關注“數據元素的定義”，“處理元素”的劃分， 以及選擇合適的“連接元素”將它們組合在起來。但當將某個明確的數據處理要求委托給某個團隊(如：內部的某個算法團隊，或者外部的供應商)開發(fā)時，架構師希望連接元素對與該團隊是透明的。

也就是說數據的處理不應該依賴于特定的連接方式。架構師甚至希望只需要提供給開發(fā)團隊模擬的連接方式并回放預先錄制的數據，開發(fā)團隊基于這些來實現其數據“處理元素”?！疤幚碓亍钡耐瓿善房梢员患軜嫀熂傻秸鎸嵉膽铆h(huán)境中，那時使用的可能是不同的連接元素。

中間件Runtime能夠使用SOME/IP、DDS、共享內存等各種不同連接通道；工具根據IDL生成的代碼完成用戶代碼和中間件Runtime的連接；服務發(fā)現讓服務的位置不是固定的而是可以被配置、可動態(tài)發(fā)現的，這些都是在發(fā)揮“連接元素”的作用。

從“關注點分離”的視角看，SOA架構在三類主要的架構元素上實現了關注點分離，這也是它適合用于復雜系統(tǒng)集成的重要原因之一。

3.5 SOA相關其它問題討論

3.5.1 SOA vs 分布式對象

分析 SOA，如果跟分布式對象做一些比較，可以更好的理解SOA的意義。我們在3.2 節(jié)提到的架構風格中有“分布式對象”風格。前文也提到CORBA 和 ZeroC ICE 都是分布對象的實現。

SOA 和分布式對象都是分布式網絡架構的實現形式。只不過一個是 Service Oriented ，一個是 Object-Oriented。我們來看看他們有什么異同，為什么車載軟件選擇 Service-Oriented 而不是Object-Oriented。

面向對象（Object-Oriented）是非常重要的軟件設計思想。當軟件規(guī)模進一步復雜后，“結構化編程”方法也體現出一定的不足。面向對象的設計思想是解決這些問題的方法論之一。

從C++開始，大多數程序設計語言都支持面向對象的方法論。它把數據和處理數據的方法封裝在一個對象中，可以用來與具體的現實事物或抽象的語義概念進行對應。提供了對現實問題或語義概念進行建模的可能，用來描述復雜的軟件語義。

程序語言創(chuàng)建的對象是本地對象，即訪問對象的內部數據和接口方法都是當前進程內的行為，不涉及網絡通訊。當面向對象的設計理念在本地編程獲得成功后，人們很自然的會想到，在分布式領域中是不是可以使用類似的方法。一個對象封裝了數據和操作方法，部署在某個服務器上，客戶程序通過網絡進行訪問。

在客戶端也提供本地化的API接口，使用這些API時跟訪問本地接口一樣，但是請求會被自動代理到服務器上的某個對象。這就是分布式對象的由來。 CORBA 標準建立之初，人們曾經認為這將是未來主流的分布式技術。但實際上世界上最大的分布式系統(tǒng)萬維網(WWW)，并沒有采用分布式對象。車載軟件的分布式化選擇了SOA，也沒有選擇分布式對象。我們從幾個角度來探究其背后的原因。

強“狀態(tài)相關”的服務不利于可擴展性

3.3.2 節(jié)討論了程序狀態(tài)在客戶端和服務器端的分布情況對軟件架構的影響。我們傾向于將服務設計成無狀態(tài)的。這在WWW 的架構中尤為重要，這是WWW 世界能成為超大規(guī)模系統(tǒng)的關鍵原因之一。

分布式對象將數據與操作接口封裝在一起，也意味著它將狀態(tài)留在了服務器端。從這種意義上看分布式對象架構風格與遠程會話風格有點接近，每一個遠程的分布式對象自身就是一個小的會話。對于同一個遠程對象的多次方法調用，都要精準的找到這個對象所在的位置。

對于 WWW 來說，這種方式會嚴重影響其可伸縮性。WWW 中，每一次請求的無狀態(tài)特性可以讓一個負載集群系統(tǒng)中的任何一個空閑的服務器都可以處理任何請求，而不需要一定讓多個請求必須綁定到同一個服務器。

對于車載軟件來說，雖然整體系統(tǒng)很復雜，但是到單個具體的服務點，其功能往往是很單一的，處理邏輯的復雜度遠遠小于電子商務等系統(tǒng)。很多時候就是接收數據，做簡單處理，然后發(fā)送數據。面向對象的建模對這些簡單功能來說帶來了不必要的復雜度。無狀態(tài)的服務設計方式能讓系統(tǒng)大大簡化。

不同對象的接口差異大

面向對象的設計方法很重要一點是對行業(yè)領域進行建模，分析出各種對象類型以及它們之間的關系。不同類型的對象就包含不同的狀態(tài)數據以及不同的操作接口。

對象類型多、接口各不相同對于開發(fā)本地應用來說不是大問題，因為一般應用程序也就幾十的對象類型，即便幾百個也是在可以處理的數量級內。但是對于WWW 系統(tǒng)，可能會面臨幾千萬甚至更高數量級的對象類型，沒人能處理這么復雜的系統(tǒng)互操作。

WWW 采用的 REST 架構的一個關鍵設計約束是統(tǒng)一接口，實際只有GET, PUT, POST, DELETE等有限幾個操作方法。僅僅這幾個操作方法就能完成 WWW上各種復雜的功能，非常的神奇。奧妙在于WWW 使用URI（統(tǒng)一資源標識）重新定義世界。

WWW上的每一個事物(簡單的文件、圖片；或者訂單、人等各種語義概念)都可以使用一個 URI去表示。世界的復雜性從對象模型的關系，轉換到了樹形的URI表示，從而采用簡單的操作方法完成所有可能的操作需求，如果不能滿足，就再拆解出一個合適的URI形式。

對于車載軟件來說，服務的類型數量也是在一個可控的數量級，并不需要URI機制去簡化接口形式。但是如前文所說，當汽車軟件需要與云端或者互聯(lián)網體系進行數據交換時，可以把車載軟件的部分服務包裝成RESTful 接口遵循WWW系統(tǒng)的架構風格。

對象生命周期管理復雜

無論是本地對象還是分布式遠程對象，都會有一創(chuàng)建、初始化、工作、失效、銷毀的完整生命周期。對于分布式對象來說，其生命周期管理非常復雜。比如，當一個客戶端請求某個對象的服務是，這個對象可能不存在，那么這種情況下如何處理也需要被考慮。

一般來說這種對象生命周期管理能力是由中間件系統(tǒng)來提供，CORBA，J2EE規(guī)范中都有對應的內容。會導致中間件實現的復雜度。

分布式對象系統(tǒng)，當然是希望以統(tǒng)一的方式管理大量的對象，比如成千上萬的訂單。只有這樣才值得在開發(fā)復雜中間件實現時的投入。然而對于車載軟件，很多軟件模塊恐怕只有一個對象需要被管理，比如上文的ACC 會話。一輛車同一時間內是不可能產生兩個及以上ACC會話的。即便某些服務需要多個會話實例（相當于要管理多個對象的生命周期），那這個復雜性由服務自身去處理。

比如某個服務內部確實需要保存多個不同對象(或會話)的實例，那么可以提供類似“createXXX”的接口并返回對象的句柄，然后在其它的接口方法參數中帶上這個句柄。服務實現時根據這個傳入的句柄去找到對應的對象進行操作。至于對象的生命周期，服務開發(fā)者自己想辦法維護。而不需要在中間件這一層提供架構級別的解決方案，因為投入與收獲不匹配，并且?guī)聿槐匾膹碗s度。

3.5.2 RPC消息通訊管道 的技術關聯(lián)

RPC 是“客戶-服務器”架構風格實現請求響應的典型方式?！盎谙⒌耐ㄓ崱?或者叫基于事件的集成、發(fā)布訂閱模式)及“管道和過濾器”本身也是常用的架構風格。這三者是架構組件之間數據通訊的方式。從架構風格的組件耦合程度看，RPC 耦合度最高，管道模式次之，發(fā)布訂閱耦合度最低。但在具體實現上，這三者之間很大程度上可以互為實現。

基于RPC 實現發(fā)布/訂閱

如果我們實現了“客戶-服務器”之間的RPC 機制，我們可以利用它來構建發(fā)布訂閱系統(tǒng)。ZeroC ICE 支持的發(fā)布訂閱服務IceStorm就是這么實現的。但是這個發(fā)布訂閱是通過中心節(jié)點進行中轉的。



圖3. 14基于RPC 實現發(fā)布/訂閱

如圖3. 14所示，“接口A”定義了一個 RPC 接口，在普通的基于RPC的“客戶-服務器”系統(tǒng)中，客戶端直接調用接口A，服務器獲取數據進行處理。當轉換成“發(fā)布/訂閱”模式時，引入中轉服務：

1、中轉服務提供基于主題(Topic,可以是一個字符串名稱)的Publish和 Subscribe 接口。中轉服務對每一個主題維護訂閱者列表。

2、訂閱者通過調用中轉服務的Subscribe接口將自己注冊到中轉服務中，以訂閱特定主題。實質上就是告訴中轉服務自己對哪個主題感興趣，告訴它回調自己的訪問點(IP，端口等)。

3、發(fā)布者按主題發(fā)布數據，實際是對接口A的一次RPC調用，但是帶上了主題名稱，方便中轉服務識別。

4、中轉服務并不識別并執(zhí)行發(fā)布者的請求，只是根據主題名稱將請求轉發(fā)給訂閱者。接口的適配（參數定義，版本匹配）由發(fā)布者和訂閱者自己保證。

以上實現“發(fā)布/定義”方式的缺點是有中轉服務，一方面存在單點失敗的可能，一方面兩次數據傳輸有額外的網絡性能開銷。另外只適合沒有返回值的RPC調用。優(yōu)點也很明顯，可以方便的把 RPC 服務轉換成“發(fā)布/訂閱”模式，能夠方便的達到解耦和發(fā)布者和訂閱者的目的。中轉服務是與特定接口無關的，也就是說任何RPC接口都可以這么轉換。因為中轉服務不需要識別接口內容，只是單純的做數據報文的轉發(fā)，不做序列化和反序列化動作，所以可以適用于任何單向RPC接口。

基于發(fā)布訂閱實現RPC

反過來，我們也可以基于“發(fā)布/訂閱”的消息通訊實現 RPC機制。“發(fā)布/訂閱”邏輯上是實現一個“多播”機制。多個軟件組件可以訂閱某一個主題的消息，不關心誰發(fā)送；多個組件也可以發(fā)出某個主題的消息而不關心誰會接收。既然可以“多播”，當然也可以“單播”，我們完全可以給用戶層一個RPC的API，而在實現的時候把RPC調用轉化成單播的消息通訊，比如利用DDS來實現。

基于“發(fā)布/訂閱”來實現管道

在管道和過濾器風格中，每個組件（過濾器）從其輸入端讀取數據流，對數據進行處理后在其輸出端產生數據流。每個過濾器必須完全獨立于其它的過濾器（零耦合），它不能與其它過濾器在其上行和下行數據流接口分享狀態(tài)、控制線程或其它資源?！肮艿篮瓦^濾器”有非常好的可配置性，可擴展性。

如果我們把管道中每一個過濾器的輸入和輸出數據流定義成“發(fā)布/訂閱”的消息，那么也可以實現管道和過濾器的風格形式。實際很多基于ROS/ROS2 實現的系統(tǒng)就是這么用的。

---- 以上幾個是架構風格在實現層面是交叉支持的具體形式，其實還可以有更多。如前文所述，架構風格定義的是軟件組件之間結構關系的約束形式。每一個架構風格當然有其最優(yōu)的原生實現形式，但是也不排除在具體實現技術上基于其它風格實現。

3.5.3車載以太網助力 SOA架構

SOA 在分布式系統(tǒng)中實際上已經被應用很多。不過在以太網用于汽車之前，車載軟件其實是不怎么提 SOA的。SOA的相關設計約束并不是說一定要基于以太網，只是在車載軟件上，以太網能讓SOA 更好的實現并發(fā)揮作用。對此我們做一些說明。

先明確討論中“以太網”的概念。當我們談及“以太網”的時候，根據上下文其實往往有“狹義”和“廣義”兩種含義。

狹義的以太網重點關注的是以太網的物理層和鏈路層。這時候我們指的以太網是符合 100BASE-T、1000BASE-T等標準的有線網絡，采用總線型拓撲，或者基于交換機實現星型拓撲。使用CSMA/CD（Carrier Sense Multiple Access/Collision Detection，即載波多重訪問/碰撞偵測）的總線技術來解決通訊沖突。在這個語義下，WiFi 不是以太網，它是無線通訊技術，有另一套標準(IEEE 802.11)。

廣義的“以太網”包含了常用的通訊協(xié)議，最核心的是對IP 層協(xié)議的支持。ISO/OSI 定義的七層網絡模型中，物理層和鏈路層之上是 IP 層（網絡層）。傳輸層協(xié)議(TCP,UDP)也都是基于 IP 層。IP成定義了數據報文進行地址和傳輸的協(xié)議，無論下面兩層如何實現，只要有IP層的支持，不同網絡就是互通的。在這個語義下，WiFi 也是以太網，因為它也支持 IP 協(xié)議。我們還可以實現 IP over USB, 那就是基于 USB 的以太網。

下面討論中的“以太網”指的是廣義的以太網，即具有IP協(xié)議支持的網絡。

Can 總線在汽車中的到廣泛的運用，Can總線只有物理層和數據鏈路層（[27]3.3）。使用 Can 總線的應用需要在這個基礎的數據鏈路層協(xié)議上去定義自己的數據格式，一般以一個DBC 格式文件描述。Lin總線成本更低， FlexRay 總線提供了比 Can 高得多的數據傳輸帶寬，但是他們也跟 Can 總線一樣，只有物理層和數據鏈路層，應用層協(xié)議各自為政。

這意味著這幾個網絡是無法互通的。汽車電子電器架構設計的時候，解決互通問題的辦法就是兩個網絡中間加網關。網關同時支持兩個以上網絡并來回搬運數據。即使是兩條Can 總線想要互通也需要加網關，而且網關的數據搬運代碼都需要單獨定制，因為每條Can的應用層協(xié)議都不一樣。

設想一下，在這種網絡環(huán)境下做SOA服務是什么效果。假如我們基于 Can 協(xié)議實現了一個 SOA 服務，我們沒法進行RPC請求，因為 Can 協(xié)議沒有尋址的概念，請求不知道發(fā)給誰。不過好消息是Can 本質上也是發(fā)布訂閱的機制，我們可以放棄單播通訊，只做事件廣播。但 Can 一個消息只有8個字節(jié)，沒有地方放更多的頭信息，我們在設計服務發(fā)現機制的時候會遇到巨大挑戰(zhàn)。

就算我們設計出了服務發(fā)現，對不起，這個服務在別的網段中不會被發(fā)現，因為各個網段的服務是不能互通的。我們就需要開發(fā)網關程序跨網段搬運數據。但是每增加一個服務，或者對服務的數據格式做些修改，網關程序都要重新修改適配。

就算這些都完成了，我們想讓一個開發(fā)好的服務在另一個項目中復用幾乎不可能，因為對應的Can 協(xié)議，網關程序全部都要重新適配。

引入以太網技術帶來的 IP 層是解決這些問題的關鍵。不管各段網絡的物理層和鏈路層是什么樣的，只要支持 IP層協(xié)議，IP報文就可以在不同網段之間傳輸。IP 協(xié)議是可以支持廣播和多播（一次數據發(fā)送，多個目標接收）的。而且廣播和多播是可以跨網段的，有成熟的協(xié)議支持。廣播和多播可被用于SOA 的“服務發(fā)現”和服務之間的數據發(fā)布訂閱。

以太網比大多數其它車載網絡提供了更高的帶寬，目前常用的車載以太網系統(tǒng)基本都可以達到1000Mbps。將來升級到萬兆甚至更高的光纖以太網也是指日可待。而這種升級在軟件架構上幾乎不需要做太多變化就可以利用網速提高帶來的好處。這樣在數據報文設計上就不用像設計Can報文一樣精打細算的利用好每一個 bit。必要的情況下可以增加更多的頭信息支持更多的功能。也可以用來傳輸圖像等多媒體數據。擴大了SOA的服務能力范圍。

TCP/IP 協(xié)議發(fā)展了很多年，是互聯(lián)網的技術基礎。衍生出了無數成熟的網絡技術，這些都可以適當調整后運用到車載軟件。比如基于發(fā)布訂閱的DDS技術，提供了豐富的 QoS能力，可以用于支持服務組件之間的通訊；與外部系統(tǒng)集成可以使用基于HTTP相關的技術。這些技術的有效利用可以很快的提供更多豐富的功能。

引入以太網也有一些其它問題需要解決。以太網的工作模式就是多個聯(lián)網節(jié)點上的多個應用爭搶網絡帶寬。某個應用的高帶寬占用可能會導致另一個應用的緊急數據不能及時傳輸，影響車內服務之間通訊的實時性。TSN (時間敏感網絡)相關協(xié)議的就是用來解決這些問題。

總而言之，在車載軟件中，以太網技術是支持車載SOA架構風格的關鍵技術基礎。

3.5.4 SOA 與 微服務

在汽車軟件開始向 SOA 架構轉型時，大型互聯(lián)網服務基本上都已經轉向了微服務架構風格。那么，SOA與微服務的異同點是什么？汽車軟件也會走向微服務架構嗎？

規(guī)模引起的量變到質變

首先SOA與微服務在架構風格的邏輯上是一脈相承的，前文對SOA的論述對微服務同樣有效。但是微服務在架構風格上更進一步，可以理解為至少增加了以下幾個約束：

1、服務粒度盡可能小

2、服務之間的依賴性更小

3、更徹底的去中心化

服務粒度盡可能小可以理解為比SOA更小的服務拆分，強調的重點是業(yè)務系統(tǒng)徹底的組件化和服務化，原有的單個業(yè)務系統(tǒng)會拆分為多個可以獨立開發(fā)，設計，運行和運維的小應用，這些小應用之間通過服務完成交互和集成。每個服務完全不依賴中心化的資源，比如不依賴中心化的數據庫，每個服務有自己的數據存儲機制。粒度越小、相互之間依賴越小，無中心化，讓開發(fā)、測試、部署的獨立性越強，越容易使用負載均衡技術支持高度的并發(fā)訪問。

相對于SOA ，微服務是一個量變引起質變的過程。目的是為了支持更大型的互聯(lián)網服務體系，應對高并發(fā)、高可用要求、高業(yè)務復雜性的挑戰(zhàn)，同時要求開發(fā)迭代更為敏捷迅速，部署簡單并高度自動化。像電商的秒殺系統(tǒng)，12306 購票系統(tǒng)，都是極限并發(fā)的典型案例，微服務架構在應對這些場景的時候有很好的表現。

微服務可以認為是SOA架構向更深度的發(fā)展進化。但是互聯(lián)網的微服務架構和車載的SOA架構，應用場景有很大的差別。雖然汽車軟件也是分布式架構，而且車載以太網技術得到應用后，很多車載分布式技術與互聯(lián)網的分布式技術有非常多的共通之處。但是車載軟件的分布式規(guī)模與互聯(lián)網服務完全不在一個量級。

“分布”與“集中”

大型互聯(lián)網服務部署規(guī)模可能涉及上百臺服務器，每秒百萬級的并發(fā)。車載的分布式服務只在一臺車的局部系統(tǒng)中，并發(fā)要求低但實時性要求高。與互聯(lián)網的極度分布式趨勢不同，車載系統(tǒng)是反過來，目前是向集中式發(fā)展。原來電子電氣架構中大量小控制器實現的功能，逐步向幾個主要的高性能域控制器集中。

車載SOA架構在功能劃分上盡量切分成多個服務，但是部署的時候實際是集中化的，同時通過一系列技術手段優(yōu)化通訊延遲。有意思的是，這個“集中”其實是與“分布式”并存的。



圖3. 15物理的集中與邏輯的分布

圖3. 15是一個理想的域控制器內的服務部署。高性能的多核心SoC被虛擬化成了多個虛擬機，VM1和VM2分別是Linux和QNX系統(tǒng)，而且都支持容器化(Docker Enable)。每個虛擬機內又有多個容器(Docker Container,不是前文服務裝配中的服務容器 )。每個容器是一個獨立的 OS系統(tǒng)，里面再部署SOA服務進程，進程內有多個SOA服務。不同虛擬機內、不同容器內的服務通過網絡進行通訊。

我們可以看到，整體的域控制器中的軟件在物理上是“集中”部署到了同一個域控制器主機，但是邏輯上又“分布”到了不同的操作系統(tǒng)實例。這樣的好處是可以使用虛擬機或Docker容器作為供應商的邊界。一個供應商提供一個虛擬機或容器內的全部服務，與其它供應商互不影響，責任邊界也容易確定。為了優(yōu)化通訊我們可以在虛擬化這一層提供PCIe總線的虛擬化來支持跨虛擬機的共享內存通訊。

虛擬化技術和容器技術在云端計算中心已經被大規(guī)模使用，車載系統(tǒng)只是在復刻這個過程。差別仍然在于規(guī)模，現實應用中微服務架構基于的虛擬機和容器數量比車載系統(tǒng)至少高出兩個數量級。而且虛擬化對微服務架構是完全透明的，微服務架構中的服務認為自己運行在獨立的OS中，在微服務架構中，只有極度的“分布式”，沒有“集中”部署的含義。

技術實現上的側重點不同

兩者的應用場景不同決定了分布式規(guī)模不同，導致在具體的設計和實現上的側重點也有很大差別。

車載SOA首要解決的是服務能夠被拆分，拆分之后能夠通訊，然后解決如何優(yōu)化通訊的效率，尤其是一定的實時性保證。 微服務架構因為徹底的分布式帶來的大量微服務組件，需要在更大的規(guī)模上去解決“負載均衡、服務發(fā)現、認證授權、監(jiān)控追蹤、流量控制、服務部署、分布式事務、分布式存儲”等等問題。

以目前最先進的微服務架構Service Mesh來說，2017 年1月發(fā)布的Service Mesh產品Linkerd，所有的請求都通過 Service Mesh 轉發(fā)，不提供直連方式，它掌控所有的流量。2017 年 5 月, Google、IBM、Lyft 聯(lián)手發(fā)布了 Istio，它與第一代 Service Mesh 相比，增加了控制平面，它具備遠超第一代的控制能力。

通過集中式控制面板，加上所有流量均會通過 Service Mesh 轉發(fā)，通過 Service Mesh 的控制面板，就可以控制所有整個系統(tǒng)。Service Mesh管控的內容出來服務注冊和服務發(fā)現外，還包括負載均衡機制，彈性的流量控制能力(熔斷、限流、降級、超時、重試等)。而轉發(fā)引起的消息延遲在互聯(lián)網業(yè)務中并不是最重要的關注點。

車載軟件架構會走向“微服務”嗎

車載SOA架構是實際上跟互聯(lián)網技術上的SOA架構也是有很大差別的，加入了很多為車載場景定制的協(xié)議和優(yōu)化機制。微服務架構作為SOA的進一步演進，已經在互聯(lián)網領域體現了其價值所在。車載的SOA架構也不會一成不變，也會進一步的演化，很自然的也會從微服務架構中吸取優(yōu)秀思想。但不會是直接使用互聯(lián)網微服務的產品。

目前來說車載軟件的當務之急還是先實現在業(yè)務功能層面SOA化，然后在服務部署上應用虛擬化和容器化，以支持不同粒度上的服務部署，并建立供應商的責任邊界。進一步的改進可以根據現實問題來做響應。有一個現成微服務架構作為參照，也為后續(xù)架構改進的思路提供了技術儲備。

審核編輯：劉清