軟件架構(gòu)方法論及

SOA推導(dǎo)

前面講了很多中間件產(chǎn)品中常用的關(guān)鍵技術(shù)。相對(duì)更大層面的軟件架構(gòu)來(lái)說(shuō)，這些只是局部的技術(shù)點(diǎn)。用于某個(gè)行業(yè)領(lǐng)域的中間件產(chǎn)品往往會(huì)非常深度地決定這個(gè)行業(yè)領(lǐng)域應(yīng)用軟件所采用的軟件架構(gòu)。

軟件系統(tǒng)規(guī)模比較小的時(shí)候，我們很少用架構(gòu)這個(gè)詞。所以早期有種說(shuō)法：

算法+數(shù)據(jù)結(jié)構(gòu)=程序

這里的程序指的是解決特定的具體問(wèn)題，一般不涉及大范圍網(wǎng)絡(luò)數(shù)據(jù)交換的獨(dú)立軟件?；ヂ?lián)網(wǎng)讓軟件應(yīng)用從小范圍專業(yè)領(lǐng)域變成覆蓋全球的信息系統(tǒng)，軟件系統(tǒng)也從簡(jiǎn)單的程序演變出很多復(fù)雜的架構(gòu)。

目前在汽車軟件領(lǐng)域也正經(jīng)歷著類似的變化，由于智能網(wǎng)聯(lián)與自動(dòng)駕駛的需求，汽車軟件的復(fù)雜度也以指數(shù)形式上升，同時(shí)由于以太網(wǎng)的引入，很多之前在互聯(lián)網(wǎng)上可以使用的軟件架構(gòu)經(jīng)過(guò)一些變換后也可以用到汽車軟件上。典型的就是現(xiàn)在大家常說(shuō)的SOA。

SOA是什么？更專業(yè)的說(shuō)法，SOA是一種軟件架構(gòu)風(fēng)格。車載中間件產(chǎn)品也會(huì)有其軟件架構(gòu)及架構(gòu)風(fēng)格，SOA 目前看來(lái)會(huì)是一個(gè)主流的趨勢(shì)。

什么是軟件架構(gòu)，什么是架構(gòu)風(fēng)格，需要一個(gè)清晰的定義，這一章先從這里開(kāi)始。

3.1 軟件架構(gòu)組成與架構(gòu)風(fēng)格

在這里，我先引用兩篇論文，

1、軟件架構(gòu)研究基礎(chǔ)(Foundations for the Study of Software Architecture [24])

2、架構(gòu)風(fēng)格與基于網(wǎng)絡(luò)的軟件架構(gòu)設(shè)計(jì)Architectural Styles and the Design of Network-based SoftwareArchitectures [23]

第一篇是1992年的論文，提出了軟件架構(gòu)的基礎(chǔ)模型和架構(gòu)風(fēng)格的概念。第二篇的作者Roy Thomas Fielding 是 HTTP1.0/1.1 規(guī)范的主要制定者，這篇文章是他2000年的博士論文，在Web發(fā)展史上，這是一篇極其重要的經(jīng)典文獻(xiàn)，奠定了現(xiàn)代 Web 架構(gòu)的基礎(chǔ)。這都是20-30年前的文章，但是其對(duì)軟件架構(gòu)的闡述絲毫沒(méi)有過(guò)時(shí)，一樣在理論上指導(dǎo)著軟件架構(gòu)的設(shè)計(jì)。

很多汽車相關(guān)企業(yè)都在推進(jìn)SOA化，但其架構(gòu)風(fēng)格背后的推理邏輯其實(shí)并不是顯而易見(jiàn)的。只看到具體的技術(shù)點(diǎn)，而不知其由來(lái)，就很難準(zhǔn)確理解并使用它。尤其是現(xiàn)代的汽車電子電器架構(gòu)就是基于多種車載網(wǎng)絡(luò)體系來(lái)構(gòu)建，汽車軟件已經(jīng)成了典型的基于網(wǎng)絡(luò)的分布式軟件系統(tǒng)。原來(lái)基于網(wǎng)絡(luò)的軟件架構(gòu)設(shè)計(jì)原理對(duì)汽車軟件一樣有非常重要的參考作用。

這一節(jié)盡量以易于理解的方式，用較短的篇幅將這兩篇文章中關(guān)于軟件架構(gòu)和架構(gòu)風(fēng)格的闡述做一個(gè)綜述。為后續(xù)的討論做一個(gè)理論基礎(chǔ)。

3.1.1 軟件架構(gòu)研究方法論

圖3. 1以 UML 類圖的表示了組成軟件架構(gòu)的基本概念。 注: 簡(jiǎn)單的 UML 符號(hào)語(yǔ)意。

表示“泛化(抽象)”概念，也就是邏輯上一般化與具體的關(guān)系，程序語(yǔ)言的繼承。箭頭所指父類，即比較“抽象”的概念，另一端是該概念的具體化呈現(xiàn)。

表示“組成”關(guān)系，也就是整體與部分的關(guān)系。箭頭所指為整體，另一端為組成整體的各個(gè)部分。

表示遵循某個(gè)“規(guī)約”，程序語(yǔ)言中代表接口實(shí)現(xiàn)。箭頭所指為具體的規(guī)約規(guī)則。

圖3. 1軟件架構(gòu)組成 軟件架構(gòu)由三個(gè)方面組成，架構(gòu)元素，架構(gòu)的組成形式，和一些形成架構(gòu)的基本原則。

架構(gòu)元素有三種:

處理元素：執(zhí)行實(shí)際的功能性運(yùn)算與數(shù)據(jù)轉(zhuǎn)換；是“計(jì)算和狀態(tài)的所在地”；是在運(yùn)行時(shí)執(zhí)行某種功能的軟件單元。

數(shù)據(jù)元素：承載著被使用和轉(zhuǎn)換的信息。

連接元素：將架構(gòu)的不同部分結(jié)合在一起的粘合劑。 我們用四個(gè)不同的領(lǐng)域概念類比來(lái)理解這些架構(gòu)元素的含義。

