基于虛擬網關的交通基礎設施監測點位數據接入方法

2024-04-23 10:14:26黃亮鄒鵬曹菁菁胡健顏澤鋅黃小蝶

計算機工程 2024年4期

關鍵詞：系統

黃亮,鄒鵬,曹菁菁,胡健,顏澤鋅,黃小蝶

(1. 武漢理工大學水路交通控制全國重點實驗室,湖北武漢 430063;2. 武漢理工大學國家水運安全工程技術研究中心,湖北武漢 430063;3. 武漢理工大學智能交通系統研究中心,湖北武漢 430063;4. 武漢理工大學交通與物流工程學院,湖北武漢 430063;5. 北京四維圖新科技股份有限公司,北京 100093)

0 引言

2019年7月25日交通運輸部印發《數字交通發展規劃綱要》,目的是推動交通基礎設施規劃、設計、建造、養護、運行管理等全要素、全周期數字化。交通基礎設施數字化通過匯集包括物聯網 (IoT)[1-2]、地理信息系統(GIS)、建筑信息模型(BIM)[3]等在內的多種技術手段,對交通基礎設施進行全方位的信息感知,從而實現對交通基礎設施中各種信息的集成處理。其中,IoT點位監測數據在實時狀態感知、結構健康監測、安全風險評估等方面具有重要價值[4-9]。文獻[10]設計了一套改進型膨脹土邊坡GNSS/多源實時監測技術,對監測數據進行實時采集、存儲、處理和分析,進而實現對邊坡的實時狀態監測;文獻[11]提出了一種基于組合載荷響應特征融合的橋梁結構智能損傷識別方法,利用點位監測數據實現了對橋梁損傷的識別和定位;文獻[12]將航道監測信息作為客觀評價指標,通過熵權模型進行科學賦值,實現了對引航安全風險的精準評估;文獻[13]提出了一種以監測點當前變化量、累計變化量和變化率3個指標為基礎的隧道風險數學模型和智能預警方法,該方法能夠及時有效地進行風險預警。

監測數據在數字化應用中扮演著重要角色,然而,交通基礎設施涵蓋了道路、橋梁、隧道、軌道、航道等多種設施,涉及多種傳感器,產生的監測數據存在數據結構、傳輸協議和采樣頻率各不相同的問題[14-15]。此外,交通基礎設施數字化需要綜合應用多種點位監測數據,這些數據往往又具有數量龐大、多源異構且實時性強的特點,給實時數據的快速接入帶來了一系列挑戰。

目前,主流的物聯網監測數據接入方法主要包括基于Netty的數據接入[16-17]、基于Kafka的接入[18]、基于云平臺的接入等[19]。在這些技術的基礎上,國內外學者進行了多項與數據接入相關的研究。文獻[20]提出了一種由Flink和Kafka集成的工業大數據平臺,能夠實現工業數據的接入、查詢與預警,但是仍存在接入速度慢、接入數據類型少的問題。文獻[21]基于Netty和Kafka開發了一個支持高并發、低延遲的數據接入平臺,能夠在萬級連接下實現快速響應,但是其系統較為簡單,整體性能不足以滿足實際需求。盡管上述技術在某些情況下能夠實現交通設施監測數據的部分接入,但是無法兼顧多源數據統一接入和高效大規模數據接入的要求,對超大規模全生命周期交通基礎設施多源異構數據的實時接入以及存儲能力較弱,這對未來構建交通基礎設施全要素數字模型帶來極大的挑戰。

本文通過使用Netty高性能網絡框架和Kafka消息隊列[22-23],實現交通基礎設施監測數據的高效大規模接入,并結合微服務的高可擴展性,設計一種微服務+Netty+Kafka架構的智能虛擬網關。針對交通基礎設施數據大規模傳輸的特點,采用一種自定義的二進制報文編碼格式,縮短數據報文所需的字節長度,提高網絡傳輸效率,進一步使系統性能得到提升。最后,通過對系統接入速度、存儲速度和溯源速度進行測試,以驗證系統的數據接入性能。

1 交通設施監測數據接入需求分析

部分燈浮監測數據如表1所示,隧道圍巖拱頂變形監測數據如表2所示。

表1 燈浮監測數據示例Table 1 Buoy light monitoring data sample

表2 隧道圍巖變形監測數據示例Table 2 Tunnel surrounding rock deformation monitoring data sample

