數字管家 | 智慧道路數據接入架構的演進之路
隨著我國智慧城市建設及新基建的推進,對城市道路智慧化建設提出新的要求。智慧道路是借助物聯網、大數據、人工智能等新一代信息技術,構建以數據為核心,以信息的收集、處理、分析和發布為主線,實現道路基礎設施數字化、管理科學化、運行高效化和服務品質化,從而解決交通問題、降低運行能耗、提升出行體驗的新型道路。而智慧道路平臺離不開各種類型的物聯設備,如智能桿、信息屏、燈控、攝像頭、井蓋,WIFI,智能電源、環境監測器等,這些設備產生和采集的數據如何安全、高效、穩定的接入平臺,一直是智慧道路工程師們關注和探索的問題。
在此背景下,深圳市城市交通規劃設計研究中心(以下簡稱“深城交”)深入探索涵蓋路段、路口、路面的全空間智慧道路集成化解決方案,面向大數據存儲、計算與通訊需求,兼顧性能要求和經濟性,針對百萬路視頻結構化的分析技術瓶頸,構建“云-邊-端”分布式存儲及協同調度的交通大數據智能計算平臺架構,經歷了三次大的數據接入框架升級,從而可以支持TB級別數據的秒級計算,在車路協同場景下能保證數據計算時延在毫秒級別,對提升業務賦能,支撐精準管控與品質服務起到了較大的作用。
數據接入1.0框架
智慧道路發展初期階段,主要桿件掛載設備是視頻攝像頭,燈控,信息屏等,種類及生產廠家比較單一。1.0框架通過創建一個數據接入處理工程來實現所有桿件設備的數據接入處理,整套數據均采用同一家廠商的同一種型號設備產生的,這樣做法的好處是有效減少了數據不兼容問題,在創建好的工程服務里對接入的數據進行解析處理,接著再把處理好的數據寫入數據庫,即可完成數據接入工作,見圖1。
圖1
1.0的框架部署簡單,不存在任何的技術壁壘,大多數情況下只需要一個工程包和一套成熟的技術棧就可以滿足智慧道路平臺日常數據接入工作。但該框架缺點也是很明顯的,如系統啟動慢, 一個進程包含了所有設備數據接入的業務邏輯,涉及到的啟動模塊過多,導致系統的啟動,重啟周期邊長;系統錯誤隔離性差,可用性差,任何一個模塊的錯誤可能導致整個系統的宕機;可伸縮性差,系統的擴容只能對整個應用擴容,不能做到對單個功能點進行擴容;線上問題修復時間長,任何一個線上問題修復需要對整個應用系統進行全面升級,同時隨著智能燈桿掛載設備種類及生產廠商的增加,每家廠商接入方式都不一樣,導致工程包越來越大擴大了該框架的缺點。
為此,深城交的智慧道路平臺的架構師們精研技術,對1.0架構進行調整升級,引入微服務架構的概念對不同類型設備數據接入服務組件化。
數據接入2.0框架
2.0框架,一種將單一應用程序開發為一組小型服務的方法,每個服務運行在自己的進程中,服務間通信采用的輕量級通信機制(通常為HTTP資源API),服務圍繞業務能力構建可通過全自動部署機制獨立部署、公用一個最小型的集中式的管理。另外服務可用不同的語言進行開發,使用不同的數據儲存技術,大大提高開發和數據管理的協調性。其中,對于不同類型的設備接入,建立不同的微服務工程進行數據接入處理,見圖2。
圖2
與1.0框架相比,2.0框架易于開發,一個服務工程只對接處理一個類型設備進行入庫,有獨立的代碼庫,開發任務可以同時獨立進行,避免了單一工程協作沖突,提高了開發效率。同時也加強了系統健壯性和可維護性,某個服務出問題不影響其他服務正常運行,保障了系統的高可用性,不會出現大面積癱瘓,某個微服務修改只需要部署修改的微服務就行,不影響其他服務;單個服務啟動塊,單個服務代碼量少;技術棧不受限,可以結合業務和團隊的特點,合理選用技術棧;資源按需收縮,可根據需求,實現細粒度的擴展,例如,系統中的某個微服務遇到了瓶頸,可以結合微服務的特點,增加內存,升級CPU或增加節點。在這種模式下,更多的服務意味著更多的運維人力投入,運維成本會有所增加。
另外,同一類型的設備來自不同的廠商,接入方式也存在差異,但最終寫入的表是一致的,為此將共性重復的工作抽取出來封裝成公共服務組件,將數據接入過程分工層級化,明確了各層的職責,這里將數據接入處理服務過程拆分為兩步進行,見圖3:
(1) 數據接入轉換:將不同產商某類型設備接入的數據進行統一數據格式轉換
(2) 數據處理中心:對每個類型設備提供寫入服務接口
圖3
在這種策略下,不同廠商的設備的數據格式達到了統一,再通過調用數據處理中心的服務接口將數據寫入數據庫中,極大減少了寫入過程的工作量,提高了開發效率。
但是,在該種模式下仍然不可避免當處理中心服務器出現問題后,存在數據無法自動寫入數據庫,為了補錄數據,需要人工檢查日志,手動錄入等弊端。因此,深城交智慧道路平臺的架構師基于2.0架構,繼續迭代升級,引入高性能、持久化、多副本備份、分布的kafka消息隊列,進一步進行分工層級化,將架構升級到3.0版本。
數據接入3.0框架
3.0框架將接入的數據進行統一格式轉換后推送到kafka消息隊列集群,再對數據處理中心進行改造,按推送數據類型監聽不同主題進行消費,將數據寫入數據庫,圖4。
圖4
在3.0框架下,由于數據先暫存在kafka消息隊列上,當數據處理中心服務出現問題或需要停機升級改造部署時,采集的數據當服務恢復了可以再次自動寫入,防止數據丟失,提升了數據接入服務質量。另外,kafka消息隊列還支持數據共享,可以讓需要的服務端訂閱數據進行數據分析研究;同時支持大量數據入庫,根據數據接入量,彈性伸縮部署多個數據處理中心,進行數據寫入,從而保證數據寫入的實時性;數據的安全性也有了大幅度提升,通過將轉換后的數據進行加密推送,訂閱方再按配對的秘鑰進行解密,從而保證數據安全,在深信投,三龍灣,龍泉驛等智慧道路項目都進行了推廣實際應用。
通過三次大的技術框架升級,可以支持千萬級的數據寫入,同時預留無限擴展的空間,可以根據數據量進行彈性伸縮部署,同時也支持新增場景類型數據的功能擴展,在深信投多功能智能桿項目(見圖5)上應用了3.0技術框架接入了9644根桿,近1萬多套設備的數據接入,每天處理上百萬條數據接入,保障了深圳全市多功能智能桿及掛載 設備的運行監測、運維管控、數據匯聚,為全市多功能智能桿發展政策研究和行業監管、桿體建設、產業發展等提供管控手段和數據支撐,支撐建設智慧城市基礎管控系統。
圖5
在佛山三龍灣智慧道路項目(見圖6)上也進行了應用,接入了水浸、智能井蓋、智慧照明、環境氣象等1千多套設備的數據接入,每天處理三十多萬條數據接入,支持了三龍灣大道以多功能智慧燈桿為核心打造的智慧道路管理平臺,集成智慧照明、視頻AI、信息發布、環境氣象檢測等多種設備于一體,實現了多部門設施共享共建和集約化管理系。
圖6
同時此技術框架也支持未來“N”種智慧應用延展見圖7,支持更多場景應用的數據接入,助力深城交打造出更優秀的產品,成為全球領先的城市交通整體解決方案提供者。
圖7
智慧道路數據接入架構演進,我們一直在努力,未來我們希望建立支持更多數據接入方式,功能組件豐富,快速低成本開發,數據流監控清晰,易部署運維,安全穩定的數據接入管理平臺,讓交通與城市更美好,一直在路上。
結語
深城交擁有一支涵蓋交通、城規、建筑、景觀、工程、智慧等多專業協同的技術團隊,以“讓交通與城市更美好”為使命,致力于為城市提供先進的交通技術服務和整體解決方案,成為全球領先的城市交通整體解決方案提供者。
未來將持續發揮多專業融合的優勢,立足于國際視野,開展城市軌道交通領域多項研究,覆蓋軌道交通客流預測、線網規劃、運營組織、成本規制、戰略研究及TOD開發等。為相關政策出臺、規劃編制提供有力技術支撐。
交通信息與模型院
撰寫:嚴 偉
審核:吳情平、屈新明
審定:丘建棟