3.3.5 服務(wù)代理

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



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

服務(wù)代理還帶來另一個好處。被代理的軟件模塊被隱藏在代理服務(wù)后面，可以單獨(dú)進(jìn)化。比如采用不同的技術(shù)路線網(wǎng)絡(luò)總線重新實現(xiàn)。

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

3.3.6 服務(wù)裝配

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

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

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

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

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



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

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

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

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

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

3.3.7 服務(wù)監(jiān)督

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

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

?

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

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

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

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

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

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

3.3.8 RESTful API

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

更為重要的是，各種異構(gòu)系統(tǒng)，如果能夠?qū)ν馓峁┗?HTTP 實現(xiàn)的RESTful API，就可以在更大范圍內(nèi)做應(yīng)用系統(tǒng)的集成。比如各大云服務(wù)提供商(AWS,阿里,百度等)，都為它們的各種云基礎(chǔ)設(shè)施提供了 RESTful API接口，我們就可以很方便的使用程序去管理我們的云端資源（如創(chuàng)建一臺云主機(jī)，讀取或更新數(shù)據(jù)庫）。



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

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

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

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

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

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

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

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

3.3.8 可選的其它風(fēng)格

“虛擬機(jī)/解釋器”風(fēng)格

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

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

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

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

“遠(yuǎn)程求值”風(fēng)格

“遠(yuǎn)程求值”風(fēng)格跟“虛擬機(jī)/解釋器”風(fēng)格正好相反，是客戶端把代碼送到服務(wù)端執(zhí)行。同樣，這種方式的需求也出現(xiàn)在與云端有交互的場景。之所以把代碼送到服務(wù)端執(zhí)行，是因為執(zhí)行所需要的數(shù)據(jù)在服務(wù)端。這些數(shù)據(jù)或者是因為數(shù)據(jù)量大不便傳輸，或者是因為數(shù)據(jù)安全或數(shù)據(jù)隱私的原因，不能被下發(fā)給客戶端。客戶端可以將代碼發(fā)送到服務(wù)端執(zhí)行，利用數(shù)據(jù)，取回結(jié)果。

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

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

3.3.9 小結(jié)

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

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

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

3.4 SOA 的架構(gòu)元素

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

SOA 的“數(shù)據(jù)元素”比較容易識別，無論是RPC調(diào)用還是消息的發(fā)布訂閱，都是數(shù)據(jù)在不同服務(wù)之間傳遞。深入理解這一點(diǎn)最好的方式是與面向?qū)ο蟮姆植际较到y(tǒng)做對比。面向?qū)ο蟮暮诵母拍钪皇恰胺庋b”，其關(guān)鍵含義在于將數(shù)據(jù)以及操作數(shù)據(jù)的方法封裝在對象實例中，對象私有數(shù)據(jù)對外不可見。這可以理解為將“數(shù)據(jù)元素”與“處理元素”封裝在了一起。面向?qū)ο蟮能浖O(shè)計就更關(guān)注如何將領(lǐng)域概念轉(zhuǎn)換成合適的對象模型，定義對象的行為和操作，以及對象之間的組成結(jié)構(gòu)。

與面向?qū)ο蟮姆椒▽Ρ?，SOA 架構(gòu)中“數(shù)據(jù)元素”和“處理元素”的耦合度就低很多?；谙⒌陌l(fā)布訂閱完全是從數(shù)據(jù)的視角看世界，基本不關(guān)心數(shù)據(jù)如何被處理，只關(guān)注數(shù)據(jù)之間的供需關(guān)系。RPC請求可以被理解為“一對一”的數(shù)據(jù)供給與需求關(guān)系。

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

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

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

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

也就是說數(shù)據(jù)的處理不應(yīng)該依賴于特定的連接方式。架構(gòu)師甚至希望只需要提供給開發(fā)團(tuán)隊模擬的連接方式并回放預(yù)先錄制的數(shù)據(jù)，開發(fā)團(tuán)隊基于這些來實現(xiàn)其數(shù)據(jù)“處理元素”。“處理元素”的完成品可以被架構(gòu)師集成到真實的應(yīng)用環(huán)境中，那時使用的可能是不同的連接元素。

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

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

3.5 SOA相關(guān)其它問題討論

3.5.1 SOA vs 分布式對象

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