架構(gòu)的組成形式中包括“配置關(guān)系”與“約束屬性”?！芭渲藐P(guān)系”是在系統(tǒng)的運(yùn)行期間處理元素、連接元素和數(shù)據(jù)元素之間的關(guān)系結(jié)構(gòu)?！凹s束屬性”用于約束架構(gòu)元素的選擇。它于將架構(gòu)元素約束到系統(tǒng)需求所需的程度。對(duì)應(yīng)的實(shí)例如下表。

架構(gòu)的一個(gè)潛在但不可或缺的部分是在定義架構(gòu)時(shí)做出的各種選擇的一些基本原則。在軟件架構(gòu)中，基本原則解釋了如何滿足系統(tǒng)約束。這些約束是由從基本功能方面到各種非功能方面的考慮因素決定的，例如經(jīng)濟(jì)性、性能、和可靠性等。

結(jié)合上面所述，我們可以把設(shè)計(jì)一個(gè)軟件架構(gòu)描述為：

根據(jù)我們需要構(gòu)建的軟件系統(tǒng)的約束需求，我們選擇一組基本的原則，在這組原則的指導(dǎo)下，選擇合適(約束符合)的架構(gòu)元素（處理元素、數(shù)據(jù)元素連接元素）組成一個(gè)集合，并設(shè)計(jì)各種架構(gòu)元素的關(guān)系結(jié)構(gòu)。

不同的基本原則選擇方式，會(huì)讓軟件架構(gòu)呈現(xiàn)出不同的風(fēng)格(Style)，我們稱之為架構(gòu)風(fēng)格。一種架構(gòu)風(fēng)格是一組協(xié)作的架構(gòu)約束，這些約束限制了架構(gòu)元素的角色和功能，以及架構(gòu)元素之間的關(guān)系。

當(dāng)我們談及某種形式的軟件架構(gòu)時(shí)，實(shí)際上往往討論的是架構(gòu)風(fēng)格，比如說(shuō) SOA。

每個(gè)架構(gòu)設(shè)計(jì)決策可以被看作是對(duì)一種風(fēng)格的應(yīng)用，而一個(gè)軟件架構(gòu)往往會(huì)混用多種風(fēng)格。

3.1.2 軟件架構(gòu)的評(píng)估方法

一種架構(gòu)風(fēng)格是一組協(xié)作的架構(gòu)約束，但是經(jīng)常會(huì)出現(xiàn)一種情況，一種約束的效果可能會(huì)抵消一些其它的約束所帶來(lái)的好處。沒(méi)有完美的設(shè)計(jì)，獲得某種優(yōu)勢(shì)的同時(shí)，可能需要在另一方面付出代價(jià)。所以我們需要一種評(píng)估機(jī)制去從多個(gè)方面去評(píng)估一個(gè)軟件架構(gòu)的特性，以便我們?cè)诓煌目赡苄灾g進(jìn)行權(quán)衡。

性能

性能往往是軟件架構(gòu)首先要考慮的方面，軟件架構(gòu)需要滿足應(yīng)用的性能需求。

對(duì)于 I/O 性能，我們關(guān)注的一般是總吞吐量和平均的傳輸延遲。對(duì)于計(jì)算性能我們關(guān)注的是計(jì)算單元的總利用率以及計(jì)算任務(wù)的響應(yīng)延遲。一個(gè)是衡量系統(tǒng)的總效率，一個(gè)是衡量系統(tǒng)的單次響應(yīng)能力，這個(gè)會(huì)影響到用戶可察覺(jué)的性能。

這兩者有時(shí)是有沖突的。好的架構(gòu)風(fēng)格要能在滿足響應(yīng)性要求的情況下，盡可能支持系統(tǒng)能夠達(dá)到的較高的總效率。

性能也受成本的約束，在移動(dòng)平臺(tái)或車載平臺(tái)，性能還受功耗的約束。

可伸縮性

可伸縮性要求架構(gòu)能支持從小規(guī)模到大規(guī)模的平滑擴(kuò)展。架構(gòu)需要能夠支持大量的組件以及這些組件之間交互的能力?？缮炜s性能夠通過(guò)以下方法來(lái)改善：

簡(jiǎn)化組件

將服務(wù)分布到很多組件（分散交互）

根據(jù)監(jiān)視的結(jié)果對(duì)組件之間的交互進(jìn)行動(dòng)態(tài)控制

風(fēng)格可以通過(guò)確定應(yīng)用狀態(tài)的位置、分布的范圍以及組件之間的耦合度，來(lái)影響這些因素。

簡(jiǎn)單性

如果分配給單獨(dú)組件的功能足夠簡(jiǎn)單，那么它們就更容易被理解和實(shí)現(xiàn)，也方便進(jìn)行測(cè)試。越簡(jiǎn)單的組件也越能夠被重復(fù)使用。架構(gòu)要能夠支持將復(fù)雜的功能分解為很多簡(jiǎn)單的組件，同時(shí)還要能夠交互協(xié)同以完成預(yù)期的功能。就是要拆得開(kāi)，還能合得起來(lái)。

可修改性

需求也會(huì)隨時(shí)間發(fā)生變化，可修改性是對(duì)于應(yīng)用的架構(gòu)所作的修改的容易程度?？尚薷男阅軌虮贿M(jìn)一步分解為在下面所描述的可進(jìn)化性、可擴(kuò)展性、可定制性、可配置性和可重用性。

可進(jìn)化性：

一個(gè)組件實(shí)現(xiàn)能夠被改變而不會(huì)對(duì)其它組件產(chǎn)生負(fù)面影響的程度。

可擴(kuò)展性：

將功能添加到一個(gè)系統(tǒng)中的能力。動(dòng)態(tài)可擴(kuò)展性意味著功能能夠被添加到一個(gè)已部署的系統(tǒng)中，而不會(huì)影響到系統(tǒng)的其它部分。提高可擴(kuò)展性的方法是在一個(gè)架構(gòu)中減少組件之間的耦合，比如基于事件或消息進(jìn)行交互。

可定制性：

