一種基于Dubbo的車聯(lián)網(wǎng)命令發(fā)送方法的設(shè)計

摘要：該文介紹了一種基于Dubbo框架實現(xiàn)的車聯(lián)網(wǎng)命令發(fā)送方法。該方法通過服務(wù)的注冊機制，擴展了Dubbo的Cluster接口的方式，實現(xiàn)了命令管理服務(wù)自動感知車輛接入服務(wù)擴容和縮容，并可以對多個實例進行透明的訪問。另外采用先詢問，確定車輛接入的服務(wù)后再下發(fā)命令到車上的方式解決了控制命令的私密性，提高了系統(tǒng)的安全性。

關(guān)鍵詞：車聯(lián)網(wǎng);命令系統(tǒng);分布式訪問

中圖分類號：TP393 文獻標識碼：A

文章編號：1009-3044（2020）21-0050-02

開放科學（資源服務(wù)）標識碼（OSID）：

1 背景

隨著物聯(lián)網(wǎng)優(yōu)勢不斷顯現(xiàn)，汽車接人互聯(lián)網(wǎng)也慢慢成為標配。尤其是新能源汽車更是以國家規(guī)范的方式，要求必須接人到車聯(lián)網(wǎng)，以滿足車企和政府的安全監(jiān)管需求。

車聯(lián)網(wǎng)系統(tǒng)平臺應(yīng)支持數(shù)萬、數(shù)十萬甚至是數(shù)百萬的車輛接人。由于單服務(wù)器的資源受限，無法支持巨量車輛的網(wǎng)絡(luò)接人，需要多臺接人服務(wù)器，形成一個服務(wù)集群來為車輛提供互聯(lián)服務(wù)。

車輛在接人車聯(lián)網(wǎng)時，由于網(wǎng)絡(luò)環(huán)境的差異導致鏈接可能隨時中斷。也會發(fā)生的接人服務(wù)器可能無法提供服務(wù)，在設(shè)計上，車輛會維持一個主機列表，車輛會根據(jù)實際情況隨機選擇連接的主機。這樣車輛接人點是動態(tài)的變化的。

當用戶需要控制車輛下發(fā)控制命令，如開關(guān)車窗、門鎖等。由于車輛的動態(tài)接人原因，命令管理服務(wù)難以知道其所需要控制的車輛所在的接人點。傳統(tǒng)上，有兩個方法解決這個問題，一種是采取廣播的方式，命令管理服務(wù)將命令廣播到每個接人服務(wù)中。另一個方法是在命令管理服務(wù)中維持每個車輛接人服務(wù)名稱和其位置信息（ip和端口）的對應(yīng)關(guān)系，并根據(jù)車輛上報數(shù)據(jù)時所在接人服務(wù)的名稱，查找到接人服務(wù)的位置信息，將命令發(fā)送到接人訪問。

第一種方法命令內(nèi)容的安全性不強，第三方實現(xiàn)的車輛接人服務(wù)可以輕易獲取車輛控制命令。第二種方法不支持車輛接人服務(wù)的動態(tài)擴容和縮容，如果增加一臺車輛接人服務(wù)器，那么需要將此服務(wù)器的ip地址和端口手動添加至命令管理系統(tǒng)，導致需要頻繁增加或刪除配置，甚至需要重啟命令管理系統(tǒng)。實時性不強，且設(shè)計復雜。

2 設(shè)計方案

命令管理服務(wù)系統(tǒng)的設(shè)計目的是當存在多個車輛接人服務(wù)實例運行，車輛可隨機選擇連接其中一個接人服務(wù)時，命令管理服務(wù)能夠準確地透明地將命令下發(fā)至指定車輛。另外，系統(tǒng)應(yīng)支持車輛接人服務(wù)能夠動態(tài)擴容和縮容。

2.1總體架構(gòu)

由上圖，整個系統(tǒng)方案由三個服務(wù)組件組成。分別為車輛接人服務(wù)、命令管理服務(wù)以及注冊組件。車輛接人服務(wù)可以啟動多個實例，并向注冊組件注冊本服務(wù);注冊組件保存車輛接人服務(wù)各實例的配置和接口信息;命令管理服務(wù)可以讀取注冊組件中車輛接人服務(wù)的注冊信息，并可以調(diào)用車輛服務(wù)實例中的下發(fā)命令的接口。

2.1.1方案組成部分說明

2.1.1.1車輛接入服務(wù)

車輛接人服務(wù)主要負責車輛的網(wǎng)絡(luò)接人的服務(wù)，為車輛提供數(shù)據(jù)交互和鏈接維持功能。

