基于微服务的交通信息化框架构建

秦小明，陈景诚

（1.江西省公路投资有限公司，江西 南昌 330000；2.江西路通科技有限公司，江西 南昌 330002）

0 引言

随着我国交通建设事业的快速推进，交通发展面临新的机遇和挑战，为此，必须在推进路网基础设施建设的过程中，引入科学高效的管理技术，提升交通基础设施资源分配及利用效率。交通信息化系统是“互联网+交通”的具体体现，是充分利用互联网、物联网、自动化控制技术所构建的人、车、路、环境等核心要素信息化、智能化运行的交通信息管理系统，可实现交通运行数据信息的高效整合和路网统筹管理，增强路网节点之间通行信息流转，实现路网负载均衡，提升路网通行能力，并向人们提供多层次、多渠道、多维度的交通决策支持，提升交通运行效率。

1 交通信息化发展存在的问题

当前交通信息传统单体式架构主要存在以下突出问题：

（1）复杂程度高。随着数据及业务规模的持续增大，外部依赖增多，多模块间耦合性增强，代码结构也愈加复杂，在团队合作过程中因代码理解难度增加，使得代码复用率降低，甚至引发外部依赖版本冲突。此外，因传统单体式架构下代码互相依赖，某个模块代码修改或重构后，其影像范围很难明确界定，从而使代码修改及重构的复杂程度增大；任何一个小的改动都需要重新进行应用的构建和部署，沟通成本高，开发效率低。

（2）交付效率低。传统单体式架构下，当代码量较为庞大时会延长编译时间和重新编译难度，增大定位故障，降低开发效率；代码合并过程中还会面临代码冲突以及较大的代码逻辑关系理解难度。

（3）可扩展性差。交通信息单体结构只能横向扩展，无法分模块垂直扩展，也不能独立进行I/O和CPU密集型模块的升级与扩容。此外，因不同业务模块集成为一体，进行功能扩展时必须停止或重新部署整个项目。全部模块均耦合式部署于一个实例中，容错率低，即使是某个非核心模块故障就能引起整个应用系统崩溃。

（4）不利于技术创新。在技术栈的约束下，必须使用同一种框架和语言，传统单体式架构必然面临较大的重构成本和风险，故不利于框架及语言的重构和创新。

2 基于微服务的交通信息化

2.1 微服务架构概述

微服务架构属于互联网应用服务型软件架构，该架构主要在面向服务架构SOA的基础上发展而来，康威定律中有关组织结构和其设计系统结构关系的描述是微服务架构的核心理论基础[1]。Martin Fowler与James Lewis在2014年率先提出微服务的概念，微服务作为一种能够独立部署、伸缩及测试的小型应用程序，职责较为单一，这种小型应用程序主要根据业务功能予以划分，并通过自动化部署机制独立部署运行，微服务之间则通过轻量级通信机制实现通信。微服务体系主要将单个应用程序拆分成小型服务，各服务均在HTTP资源API的轻量级通信机制下按照所属进程运行，此类服务均围绕业务功能构建，且通过自动化机制独立部署，对服务进行集中化管理。

2.2 微服务与交通信息系统的融合

从逻辑上来看，交通信息系统主要由信息采集、处理及发布等模块组成，交通信息化微服务架构中，不同类型交通信息所对应的微服务功能划分不尽相同。针对信息垂直发布的情形，交通信息无需处理，能直接发布，信息采集微服务则由信息发布相关微服务直接调取。交通信息微服务框架中，不同功能模块拆分成不同微服务，在接口定义完成的基础上，微服务间接口可互相调用。所构建起的交通信息系统微服务架构具体见图1，交通信息系统的主要目的在于为交通参与方提供交通信息服务，交通参与方可以通过移动客户端、浏览器端等多种渠道获取相关信息。虽然不同的信息获取渠道数据展示形式不同，但都对应着同样信息或信息组合，故后端只需提供统一数据格式及内容，数据视图则通过客户端形成并展示。

图1 交通信息系统微服务架构

RESTful Web Services具有跨平台、跨Internet接口调用等功能，并能有效利用HTTP协议，交通信息系统微服务架构前后端数据交换通过RESTful API进行，数据传递主要采用具备自解释性的json格式，能有效避免前后端数据耦合[2]。考虑到微服务数量较多，必须引入一套治理框架以实现微服务统一管理。当前应用较为普遍的是Spring Cloud微服务治理框架，该框架主要借助Spring Boot开发的便捷性使分布式系统基础设施开发过程大幅简化，通过Spring Boot开发风格实现了服务注册、消息总线、配置中心、数据监控、负载均衡等的一键式启动与部署。此外，Spring Boot还将当前成熟的服务框架有机组合后，通过再封装将复杂配置及实现原理予以屏蔽，向开发者呈现出一套部署、维护均较为简便的分布式系统开发工具包。

微服务启动后向Eureka注册中心注册，系统维护人员可同时通过Eureka Server进行微服务运行过程监控；考虑到微服务部署并不使用固定IP，Spring Cloud的API GATEWAY等模块通过Eureka Server发现其他微服务系统后可执行相应逻辑。为实现负载均衡及动态部署，可通过注册中心隐藏IP，使其余微服务主要通过固定名字调取相应的微服务，当其所承受压力过大，还可同时启动一个相同实例，注册后达到横向动态扩容的目的。