指組件可以為一個(gè)客戶進(jìn)行定制化擴(kuò)展，而不會(huì)對(duì)該組件的其它客戶產(chǎn)生影響。支持可定制性的風(fēng)格也可能會(huì)提高簡(jiǎn)單性和可擴(kuò)展性，這是因?yàn)橥ㄟ^(guò)僅僅直接實(shí)現(xiàn)最常用的服務(wù)，允許客戶端來(lái)定義不常用的服務(wù)，服務(wù)組件的尺寸和復(fù)雜性將會(huì)降低。

可配置性

指在部署后對(duì)于組件，或者對(duì)于組件配置的修改，這樣組件能夠使用新的服務(wù)或者新的數(shù)據(jù)元素類型。管道/過(guò)濾器風(fēng)格和按需代碼風(fēng)格就是典型的例子。

可重用性

一個(gè)應(yīng)用的架構(gòu)中的處理元素、連接元素或數(shù)據(jù)元素能夠在不做修改的情況下在其它應(yīng)用中重用。在架構(gòu)風(fēng)格中提高可重用性的主要方法就是是降低組件之間的耦合（對(duì)于其它組件的標(biāo)識(shí)的了解）和強(qiáng)制使用通用的組件接口。

可見(jiàn)性

指對(duì)組件之間的交互進(jìn)行監(jiān)視或仲裁的能力?？梢酝ㄟ^(guò)以下方式提高可見(jiàn)性：交互的共享緩存、通過(guò)分層服務(wù)提供可伸縮性、通過(guò)反射式監(jiān)視（reflective monitoring）提供可靠性、以及通過(guò)允許中間組件（例如，網(wǎng)絡(luò)防火墻）對(duì)交互做檢查提供安全性。風(fēng)格能夠通過(guò)限制必須使用通用性的接口，或者提供訪問(wèn)監(jiān)視功能的方法，來(lái)影響基于網(wǎng)絡(luò)的應(yīng)用中交互的可見(jiàn)性。比如在自動(dòng)駕駛應(yīng)用中，我們強(qiáng)制每個(gè)算法組件報(bào)告它接收數(shù)據(jù)、處理數(shù)據(jù)、發(fā)送數(shù)據(jù)的幀率。

可移植性

如果軟件能夠在不同的環(huán)境下運(yùn)行，軟件就是可移植的。標(biāo)準(zhǔn)的通訊協(xié)議，標(biāo)準(zhǔn)化的API接口都可以提高軟件的可移植性。SOME/IP 協(xié)議只管通訊的數(shù)據(jù)交換格式，可以兼容不同的通訊庫(kù)的實(shí)現(xiàn)。AdaptiveAutoSAR 標(biāo)準(zhǔn)將應(yīng)用程序可以使用的系統(tǒng)調(diào)用限制為 POSIX PSE51 標(biāo)準(zhǔn)(參見(jiàn) 4.3.1.1)，方便移植到不同的 OS(Linux/QNX/VxWorks) ；同時(shí)提供標(biāo)準(zhǔn)的應(yīng)用API接口，支持基于Adaptive AutoSAR的應(yīng)用在不同的 Adaptive AutoSAR實(shí)現(xiàn)之間移植。

可靠性

從應(yīng)用的架構(gòu)角度來(lái)說(shuō)，可靠性可以被看作當(dāng)在處理元素、連接元素或數(shù)據(jù)之中出現(xiàn)部分故障時(shí)，一個(gè)架構(gòu)容易受到系統(tǒng)層面故障影響的程度。架構(gòu)風(fēng)格能夠通過(guò)以下方法提高可靠性：避免單點(diǎn)故障、增加冗余、允許監(jiān)視、以及用可恢復(fù)的動(dòng)作來(lái)縮小故障的范圍。車載應(yīng)用還有更高的功能安全要求。

3.2 常見(jiàn)基于網(wǎng)絡(luò)應(yīng)用的架構(gòu)風(fēng)格

圖3. 2列舉出了大多數(shù)基于網(wǎng)絡(luò)的應(yīng)用架構(gòu)風(fēng)格。有一些與網(wǎng)絡(luò)應(yīng)用相關(guān)性不大的其它架構(gòu)風(fēng)格沒(méi)有放進(jìn)來(lái)。



圖3. 2常見(jiàn)的軟件架構(gòu)風(fēng)格之間的關(guān)系 圖中偏左側(cè)黑色粗框標(biāo)識(shí)的是幾個(gè)基礎(chǔ)風(fēng)格，包括“客戶-服務(wù)器，管道和過(guò)濾器、多副本，分層系統(tǒng)，虛擬機(jī)/解釋器；基于事件的集成”等。其它風(fēng)格是對(duì)這些基礎(chǔ)風(fēng)格的繼承（或稱為擴(kuò)展），有的風(fēng)格是繼承自多個(gè)基礎(chǔ)風(fēng)格。

每個(gè)風(fēng)格上部以淡粉色標(biāo)注的標(biāo)簽表示正面的評(píng)估結(jié)果，如改進(jìn)“網(wǎng)絡(luò)性能、可伸縮性、可靠性等”，下部以淡青色標(biāo)注的標(biāo)簽表示負(fù)面的評(píng)估結(jié)果。這里我們不會(huì)逐一介紹每個(gè)風(fēng)格，而是在下文對(duì)SOA 風(fēng)格的推導(dǎo)中敘述涉及到的風(fēng)格。

3.3 面向服務(wù)(SOA)的架構(gòu)風(fēng)格推導(dǎo)

汽車軟件最近開(kāi)始了向 SOA 轉(zhuǎn)型的趨勢(shì)。從軟件架構(gòu)角度看，SOA是一組軟件架構(gòu)風(fēng)格的統(tǒng)稱。嚴(yán)格來(lái)說(shuō)，SOA并不是一個(gè)單一的軟件架構(gòu)風(fēng)格，而是一系列各具特點(diǎn)的軟件架構(gòu)風(fēng)格的綜合運(yùn)用，其中每一種架構(gòu)風(fēng)格都推崇架構(gòu)元素之間的一種特定的交互類型。