從表1和表2可以看出,交通基礎設施監測數據涵蓋位置、時間、電壓、電流、沉降等多種信息,這些數據在格式、內容、精度和采樣頻率方面存在顯著差異,呈現出明顯的異構性。隨著監測數據持續產生,數據會不斷累積,數據中每個時間戳都記錄了最新的監測信息,反映了設施的實時狀態。因此,時效性和逐步累積性是交通基礎設施監測數據的兩大特征。上述數據特征對數據接入框架提出以下需求:

1)多源異構監測數據的統一接入需求。

數字交通基礎設施感知設備的數據呈現多源性,這一多源性不僅體現在數據來自不同的采集系統,還在于數據源覆蓋多個地域。當前主流數據傳輸系統采用了多種網絡通信協議,如超文本傳輸協議(HTTP)、用戶數據報協議(UDP)、傳輸控制協議(TCP)等[24]。因此,接入框架需要具備對各種數據來源接入請求的支持和處理多協議、多節點并發操作的能力。

2)數據接入效率高的需求。

交通基礎設施監測設備種類繁多,它們不斷產生龐大的數據量,并且數據持續上傳到數據接入系統。這一巨大的數據體量如果不能及時處理,就會導致數據積壓,可能會造成系統的阻塞。因此,需要高效、迅速地處理數據接入的請求。

3)數據接入規模大的需求。

交通基礎設施數量龐大,產生的監測數據規模也相應增大。為了應對這種規?；臄祿?數據接入系統需要具備同時處理大規模數據的能力。

2 基于虛擬網關的點位數據接入

2.1 虛擬網關架構

本文提出一個基于微服務+Netty+Kafka的智能虛擬網關架構。該架構整合了Netty框架,能夠支持HTTP、TCP、UDP這3種協議,使得多源異構數據能夠按照相應協議高效傳入系統。傳入的數據會被快速寫入Kafka集群,并通過該集群分發至其他存儲組件,以實現持久化存儲。同時,微服務結合Kafka集群的使用,能夠應對大規模數據的處理需求,實現系統的橫向擴展能力。

本文交通基礎設施數據接入智能虛擬網關的整體結構如圖1所示,其涵蓋了Web端網關配置界面、Nacos注冊服務以及核心處理等多個關鍵模塊。各個模塊的核心功能分別如下:

圖1 交通基礎設施數據接入智能虛擬網關結構Fig.1 Traffic infrastructure data access intelligent virtual gateway structure

1)Web端網關配置界面:配置服務器,選擇Docker鏡像包,配置Kafka地址、端口、主題,增/刪/改數據字段,生成數據接收服務地址。

2)Nacos注冊服務:注冊服務,提供服務清單。

3)核心處理模塊:讀取配置,分配端口,拉取鏡像,啟動容器,監聽Nacos注冊,發現、修改Nginx配置,平滑重啟Nginx,驗證服務可用性。

2.2 虛擬網關配置

本文設計并開發一種智能虛擬網關平臺[25],為用戶提供一套可視化監測點位配置界面。通過智能網關配置界面,用戶能夠設定接入數據的類型、接入協議、字段名稱、字段類型、字段說明等關鍵信息,這些配置信息規定了監測點位的配置方式。

在選擇服務器和鏡像后,系統會自動在對應服務器上拉取鏡像,并根據配置的Kafka地址啟動相應的后端服務,這些服務會發布數據發送接口,按照接口規范進行數據傳輸,實現與Kafka集群的接入。此外,系統可以根據網絡情況針對性地對Kafka進行動態配置,充分利用網絡本地特性,就近部署Kafka集群,能夠有效減輕網絡傳輸對系統性能的影響。為了滿足服務的橫向擴展,當單個集群網關達到性能瓶頸時,也可以通過搭建多集群的方式[26],同時啟動多網關分配服務,設置一定的分配規則,比如:

1)基于hash的分配規則。根據客戶端IP地址進行hash計算,將同一客戶端的請求分配給相同的服務器;根據請求的URL信息進行hash計算,將相同URL的請求分配給相同服務器。

2)基于負載均衡的分配規則。將請求依次分配給不同的服務器,確保每臺服務器都有機會處理請求,或將請求分配給當前連接數最少的服務器,以達到負載均衡。