交通信息化微服务框架主要通过信息发布模块面向用户提供服务，其余模块则用于微服务架构内部调用，故可通过统一网关API GATEWAY实现权限管理。微服务采用RESTful通信模式，其所采用的JSON WEB TOKEN引入方式会使请求均附带权限信息，JSON WEB TOKEN为信息安全传递的表述性规范，其鉴权流程具体见图2，从客户端提交用户名和密码后，服务端调用权限予以验证，并将所取得的用户角色信息加载至JWT负载，服务端对JWT解析后验鉴，通过后即可调用微服务权限。

图2 JSON WEB TOKEN鉴权流程

2.3 微服务业务模块

随着我国交通运行规模的不断扩大，各类交通信息设备广泛应用，各类视频、图像、语音等高存储密度数据不断生成，交通运行数据不断呈现出大数据属性，交通信息系统也越来越多地面临大数据承载问题。面对巨大的数据量，考虑到单台机器存储能力有限，I/O口性能也无法满足数据集持续增长的需要，故大数据很难通过传统技术存储、管理、分析、使用。交通运行领域所产生的大数据主要为人、车、路、环境等方面的数据源，具体包括车辆运行、车辆检测、道路养护、事故处理、收费、视频检测、GPS、基础设施等方面的数据，交通运行大数据具有数据体量大、类型复杂、更新速度快、价值密度低等特征。

2.3.1 信息采集

基于微服务架构的交通信息化框架，信息采集层位于整个系统最底层，主要进行交通运行数据的采集和获取，不同于传统采集方式，微服务架构提供多样化的交通运行服务，其所采集的数据主要包括静态结构化异构数据和动态非结构化异构数据两大类。前者主要来自不同管理部门的交通数据库；后者则来自交通节点传感器，考虑到传感器形式的多样性，其所采集到的数据信息在时间及空间粒度、数据格式及存储方法等方面均存在一定差异。

采集交通运行信息的主要目的在于对道路运行状况实施监测，分析各个路段及道路交叉口运行状态，预测交通运行趋势等。随着路网建设进程的不断推进，交通运行信息采集方面过去所普遍面临的采集设备覆盖面不足、设备种类缺乏多元化等问题逐步得到解决，道路信息采集设备覆盖面越来越广泛、采集来源也更加多元化。多元化的信息来源所引起的数据异构化问题可以通过分类、归纳信息来源，拆分模块，并通过不同微服务独立承接、存储数据的处理技术予以解决[3]。数据承载量不大的交通运行数据可以通过传统数据库，根据数据类型选择关系型/非关系型数据库，并结合硬盘raid以保证数据安全。数据承载量较大的交通运行数据，则应通过由低成本机器集群所构成的大容量、高容错能力的分布式文件系统存储，例如应用较为广泛的HDFS分布式文件存储系统等。

2.3.2 信息处理及发布

基于微服务架构的交通信息化框架中，交通信息处理是最核心业务层，该层主要根据服务需求对所采集到的异构数据集成化处理，同时执行数据发布层所提出的查询请求。

进行交通运行信息处理时，主要根据业务场景及数据类型进行微服务拆分，并在微服务间预留接口便于调用。考虑到交通运行数据体量巨大、完成计算任务消耗资源多，故采用基于内存计算的Spark增量流处理框架，同时针对不同业务场景开发不同的微服务，构建起交通运行数据处理微服务群。

交通运行系统处理的最后环节是信息发布，具体包括推送和请求两种方式。推送主要指将信息推进消息队列，并对订阅用户终端实时发送；请求则是通过客户端向服务端API发送资源请求，经过合法性验证后从服务端向客户端发送数据。

2.4 微服务集群部署

将单体服务拆分成微服务后，内部耦合性降低，可扩展性明显增强，实例数量也因此从单个扩展成多个，项目部署及启动面临的挑战也因此增大，为此，交通信息化微服务集群部署必须引入容器化方法。Docker开源项目能够提供系统方式以利于可移植容器内Linux程序的自动化部署，其内核及应用程序的API实现了LXC的扩展，能保证CPU、内存及I/O、网络等API的独立运行。此外，Docker还能通过名称空间将进程树、用户ID、网络及文件系统等应用程序对底层操作环境的视图完全隔离。在进行交通信息化微服务集群部署时，通过Docker将各微服务打包成独立运行容器，借助Docker-compose进行其镜像间依赖关系的描述，并通过统一入口一键启动微服务集群，还能在确保后端微服务协调调用的情况下将对外提供服务端口映射至物理机端口，达到对外隐藏端口及保证微服务集群安全的效果。

3 结语

综上所述，交通信息化是未来交通运行管理发展的必然趋势，当前交通信息系统单体式结构主要存在复杂程度高、交付效率低、可靠性和可扩展性不足、维护难度高等技术难题，基于微服务的交通信息系统架构是解决当前单体结构问题的可行之策，该系统架构主要面临交通信息收集、处理及发布等方面的微服务业务优化方案。实践证明，采用分立的微服务承接、持久化处理不同类型的交通运行信息数据，并通过专门的微服务发布，能有效解决传统单体式架构存在的弊端，提升交通运行数据信息处理效率，推进交通信息化的发展。