我們從一個(gè)空的架構(gòu)風(fēng)格開(kāi)始，逐步增加新的約束，從而推導(dǎo)出 SOA 的架構(gòu)風(fēng)格，并結(jié)合車載軟件和自動(dòng)駕駛軟件的特點(diǎn)來(lái)做進(jìn)一步的說(shuō)明。



圖3. 3空風(fēng)格

3.3.1 “客戶-服務(wù)器”風(fēng)格

首先我們加入到我們約束集合中的是“客戶-服務(wù)器”風(fēng)格?？蛻?服務(wù)器約束背后的原則是關(guān)注點(diǎn)分離?！瓣P(guān)注點(diǎn)分離”是軟件設(shè)計(jì)思想中的一個(gè)關(guān)鍵概念，幾乎可以用在軟件設(shè)計(jì)從架構(gòu)到具體實(shí)現(xiàn)的各個(gè)方面。這個(gè)概念比較抽象，簡(jiǎn)單理解，可以認(rèn)為“一個(gè)軟件單元(架構(gòu)組件，軟件模塊，接口等)，其關(guān)注的范圍盡可能小，聚焦在某一個(gè)特定的領(lǐng)域范圍(關(guān)注點(diǎn))。”一個(gè)關(guān)注點(diǎn)可以看作是“功能，行為，數(shù)據(jù)”等，很難有一個(gè)通用準(zhǔn)確的概括。不同的關(guān)注點(diǎn)由不同的軟件單元來(lái)處理，軟件的耦合程度就會(huì)降低，會(huì)帶來(lái)架構(gòu)和實(shí)現(xiàn)上的各種便利。

“客戶-服務(wù)器”風(fēng)格首先分離了“功能實(shí)現(xiàn)”與“用戶接口”兩個(gè)關(guān)注點(diǎn)?！肮δ軐?shí)現(xiàn)”一般包括對(duì)數(shù)據(jù)的處理、計(jì)算、存儲(chǔ)，“用戶接口”是用戶提供數(shù)據(jù)和獲取結(jié)果的界面。這兩者的分離可以讓“功能實(shí)現(xiàn)”部分單獨(dú)進(jìn)化，而不影響用戶的使用。在用戶接口不變的情況下，“功能實(shí)現(xiàn)”可以采用更新的算法，更快的存儲(chǔ)，更大的部署規(guī)模，或者移植到不同的技術(shù)平臺(tái)，而這些對(duì)用戶都是透明的。

對(duì)復(fù)雜的軟件系統(tǒng)而言，把整個(gè)系統(tǒng)拆解成多個(gè)服務(wù)器程序，每個(gè)服務(wù)器程序關(guān)注特定的功能。這種拆分本身也是關(guān)注點(diǎn)分離思想的應(yīng)用。

現(xiàn)代車載軟件以及自動(dòng)駕駛系統(tǒng)極為復(fù)雜，需要很多家不同供應(yīng)商開(kāi)發(fā)不同的軟件組件?？蛻?服務(wù)器風(fēng)格以服務(wù)界定功能邊界，不同供應(yīng)商開(kāi)發(fā)按照預(yù)定義的接口實(shí)現(xiàn)特定的服務(wù)，為其它組件提供服務(wù)的同時(shí)也使用其它供應(yīng)商開(kāi)發(fā)的服務(wù)組件，只要接口定義好，多個(gè)不同的供應(yīng)商的軟件組件就可以協(xié)同工作。



圖3. 4 SOA：客戶-服務(wù)器

3.3.2 狀態(tài)分離與局部化

3.3.2.1程序“狀態(tài)”的含義

“狀態(tài)”這個(gè)詞被用在很多地方，其含義往往有很多細(xì)微差別，容易被混淆。這里所謂的狀態(tài)是指“某個(gè)軟件組件內(nèi)部包含的數(shù)據(jù)信息，這個(gè)數(shù)據(jù)信息會(huì)影響外部對(duì)這個(gè)軟件組件發(fā)出請(qǐng)求的響應(yīng)結(jié)果”。

假設(shè)有一個(gè)加法器A，提供了兩個(gè)接口： 1、設(shè)置初始值 2、增加 n 并返回結(jié)果 我們給加法器A設(shè)置初始值0，然后每次加1 ，返回的結(jié)果是不一樣的。

對(duì)另一加法器 B，提供如下接口： 輸入兩個(gè)操作數(shù)，返回其加法結(jié)果 對(duì)加法器B而言，只要每次給出相同的輸入數(shù)據(jù)，返回的結(jié)果是一樣的，不依賴于加法器B的內(nèi)部數(shù)據(jù)。

加法器A內(nèi)部就保存了程序狀態(tài)，假如多個(gè)客戶端并發(fā)進(jìn)行訪問(wèn)，取得的結(jié)果就會(huì)互相干擾。加法器B就是我們常說(shuō)的無(wú)狀態(tài)服務(wù)器，所有狀態(tài)數(shù)據(jù)保存在客戶端的請(qǐng)求中，多個(gè)客戶端并發(fā)調(diào)用互不影響。這樣就允許我們復(fù)制部署多個(gè)加法器B，分擔(dān)承接大量并發(fā)請(qǐng)求。

圖3. 5描述了多種軟件架構(gòu)風(fēng)格在“狀態(tài)分布”和“交互耦合程度”上的分布情況。這里我們先關(guān)注狀態(tài)分布。圖中縱軸的上部表示狀態(tài)偏向在服務(wù)端保存，下端表示狀態(tài)偏向在客戶端保存。



圖3. 5不同架構(gòu)風(fēng)格的狀態(tài)與交互耦合程度的分布

狀態(tài)偏向服務(wù)端的極端案例是“遠(yuǎn)程會(huì)話”風(fēng)格，每個(gè)客戶端在服務(wù)器上啟動(dòng)一個(gè)會(huì)話，然后調(diào)用服務(wù)器的一系列服務(wù)接口，最后退出會(huì)話。應(yīng)用狀態(tài)被完全保存在服務(wù)器上。如:FTP服務(wù),Telnet服務(wù)等。