SOA 和分布式對象都是分布式網(wǎng)絡(luò)架構(gòu)的實現(xiàn)形式。只不過一個是 Service Oriented ，一個是 Object-Oriented。我們來看看他們有什么異同，為什么車載軟件選擇 Service-Oriented 而不是Object-Oriented。

面向?qū)ο螅∣bject-Oriented）是非常重要的軟件設(shè)計思想。當(dāng)軟件規(guī)模進(jìn)一步復(fù)雜后，“結(jié)構(gòu)化編程”方法也體現(xiàn)出一定的不足。面向?qū)ο蟮脑O(shè)計思想是解決這些問題的方法論之一。

從C++開始，大多數(shù)程序設(shè)計語言都支持面向?qū)ο蟮姆椒ㄕ?。它把?shù)據(jù)和處理數(shù)據(jù)的方法封裝在一個對象中，可以用來與具體的現(xiàn)實事物或抽象的語義概念進(jìn)行對應(yīng)。提供了對現(xiàn)實問題或語義概念進(jìn)行建模的可能，用來描述復(fù)雜的軟件語義。

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

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

強(qiáng)“狀態(tài)相關(guān)”的服務(wù)不利于可擴(kuò)展性

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

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

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

對于車載軟件來說，雖然整體系統(tǒng)很復(fù)雜，但是到單個具體的服務(wù)點(diǎn)，其功能往往是很單一的，處理邏輯的復(fù)雜度遠(yuǎn)遠(yuǎn)小于電子商務(wù)等系統(tǒng)。很多時候就是接收數(shù)據(jù)，做簡單處理，然后發(fā)送數(shù)據(jù)。面向?qū)ο蟮慕@些簡單功能來說帶來了不必要的復(fù)雜度。無狀態(tài)的服務(wù)設(shè)計方式能讓系統(tǒng)大大簡化。

不同對象的接口差異大

面向?qū)ο蟮脑O(shè)計方法很重要一點(diǎn)是對行業(yè)領(lǐng)域進(jìn)行建模，分析出各種對象類型以及它們之間的關(guān)系。不同類型的對象就包含不同的狀態(tài)數(shù)據(jù)以及不同的操作接口。

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

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

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

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

對象生命周期管理復(fù)雜

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

3.5.3車載以太網(wǎng)助力 SOA架構(gòu)

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

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

狹義的以太網(wǎng)重點(diǎn)關(guān)注的是以太網(wǎng)的物理層和鏈路層。這時候我們指的以太網(wǎng)是符合 100BASE-T、1000BASE-T等標(biāo)準(zhǔn)的有線網(wǎng)絡(luò)，采用總線型拓?fù)?，或者基?a href="http://m.sdkjxy.cn/v/tag/1392/" target="_blank">交換機(jī)實現(xiàn)星型拓?fù)洹Ｊ褂肅SMA/CD（Carrier Sense Multiple Access/Collision Detection，即載波多重訪問/碰撞偵測）的總線技術(shù)來解決通訊沖突。在這個語義下，WiFi 不是以太網(wǎng)，它是無線通訊技術(shù)，有另一套標(biāo)準(zhǔn)(IEEE 802.11)。

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

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

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

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

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

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

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

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

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

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

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

總而言之，在車載軟件中，以太網(wǎng)技術(shù)是支持車載SOA架構(gòu)風(fēng)格的關(guān)鍵技術(shù)基礎(chǔ)。

3.5.4 SOA 與 微服務(wù)

在汽車軟件開始向 SOA 架構(gòu)轉(zhuǎn)型時，大型互聯(lián)網(wǎng)服務(wù)基本上都已經(jīng)轉(zhuǎn)向了微服務(wù)架構(gòu)風(fēng)格。那么，SOA與微服務(wù)的異同點(diǎn)是什么？汽車軟件也會走向微服務(wù)架構(gòu)嗎？

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

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

1、服務(wù)粒度盡可能小

2、服務(wù)之間的依賴性更小

3、更徹底的去中心化

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

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

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

“分布”與“集中”

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

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



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

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

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

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

技術(shù)實現(xiàn)上的側(cè)重點(diǎn)不同

兩者的應(yīng)用場景不同決定了分布式規(guī)模不同，導(dǎo)致在具體的設(shè)計和實現(xiàn)上的側(cè)重點(diǎn)也有很大差別。

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

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

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

車載軟件架構(gòu)會走向“微服務(wù)”嗎

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

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

審核編輯：劉清