3)基于權重的分配規則。為每臺服務器分配一個權重,高權重的服務器獲得更多的請求,這在服務器性能不同時比較適用。

4)基于地理位置的分配規則。根據客戶端的地理位置信息,將請求分配給最近的服務器,降低網絡延遲,提高訪問速度。

圖2是智能網關的數據接入配置頁面,能夠顯示鐵路、港航、公路、民航的不同交通基礎設施感知設備類別,如信號設備、供電設備、RSU設備、路面監測設備、氣象監測設備、攝像頭、AIS設備、閘壩監測設備、機場風力傳感器等,此外,還可以選擇服務器、鏡像名、Kafka地址、Nginx路由等。每個交通基礎設施感知設備有默認的數據字段,根據實際需要可以通過配置頁面進行刪除、修改、增加,保存后就可以啟動后臺數據接收服務并生成數據接收接口,提供給數據發送方進行數據傳輸。

圖2 虛擬網關數據接入配置頁面Fig.2 Virtual gateway data access configuration page

2.3 多終端多協議數據接入

2.3.1 數據接入流程

數據接入流程如圖3所示。系統的數據輸入涵蓋各類交通基礎設施信息數據源,主要包括道路、鐵路、航標等相關設施的點位監測數據。原始數據通過HTTP/TCP/UDP協議與網關集群相連接,從而啟動數據接入過程。根據不同連接協議和數據包類型,網關將數據分發至相應的HTTP服務集群、TCP服務集群以及UDP服務集群,這些服務集群擁有可伸縮和可擴展的特性。通過標識(Topic),服務集群將經過處理的數據傳輸至Kafka數據總線,進而流入大數據存儲系統進行有效的存儲和管理。同時,數據也會被寫入Redis集群,其中庫名與Topic相匹配,而時間戳加上分區(PARTITION)則成為KEY,設置一定的超時時間以滿足數據回溯的需求。

圖3 數據接入流程Fig.3 Data access process

2.3.2 數據接入協議

虛擬網關支持HTTP、TCP、UDP這3種數據接入協議,對于每種協議下的數據格式做出相關定義,如下:

1)HTTP接入協議(傳感器使用最多)。

HTTP是基于TCP協議的一種應用層傳輸協議,是一種使用最廣泛的協議類型。HTTP接入需要解析數據實體,數據正文形式如表3所示。

表3 HTTP數據正文形式Table 3 HTTP data body format

數據示例如下:

目前，綜合考慮性價比、可靠性和測速性能，基于傳感器的測速方法仍是普通環境下測速應用的首選方法。由于測速傳感器的精度與價格成正比，高精度、高性能測速傳感器高昂的價格讓普通用戶望而卻步。因此針對常規精度測速傳感器，設計一種能保證高、中轉速區測速精度，并能有效改善低速區測速精度的寬范圍、實時濾波測速算法，對拓寬普通測速傳感器的應用范圍具有重要的工程意義。

{

"lcp": "topic1",

"list":[

{"time":"2023-07-11_10:48:54","lng":109.093,"lat":21.498,"U":15.5,"I":0,"temperature":2.0,"humidity":52,"motor_nums":3,"Light_Intensity":5.0},

{"time":"2023-07-11_11:00:53","lng":109.092,"lat":21.498,"U":15.7,"I":0,"temperature":1.8,"humidity":46,"motor_nums":3,"Light_Intensity":5.0},

...

]}

2)TCP接入協議(大規模數據接入)。

在TCP協議下以二進制形式封裝數據報文,如圖4所示,該報文采用big-endian字節順序。

圖4 TCP協議下的報文格式參考Fig.4 Message format reference under TCP protocol

(1)魔數:占用4個字節,固定為WHUT,用于在二進制數據流中區分數據報文。

(2)CRC32校驗碼:占用4個字節,對數據報文中的報文長度、命令ID以及協議報文字段3個部分的字節流求取CRC32校驗碼。

(3)報文長度:占用4個字節,包括命令ID以及協議報文字段的字節流長度。

(4)命令ID:占用4個字節,從1開始編號,用以標識報文所對應的平臺業務。

(5)協議報文:占用可變字節長度,根據命令ID的不同,它所包含的字段也不一樣,其中心跳報文命令ID取值為1,無協議報文。

(6)String類型:字符串長度,占用4個字節,字符串內容以“