狀態(tài)偏向客戶端的極端案例是“客戶-無(wú)狀態(tài)-服務(wù)器”風(fēng)格，從客戶端發(fā)到服務(wù)器的每個(gè)請(qǐng)求必須包含用于理解請(qǐng)求所必需的全部信息，不能利用任何保存在服務(wù)器上的上下文(context)，會(huì)話狀態(tài)全部保存在客戶端。

其它設(shè)計(jì)風(fēng)格的“狀態(tài)分布”模式處于兩個(gè)極端中間。加入緩存機(jī)制的設(shè)計(jì)風(fēng)格部分狀態(tài)保存在客戶與服務(wù)器之間的緩存機(jī)制上。分布式對(duì)象為基礎(chǔ)的設(shè)計(jì)風(fēng)格，狀態(tài)主要保存在遠(yuǎn)程對(duì)象中，偏向服務(wù)器?！肮艿篮瓦^(guò)濾器”風(fēng)格和“基于事件集成”風(fēng)格沒(méi)有明顯的客戶和服務(wù)器端，狀態(tài)保存在各自組件中。

3.3.2.2 SOA服務(wù)的狀態(tài)分布選擇

前面說(shuō)的是程序狀態(tài)分布的通用概念。現(xiàn)在回到車載軟件SOA風(fēng)格。我們新增一條約束，“分離強(qiáng)狀態(tài)服務(wù)與無(wú)狀態(tài)服務(wù)，并控制狀態(tài)在局部范圍”。

這個(gè)約束的核心含義有兩點(diǎn)：

1、一個(gè)是無(wú)狀態(tài)服務(wù)與強(qiáng)狀態(tài)服務(wù)要分離在不同的服務(wù)中

2、每一個(gè)服務(wù)要么是無(wú)狀態(tài)，要么是強(qiáng)狀態(tài)，避免中間路線。

無(wú)狀態(tài)服務(wù)會(huì)顯著改善服務(wù)的可見(jiàn)性、可靠性和可伸縮性。改善了可見(jiàn)性是因?yàn)楸O(jiān)視系統(tǒng)僅僅只需要對(duì)單個(gè)請(qǐng)求進(jìn)行分析就能得到其全部特質(zhì)，不需要關(guān)心其它請(qǐng)求。改善了可靠性是因?yàn)樗審木植抗收现谢謴?fù)所需要做的工作減少了。改善了可伸縮性是因?yàn)榉?wù)器不必在多個(gè)請(qǐng)求之間保存狀態(tài)，請(qǐng)求結(jié)束就可以迅速釋放資源。服務(wù)器的實(shí)現(xiàn)得到簡(jiǎn)化，負(fù)載均衡也容易實(shí)現(xiàn)[23]5.1.3。

車載軟件對(duì)于可見(jiàn)性和可靠性的要求是顯而易見(jiàn)的。而對(duì)于可伸縮性的要求不高，因?yàn)檐囕d軟件高并發(fā)的場(chǎng)景并不多。但是只需要關(guān)注單個(gè)請(qǐng)求的實(shí)現(xiàn)，并迅速釋放資源，依然會(huì)讓服務(wù)器的實(shí)現(xiàn)簡(jiǎn)化很多，同時(shí)也會(huì)促進(jìn)可靠性的提高。

對(duì)自動(dòng)駕駛軟件來(lái)說(shuō)，單個(gè)請(qǐng)求的獨(dú)立性，也意味著附著在請(qǐng)求上的功能性和非功能性約束也更為清晰明確。功能性約束體現(xiàn)在請(qǐng)求的參數(shù)和響應(yīng)結(jié)果的數(shù)據(jù)形式上，因?yàn)橐淮畏?wù)只需要一次請(qǐng)求響應(yīng)，約定好請(qǐng)求響應(yīng)的數(shù)據(jù)規(guī)范就能界定服務(wù)的功能邊界。非功能性約束往往體現(xiàn)在響應(yīng)時(shí)間（或幀率），數(shù)據(jù)傳遞的 QoS 要求上，服務(wù)越簡(jiǎn)單，這些非功能性約束也就越容易明確。一方面可見(jiàn)性的提高能對(duì)這些非功能性約束做更好的監(jiān)控，另一方面服務(wù)實(shí)現(xiàn)上滿足這些非功能性約束也會(huì)越容易。比如，對(duì)響應(yīng)時(shí)間的約束滿足體現(xiàn)在任務(wù)調(diào)度機(jī)制上，無(wú)狀態(tài)帶來(lái)的簡(jiǎn)單話意味著實(shí)現(xiàn)良好任務(wù)調(diào)度機(jī)制就容易許多。

雖然無(wú)狀態(tài)帶來(lái)了諸多好處，但是在應(yīng)用中狀態(tài)依然是存在的。某些自動(dòng)駕駛功能其狀態(tài)往往需要用復(fù)雜的“有限狀態(tài)機(jī)(FSM)”來(lái)定義。那如何來(lái)設(shè)計(jì)這些對(duì)狀態(tài)強(qiáng)依賴的服務(wù)。解決的辦法是：

1、在服務(wù)劃分上分離無(wú)狀態(tài)服務(wù)與有狀態(tài)服務(wù)

2、將狀態(tài)限制在服務(wù)的局部范圍，即少量特定的SOA服務(wù)

在服務(wù)劃分上，我們應(yīng)該盡量把能夠進(jìn)行的無(wú)狀態(tài)化處理的服務(wù)識(shí)別出來(lái)，并按照無(wú)狀態(tài)的方式去定義其服務(wù)接口并實(shí)現(xiàn)。而把涉及到復(fù)雜狀態(tài)轉(zhuǎn)換的部分集中在一個(gè)獨(dú)立的服務(wù)中。不同的有狀態(tài)服務(wù)之間，其各自涉及的狀態(tài)范圍應(yīng)該是正交的，即不同服務(wù)的狀態(tài)相互無(wú)關(guān)。各自服務(wù)將狀態(tài)限制在自己服務(wù)本地，甚至還可以對(duì)外呈現(xiàn)出一定的無(wú)狀態(tài)特征。