2.1.1.2命令管理服務(wù)

命令管理服務(wù)主要負責接收用戶的命令下發(fā)，并準確地向指定車輛發(fā)送命令的功能。主要包含選擇器和篩選器兩個策略器。

2.1.1.3注冊組件

注冊服務(wù)主要負責保存各服務(wù)的注冊信息，記錄各服務(wù)的位置以及調(diào)用接口等元數(shù)據(jù)信息。支持存儲節(jié)點的動態(tài)更改通知。

2.1.2接入服務(wù)注冊和刪除流程

車輛接人服務(wù)實例在啟動的時候向注冊組件注冊自己的位置及接口的相關(guān)信息。當有命令下發(fā)，命令管理服務(wù)從注冊組件中獲取車輛接人服務(wù)列表信息，采用遠程過程調(diào)用RPCⅢ的方式直接訪問車輛接人服務(wù)的接口。另外，命令管理服務(wù)緩存了車輛接人列表實例信息，如果有新的車輛接人服務(wù)實例上線或者原有的服務(wù)下線，注冊組件中的數(shù)據(jù)均會改變。注冊組件會立即將改變推送至命令管理服務(wù)，命令管理服務(wù)可以實時維護最新的車輛接人服務(wù)的列表，從而支持了車輛接人服務(wù)自動透明的擴容和縮容。

2.2 命令下發(fā)流程

命令管理服務(wù)在接收到用戶的車輛控制命令后，獲取指定車輛的標識符，向車輛接入服務(wù)廣播，詢問指定車輛所在接入服務(wù)的位置。如果車輛在線，將會收到一個接人服務(wù)在線的應(yīng)答，表明車輛在此接人服務(wù)中上線。然后命令管理服務(wù)調(diào)用命令下發(fā)接口將命令發(fā)送到此接人服務(wù)中，進而通過TCP鏈接轉(zhuǎn)發(fā)至車輛的接收設(shè)備，實現(xiàn)了命令下發(fā)的過程。

2.2.1 在線鏈接詢問

在線鏈接詢問是命令管理服務(wù)向各個接入服務(wù)詢問指定終端在線情況的過程。管理服務(wù)采取廣播的方式詢問接人服務(wù)，接人服務(wù)將車當前在線或者離線狀態(tài)返回給命令管理服務(wù)。采取先詢問后發(fā)送命令的好處在于，保證命令內(nèi)容的安全性。由于接人服務(wù)器可能由第三方維護，為了避免將某些敏感的命令信息暴露給第三方的接人服務(wù)，造成不必要的信息泄露。所以在發(fā)送命令之前，先詢問待接收命令的車輛所在服務(wù)的確切位置，后將命令發(fā)送給接人服務(wù)中。

2.2.2 接入服務(wù)選擇器

車輛的TCP鏈接存在假死的情況，當車輛在A接人服務(wù)鏈接意外失效，但服務(wù)并沒有感知，直到超時之后A才發(fā)現(xiàn)車輛長時間沒有發(fā)送數(shù)據(jù)到服務(wù)端1上。從而將鏈接斷開，此時A車才在服務(wù)器端處于離線狀態(tài)。但可能出現(xiàn)A在超時期間，又重新鏈接到了接人服務(wù)2上。那么如果此時用戶要發(fā)送命令到A車，命令管理服務(wù)器詢問A車所在鏈接的位置，服務(wù)1和服務(wù)2均返回A車在線，命令管理服務(wù)無法確認車輛真實所在位置。

解決這個問題的辦法是，實現(xiàn)一個接人服務(wù)選擇器。此選擇器為策略器的具體實現(xiàn)。在命令管理服務(wù)詢問時，接人服務(wù)將返回車輛在線狀態(tài)和最后接收到車輛數(shù)據(jù)的時間。選擇器確定最近收到數(shù)據(jù)的鏈接為車輛的真實在線鏈接，以此接人服務(wù)為選擇出來的服務(wù)。

2.2.3 命令協(xié)議

車輛的控制命令根據(jù)實際需要更新較為頻繁，經(jīng)常出現(xiàn)增加某個控制命令或者更改某個控制協(xié)議。如果協(xié)議轉(zhuǎn)換模塊在車輛接人服務(wù)中實現(xiàn)，勢必導致車輛接人服務(wù)軟件更替較快，影響到車輛的接人服務(wù)。我們將命令協(xié)議放人到命令管理服務(wù)中，車輛接人服務(wù)只接收二進制命令數(shù)據(jù)，可直接發(fā)送。這樣使雙方的接口定義更加的簡單，命令下發(fā)更加靈活，同時也降低了車輛接人服務(wù)的實現(xiàn)復雜度。命令管理服務(wù)在接收到用戶發(fā)送的命令之后，轉(zhuǎn)換成車輛的通信協(xié)議的二進制數(shù)據(jù)后，直接通過車輛接人服務(wù)發(fā)送至車輛。

