詳細(xì)介紹一下SOME/IP協(xié)議

SOME/IP，全稱為Scalable service-Oriented MiddlewarE over IP，是用于控制消息的汽車中間件解決方案，是一種面向服務(wù)的可伸縮的協(xié)議。SOME/IP于2011年由BMW設(shè)計，2014年納入AUTOSAR規(guī)范。

SOME/IP的報文格式如下圖所示，由消息頭部(Header)和消息體(Payload)組成，Header主要包括以下字段：

Message ID，用于唯一標(biāo)識消息，當(dāng)消息為Method類型時，由Service ID和Method ID組成，當(dāng)消息為Event類型時，由Service ID和Event ID組成，如下圖所示：

Length，消息長度(從Request ID開始到Payload結(jié)束)；

Request ID，服務(wù)提供者和調(diào)用者可用于區(qū)分相同消息的不同調(diào)用，由Client ID和Session ID組成，如下圖所示：

通常我們稱服務(wù)提供者為Service，服務(wù)調(diào)用者為Client，Service ID和Client ID用于區(qū)分，一般會在一個SOA架構(gòu)中統(tǒng)一地配置這些ID的數(shù)值。

這里插播一點個人理解，在SOA中，每個服務(wù)就好像我們每一個人在社會中扮演的角色，在對別人提供著服務(wù)的同時，同時也享受著別人提供出來的服務(wù)，人與人之間，既是彼此獨立的，又是需要互相通訊的。服務(wù)提供者將功能具象為一組接口，這樣使用者就能知道如何調(diào)用服務(wù)，完成某件事情，得到某個結(jié)果。

Protocol Version，協(xié)議頭版本號，目前該值必須為1；

Interface Version，接口版本號，一般由服務(wù)提供者定義；

Message Type，用于標(biāo)識消息的類型，如下圖所示：

消息類型和通信機制之間的映射關(guān)系，如下圖所示(靈魂畫手，將就看吧)，不難發(fā)現(xiàn)，F(xiàn)ield結(jié)合了Method和Event，這也就理解了Message ID中為什么只有Method ID和Event ID，沒有Field ID。Field可以用于實現(xiàn)這樣一種通信場景：客戶端希望能夠獲取/設(shè)置/監(jiān)聽服務(wù)端的某一個狀態(tài)值，圖中SOME/IP-SD

Return Code，用于標(biāo)識請求是否成功處理，不同的消息類型，它們在傳輸時所攜帶的Return Code也不同：

具體返回值和錯誤碼定義如下：

Payload，也叫有效載荷，是消息內(nèi)容，通常它的長度是可變的。SOME/IP協(xié)議在OSI七層網(wǎng)絡(luò)結(jié)構(gòu)中位于應(yīng)用層，它建立在TCP或者UDP傳輸層協(xié)議之上。當(dāng)通過UDP傳輸時，由于UDP的限制，Payload的長度應(yīng)該限制在1400字節(jié)以內(nèi)，超了則要分組(SOME/IP-TP)，而當(dāng)通過TCP傳輸時，可以傳輸更多的字節(jié)，理論上只要不超過Length字段的大小即可。

對于AUTOSAR系統(tǒng)，Payload要遵循AUTOSAR規(guī)范進行序列化，對于非AUTOSAR系統(tǒng)，可以遵循AUTOSAR規(guī)范進行序列化，也可以采用其他序列化方式如常用的Google Protocol Buffer、JSON等。

以上介紹了SOME/IP協(xié)議，可以發(fā)現(xiàn)，SOME/IP其實并不等同于SOA，只能說要實現(xiàn)SOA，SOME/IP是一個很不錯的協(xié)議選擇。

審核編輯：劉清