例如，對(duì)于一個(gè) ACC 應(yīng)用，涉及的服務(wù)可以簡(jiǎn)化的分解為如圖3. 6所示的多個(gè)服務(wù)(只是簡(jiǎn)化表示)。我們可以把ACC狀態(tài)機(jī)集中在一個(gè)ACC 會(huì)話服務(wù)中。它所依賴的其它服務(wù)是無(wú)狀態(tài)的，只是根據(jù)輸入產(chǎn)生對(duì)應(yīng)的輸出。

實(shí)際情況會(huì)更復(fù)雜一些，比如“前視算法服務(wù)”中并不是完全無(wú)狀態(tài)，如果需要做多幀融合或者目標(biāo)跟蹤，其結(jié)果跟多幀的數(shù)據(jù)相關(guān)。這多幀的歷史數(shù)據(jù)就是狀態(tài)。解決的辦法是進(jìn)一步拆解成更小的粒度。目標(biāo)跟蹤算法做成單獨(dú)的服務(wù)，輸入是所有關(guān)聯(lián)幀的數(shù)據(jù)。

SOA服務(wù)劃分的無(wú)狀態(tài)和有狀態(tài)的分離，在形式上與函數(shù)式編程范式中的純函數(shù)與副作用的分離相對(duì)應(yīng)，只是描述的是不同粒度上的架構(gòu)問(wèn)題。所以也可以在前視算法服務(wù)內(nèi)部再做更細(xì)粒度的狀態(tài)分離。

也就是說(shuō)，向“前視算法服務(wù)”這樣的輕量級(jí)狀態(tài)可以通過(guò)內(nèi)部或外部的進(jìn)一步分解來(lái)做到真正的無(wú)狀態(tài)。服務(wù)劃分得過(guò)于零碎，會(huì)導(dǎo)致服務(wù)部署配置的難度和額外的通訊開(kāi)銷，但這可以通過(guò)其它的技術(shù)優(yōu)化手段來(lái)解決，后文會(huì)詳述。

?

圖3. 6參與 ACC 功能的服務(wù)(簡(jiǎn)化圖)

圖中的“ACC會(huì)話服務(wù)”的狀態(tài)就復(fù)雜的多。當(dāng)用戶啟動(dòng)ACC 功能，從功能激活到退出是一個(gè)完整的會(huì)話過(guò)程，會(huì)話的狀態(tài)細(xì)節(jié)由狀態(tài)機(jī)進(jìn)行控制。這是典型的“遠(yuǎn)程會(huì)話”架構(gòu)風(fēng)格，這與一個(gè)Telnet 會(huì)話其實(shí)是非常相似的，都有一個(gè)會(huì)話生命周期過(guò)程。只不過(guò)在一輛車上，一個(gè) ACC 會(huì)話同一時(shí)間只會(huì)出現(xiàn)一次，單輛車上不會(huì)出現(xiàn)同時(shí)多個(gè)ACC 會(huì)話實(shí)例。這個(gè)會(huì)話服務(wù)未必就沒(méi)有辦法是無(wú)法拆解成無(wú)狀態(tài)的形式，但是會(huì)導(dǎo)致大量的狀態(tài)數(shù)據(jù)在每次請(qǐng)求中傳輸，同時(shí)實(shí)現(xiàn)上沒(méi)有狀態(tài)機(jī)形式更自然，徒增復(fù)雜性。

設(shè)計(jì)某一個(gè)具體的車載SOA服務(wù)時(shí)，對(duì)服務(wù)狀態(tài)分布的選擇最好在強(qiáng)狀態(tài)的“遠(yuǎn)程會(huì)話”和“無(wú)狀態(tài)”兩個(gè)極端風(fēng)格中二選一。應(yīng)該避免在客戶端和服務(wù)端都維護(hù)狀態(tài)數(shù)據(jù)。

從“關(guān)注點(diǎn)分離”的視角看，“無(wú)狀態(tài)”化設(shè)計(jì)分離了狀態(tài)“數(shù)據(jù)的存儲(chǔ)與傳輸”和“狀態(tài)數(shù)據(jù)的處理”兩個(gè)關(guān)注點(diǎn)。



圖3. 7 SOA：客戶-服務(wù)器-狀態(tài)分布

3.3.3 服務(wù)發(fā)現(xiàn)

復(fù)雜的軟件系統(tǒng)被分解為大量小規(guī)模的服務(wù)后，服務(wù)之間也會(huì)有很多依賴關(guān)系，某個(gè)服務(wù)同時(shí)也會(huì)作為客戶端訪問(wèn)其它服務(wù)。一個(gè)客戶端訪問(wèn)另一個(gè)服務(wù)，需要知道該服務(wù)的訪問(wèn)點(diǎn)，對(duì)于TCP/IP 協(xié)議棧來(lái)說(shuō)，至少包含IP和Port信息。同時(shí)，還需要知道該服務(wù)是否可用。因?yàn)榉?wù)可能還未啟動(dòng)，或者在啟動(dòng)中，或者因?yàn)槟撤N原因停止了服務(wù)。

服務(wù)的訪問(wèn)點(diǎn)是可以通過(guò)配置文件靜態(tài)配置的，如果系統(tǒng)中只有幾個(gè)服務(wù)靜態(tài)配置難度還不大，如果服務(wù)數(shù)量上升到幾十個(gè)甚至更多，靜態(tài)配置的維護(hù)難度就非常大。

某個(gè)服務(wù)啟動(dòng)時(shí)，為了它所依賴的服務(wù)已經(jīng)就緒，就需要對(duì)服務(wù)的啟動(dòng)順序進(jìn)行管理。這對(duì)大量服務(wù)并存的系統(tǒng)也是很難做到的。

因此，我們給 SOA 架構(gòu)風(fēng)格增加一條約束“每個(gè)服務(wù)具備能被其它服務(wù)發(fā)現(xiàn)的能力，也能查找需要使用的其它服務(wù)”。

所謂實(shí)現(xiàn)被其它服務(wù)發(fā)現(xiàn)的能力，意味著該服務(wù)應(yīng)該至少具備一下兩個(gè)能力：

1、服務(wù)可用性狀態(tài)發(fā)生變化時(shí)能通知其它服務(wù)

2、響應(yīng)對(duì)服務(wù)可用性的查詢