2.3 具體實現(xiàn)

2.3.1 Dubbo介紹

Apache Dubbo[2]是一款阿里巴巴公司開源的高性能JavaRPC框架。其為用戶封裝了遠程過程調(diào)用的實現(xiàn)細節(jié)，具有智能糾錯，負載均衡和自動注冊發(fā)現(xiàn)等功能。是一款應(yīng)用極為廣泛的RPC框架。

2.3.2 接口定義

接口即為契約，使服務(wù)雙方共同達成的訪問協(xié)議。在命令下發(fā)程序中涉及兩個服務(wù)。一個是車輛接人服務(wù)，另一個是命令管理服務(wù)。命令管理服務(wù)調(diào)用車輛接人服務(wù)的接口，完成命令下發(fā)過程。

ITsService為接口，定義了isOnline和fireBvtesData兩個成員函數(shù)。isOnline就是詢問車輛否在此接入服務(wù)中在線，參數(shù)為車輛標識符;fireCommand即為下發(fā)命令接口，參數(shù)車輛標識符和命令的二進制數(shù)據(jù)。

VehicleService為車輛接人服務(wù)類，維持車輛與平臺的網(wǎng)絡(luò)鏈接，實現(xiàn)了ITsService的接口。

CommandMgrService為命令管理服務(wù)類，接收用戶的命令并通過Dubbo框架遠程調(diào)用VehicleService的接口方法，實現(xiàn)了車輛狀態(tài)的查詢和命令的下發(fā)功能。

2.3.3 篩選器實現(xiàn)

篩選器是在命令管理服務(wù)中實現(xiàn)的詢問車輛所在接人服務(wù)的位置并將命令下發(fā)到車輛的模塊。因為車輛接人服務(wù)器時是按照預先保存的服務(wù)器列表和當時的網(wǎng)絡(luò)環(huán)境隨機選擇主機。系統(tǒng)平臺一開始并不確定某臺車在哪個接入實例中上線。在發(fā)送車輛命令時需要知道當前車輛所在的接人實例，這樣可以利用其維持的網(wǎng)絡(luò)鏈接，向車輛發(fā)送命令信息。車輛在隨機接人服務(wù)器后，系統(tǒng)通過篩選器獲取其所在的接人實例。篩選器主要起到向上屏蔽查查找車輛鏈接位置的邏輯，并完成向車輛發(fā)送命令的功能。我們利用Dubbo集群的Cluster的SPI接口實現(xiàn)了自定義篩選器功能。

在具體實現(xiàn)上，按照Dubbo的提供的JAVA SPI規(guī)范在ME-TA-INF中的dubbo文件夾中建立說明文件com.alibaba.dubbo.rpc.cluster.Cluster，定義Cluster接口的實現(xiàn)并命名為evts。在引用ITsService實例時在@Reference注解中指定cluster成員變量為evts。這樣在CommandMgrService可以直接透明訪問已經(jīng)注冊的車輛接人服務(wù)ITsService接口列表，從而實現(xiàn)車輛在線狀態(tài)詢問和命令發(fā)送過程。

3 結(jié)束語

本文介紹了一種基于Dubbo框架的車聯(lián)網(wǎng)命令下發(fā)方法。此方法支持車輛接人服務(wù)的自動擴容和縮容，屏蔽了查找在線車輛所在接人服務(wù)邏輯，對于單機接人實例和集群接人實例形成了統(tǒng)一一致的訪問方式。有效地降低了系統(tǒng)的復雜度，對命令管理等上層應(yīng)用提供了無感的訪問方式。并且采取詢問發(fā)送的方式，避免了敏感的命令內(nèi)容的泄露，進一步提高了系統(tǒng)的安全性。

參考文獻：

[1] Srinivasan R.RPC： remote procedure call protocol specification[Ml.United States：RFC Editor，1988.

[2] The Apache Software Foundation. Apache Dubbo[EB/OL].[2019- 12-20].http：//dubbo.apache.org/.

【通聯(lián)編輯：謝媛媛】

作者簡介：胡晨光（1981-），男，安徽宿州人，高級工程師，碩士，研究方向為車聯(lián)網(wǎng)、大數(shù)據(jù)。