数字管家 | 智慧道路数据接入架构的演进之路

随着我国智慧城市建设及新基建的推进,对城市道路智慧化建设提出新的要求。智慧道路是借助物联网、大数据、人工智能等新一代信息技术,构建以数据为核心,以信息的收集、处理、分析和发布为主线,实现道路基础设施数字化、管理科学化、运行高效化和服务品质化,从而解决交通问题、降低运行能耗、提升出行体验的新型道路。而智慧道路平台离不开各种类型的物联设备,如智能杆、信息屏、灯控、摄像头、井盖,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开发等。为相关政策出台、规划编制提供有力技术支撑。

 

 

 

交通信息与模型院

撰写:严 伟

审核:吴情平、屈新明

审定:丘建栋

 

返回列表