第1條是事件發(fā)生時(shí)的主動(dòng)通知，不關(guān)心誰(shuí)接收。第2條是主動(dòng)響應(yīng)對(duì)本服務(wù)可用狀態(tài)的查詢。這也意味著每個(gè)服務(wù)需要維護(hù)自己的可用性狀態(tài)。



圖3. 8 SOA：客戶-服務(wù)器-狀態(tài)分布-服務(wù)發(fā)現(xiàn)

除了事件性的通知機(jī)制，“服務(wù)發(fā)現(xiàn)”也需要包括主動(dòng)查詢服務(wù)可用性的能力。上圖顯示了在 SOA架構(gòu)風(fēng)格上增加“服務(wù)發(fā)現(xiàn)”后的圖示和約束。

相對(duì)于靜態(tài)配置，“服務(wù)發(fā)現(xiàn)”實(shí)際上提供了動(dòng)態(tài)配置的能力，提高了系統(tǒng)的可維護(hù)性和可配置性。因?yàn)榉?wù)不是靜態(tài)配置的，當(dāng)一個(gè)服務(wù)失效時(shí)，可以很快的用另一個(gè)相同功能的服務(wù)替換掉它，新服務(wù)的訪問(wèn)點(diǎn)信息會(huì)很快在系統(tǒng)中被其它服務(wù)獲取，系統(tǒng)可以很快能從服務(wù)失效引起的錯(cuò)誤中恢復(fù)，提高了系統(tǒng)的可靠性。當(dāng)某個(gè)服務(wù)需要被升級(jí)時(shí)，也可以采用類似的方式進(jìn)行，對(duì)系統(tǒng)的可進(jìn)化性也有顯著幫助。

3.3.4 基于“事件/消息”發(fā)布訂閱

我們?cè)僭黾右粭l約束，“服務(wù)之間支持基于‘事件/消息’的發(fā)布訂閱機(jī)制，以降低服務(wù)之間的耦合性。”

關(guān)于這個(gè)約束有很多稱呼方式，含義接近但又各有側(cè)重點(diǎn)，如：事件總線(EventBus), 消息通訊，發(fā)布訂閱模式等。

“事件總線”的稱呼，關(guān)注點(diǎn)在于系統(tǒng)中事件的觸發(fā)，比如UI程序中的用戶交互，或者OS內(nèi)核的中斷。事件發(fā)生后“廣播”出來(lái)，由感興趣的軟件模塊去處理。事件產(chǎn)生源不關(guān)心事件的處理者是誰(shuí)。但是對(duì)于本地程序來(lái)說(shuō)事件的觸發(fā)到事件的處理可能是在一個(gè)線程里同步執(zhí)行的。

“消息通訊”關(guān)注點(diǎn)在于數(shù)據(jù)的傳輸方式以及隱含的消息的異步處理語(yǔ)意。意味著發(fā)送者發(fā)出“消息”后，就不再擁有消息數(shù)據(jù)的內(nèi)存所有權(quán)(“潑出去的水”)。發(fā)送者和消息接收者對(duì)消息數(shù)據(jù)的處理是異步的，發(fā)送者不用等待接收者確認(rèn)。

“事件總線”和“消息通訊”都可以實(shí)現(xiàn)“發(fā)布/訂閱”模式。這里發(fā)布者和訂閱者之間只共享“事件名稱”，或稱作“消息主題”。發(fā)布者按主題發(fā)布消息，不關(guān)心誰(shuí)會(huì)收到；訂閱者按主題接收消息，不關(guān)心消息從哪里來(lái)。

這種特性讓軟件模塊的測(cè)試也變得非常方便，我們可以在非生產(chǎn)環(huán)境中發(fā)送模擬的消息來(lái)測(cè)試軟件的功能?？梢凿浿粕a(chǎn)環(huán)境的消息然后線下回放來(lái)做仿真測(cè)試。



圖3. 9 SOA：客戶-服務(wù)器-服務(wù)發(fā)現(xiàn)-發(fā)布訂閱

“發(fā)布/訂閱”風(fēng)格顯著降低了系統(tǒng)各組件之間的耦合度。添加訂閱某個(gè)主題消息件的新組件變得非常容易（可擴(kuò)展性）、只要組件接收或發(fā)送消息格式（接口）確定，該組件就可以被用在任何支持這個(gè)消息格式的場(chǎng)合（可重用性）；允許組件被替換而不會(huì)影響其它組件的接口（可進(jìn)化性）。發(fā)布訂閱風(fēng)格為可擴(kuò)展性、可重用性和可進(jìn)化性提供了強(qiáng)有力的支持。

發(fā)布/訂閱的一個(gè)缺點(diǎn)是：難以預(yù)料一個(gè)事件將會(huì)產(chǎn)生什么樣的響應(yīng)（缺乏可理解性），事件通知并不適合交換大粒度的數(shù)據(jù)，而且也不支持從局部故障中恢復(fù)。

上圖為我們的 SOA 架構(gòu)增加了基于“事件/消息”發(fā)布訂閱風(fēng)格。多個(gè)服務(wù)之間有相互交互的方式，交互方式有基于RPC的“請(qǐng)求/響應(yīng)”，也有基于“事件/消息”的發(fā)布訂閱方式。

從“關(guān)注點(diǎn)分離”的視角看，發(fā)布訂閱分離了數(shù)據(jù)的“生產(chǎn)者”和“消費(fèi)者”兩個(gè)關(guān)注點(diǎn)。

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ī)制。對(duì)于這些成熟的既有系統(tǒng)，可以為它們?cè)黾右粋€(gè)代理服務(wù)。代理服務(wù)仍然按照原有的方式(如:Can 總線)跟既有系統(tǒng)進(jìn)行通訊。但是代理服務(wù)對(duì)外可以以獨(dú)立SOA服務(wù)的方式呈現(xiàn)，提供標(biāo)準(zhǔn)的訪問(wèn)接口， 接口暴露既有系統(tǒng)可以開(kāi)放的部分能力。下圖在SOA架構(gòu)風(fēng)格上增加了服務(wù)代理風(fēng)格。



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

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

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

3.3.6 服務(wù)裝配

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

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

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

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

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



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

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

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

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

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

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

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

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

?

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

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

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

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

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

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

3.3.8 RESTful API

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

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



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

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

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

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

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

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

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

這些就是SOA 服務(wù)轉(zhuǎn)換為 RESTfulAPI 的基本映射方式。一般來(lái)說(shuō)并不需要為所有服務(wù)設(shè)計(jì)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í)行代碼。這個(gè)受控的環(huán)境只能訪問(wèn)指定的資源，對(duì)資源的訪問(wèn)權(quán)限被限制在預(yù)定義的范圍內(nèi)。

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

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

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

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

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

這種方式在智能網(wǎng)聯(lián)汽車的“車路云協(xié)同”上是有應(yīng)用場(chǎ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)用。但是更靈活的方式，是開(kāi)放執(zhí)行環(huán)境，由車端上傳代碼來(lái)決定如何利用數(shù)據(jù)。當(dāng)然被執(zhí)行代碼的權(quán)限也會(huì)被限制，執(zhí)行環(huán)境也會(huì)是一個(gè)受限的沙箱。

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

3.3.9 小結(jié)

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

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

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

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

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

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

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

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

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

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

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

也就是說(shuō)數(shù)據(jù)的處理不應(yīng)該依賴于特定的連接方式。架構(gòu)師甚至希望只需要提供給開(kāi)發(fā)團(tuán)隊(duì)模擬的連接方式并回放預(yù)先錄制的數(shù)據(jù)，開(kāi)發(fā)團(tuán)隊(duì)基于這些來(lái)實(shí)現(xiàn)其數(shù)據(jù)“處理元素”?！疤幚碓亍钡耐瓿善房梢员患軜?gòu)師集成到真實(shí)的應(yīng)用環(huán)境中，那時(shí)使用的可能是不同的連接元素。

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

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

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

3.5.1 SOA vs 分布式對(duì)象

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

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

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

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

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

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

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

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

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

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

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

不同對(duì)象的接口差異大

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

對(duì)象類型多、接口各不相同對(duì)于開(kāi)發(fā)本地應(yīng)用來(lái)說(shuō)不是大問(wèn)題，因?yàn)橐话銘?yīng)用程序也就幾十的對(duì)象類型，即便幾百個(gè)也是在可以處理的數(shù)量級(jí)內(nèi)。但是對(duì)于WWW 系統(tǒng)，可能會(huì)面臨幾千萬(wàn)甚至更高數(shù)量級(jí)的對(duì)象類型，沒(méi)人能處理這么復(fù)雜的系統(tǒng)互操作。

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

廣義的“以太網(wǎng)”包含了常用的通訊協(xié)議，最核心的是對(duì)IP 層協(xié)議的支持。ISO/OSI 定義的七層網(wǎng)絡(luò)模型中，物理層和鏈路層之上是 IP 層（網(wǎng)絡(luò)層）。傳輸層協(xié)議(TCP,UDP)也都是基于 IP 層。IP成定義了數(shù)據(jù)報(bào)文進(jìn)行地址和傳輸?shù)膮f(xié)議，無(wú)論下面兩層如何實(shí)現(xiàn)，只要有IP層的支持，不同網(wǎng)絡(luò)就是互通的。在這個(gè)語(yǔ)義下，WiFi 也是以太網(wǎng)，因?yàn)樗仓С?IP 協(xié)議。我們還可以實(shí)現(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)用需要在這個(gè)基礎(chǔ)的數(shù)據(jù)鏈路層協(xié)議上去定義自己的數(shù)據(jù)格式，一般以一個(gè)DBC 格式文件描述。Lin總線成本更低， FlexRay 總線提供了比 Can 高得多的數(shù)據(jù)傳輸帶寬，但是他們也跟 Can 總線一樣，只有物理層和數(shù)據(jù)鏈路層，應(yīng)用層協(xié)議各自為政。

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

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

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

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

引入以太網(wǎng)技術(shù)帶來(lái)的 IP 層是解決這些問(wèn)題的關(guān)鍵。不管各段網(wǎng)絡(luò)的物理層和鏈路層是什么樣的，只要支持 IP層協(xié)議，IP報(bào)文就可以在不同網(wǎng)段之間傳輸。IP 協(xié)議是可以支持廣播和多播（一次數(shù)據(jù)發(fā)送，多個(gè)目標(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。將來(lái)升級(jí)到萬(wàn)兆甚至更高的光纖以太網(wǎng)也是指日可待。而這種升級(jí)在軟件架構(gòu)上幾乎不需要做太多變化就可以利用網(wǎng)速提高帶來(lái)的好處。這樣在數(shù)據(jù)報(bào)文設(shè)計(jì)上就不用像設(shè)計(jì)Can報(bào)文一樣精打細(xì)算的利用好每一個(gè) bit。必要的情況下可以增加更多的頭信息支持更多的功能。也可以用來(lái)傳輸圖像等多媒體數(shù)據(jù)。擴(kuò)大了SOA的服務(wù)能力范圍。

TCP/IP 協(xié)議發(fā)展了很多年，是互聯(lián)網(wǎng)的技術(shù)基礎(chǔ)。衍生出了無(wú)數(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èn)題需要解決。以太網(wǎng)的工作模式就是多個(gè)聯(lián)網(wǎng)節(jié)點(diǎn)上的多個(gè)應(yīng)用爭(zhēng)搶網(wǎng)絡(luò)帶寬。某個(gè)應(yīng)用的高帶寬占用可能會(huì)導(dǎo)致另一個(gè)應(yīng)用的緊急數(shù)據(jù)不能及時(shí)傳輸，影響車內(nèi)服務(wù)之間通訊的實(shí)時(shí)性。TSN (時(shí)間敏感網(wǎng)絡(luò))相關(guān)協(xié)議的就是用來(lái)解決這些問(wèn)題。

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

3.5.4 SOA 與 微服務(wù)

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

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

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

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

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

3、更徹底的去中心化

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

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

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

“分布”與“集中”

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

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



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

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

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

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

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

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

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

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

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

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

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

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

審核編輯：劉清