产品设计 | 数字公路综合信息管理平台：单体、微服务融合的几个设计要点？

“ 目前数字公路综合信息管理平台一般采用云边端的方式来设计和建设。在此过程中，我们发现一些业务无法直接上云，整体还需要综合考量，所以采用三级架构与云边端的混合异构方式。”

数字公路综合信息管理平台是实现全省高速公路路网监测预警与应急指挥的综合性平台，其设计之初就是构建一个统一门户，打造成一体化的综合信息管理平台。

目前数字公路综合信息管理平台一般采用云边端的方式来设计和建设。在此过程中，我们发现一些业务无法直接上云，整体设计还需要综合考虑，所以实际业务采用了三级架构与云边端的混合异构方式。

三级架构主要针对时效性特别强的业务系统，例如隧道监控系统，这是需要隧道站/所进行设备管控和应急处置的。

云边端架构可以应用在时效性需求不大的业务系统，例如车辆监测系统、收费稽核系统等等。

在设计的过程中，我们发现微服务架构并不适用于全部三级架构，在第二层和第三层，更适合采用单体应用。

这就决定了综合信息管理平台的异构性，单体应用与微服务同时存在。

传统的web开发方式，所有的功能打包在一个 WAR包里，基本没有外部依赖，部署在一个J2EE容器（Tomcat，JBoss，WebLogic）里，应用内包含了Service、DAO、UI等所有逻辑。这种开发模式称为单体应用(即Monolithic架构，也叫巨石应用)。

单体应用的时候经常设计到两个问题：

一、负载均衡

负载均衡就是将请求均衡地分配到多个系统上。目前常用Nginx&LVS&F5，主要用于同一地点内机器级别的负载均衡。

其中Nginx是软件的7层负载均衡，LVS是内核的4层负载均衡，F5是硬件做4层负载均衡，性能从低到高位Nginx<LVS<F5。

二、session共享

session共享就是用户在A服务器登录，结果查看购物车时，请求发送到了B服务器，因此用户的session存在A服务器上，所以当请求发送到B服务器上时，会认为用户没有登录。目前解决session跨域共享问题有如下几种方式。

• session 定向；
• 将请求都落到同一个服务器上，如Nginx的url hash；
• session 复制；
• 每台服务器都保存一份相同的session；
• session 集中存储；
• 存储在db、 存储在缓存服务器 （redis）；
• cookie (主流)；
• 将信息存在加密后的cookie中；

单体应用的优缺点，不做描述。

在实际应用过程中，尤其是针对路段平台的收费稽核、隧道监控等平台，我们采用单体应用。这些单体应用的平台一般具备如下特性：

1.时效性较强，需要跟前端机电设备进行实时控制，核心控制业务在本地。类似隧道所的隧道监控系统。

2.业务定制化较高，一些无法业务无法标准化，各个路段公司都有自己特性的业务，此类平台也是无法上云标准化的。但目前来看，高速公路的业务业主逐步趋向标准化。

3.基于本地数据资源的统计分析类平台，类似路段收费稽核平台，无法拿到其他路段收费数据的时候，也建议采用单体应用的架构。

微服务是一种用于构建应用的架构方案，也是一种架构风格，有别于传统的单体式方案，是一种以小粒度服务来替代开发单个大而全应用的方法。系统的每个功能都被称为一项微服务，每个微服务仅关注于完成一件任务，并很好地完成该任务。微服务之间是松耦合的，每个微服务运行在自己的进程里，并以轻量级的机制来通信，通常是 HTTP RESTful API。每一个微服务可被独立部署。各项服务在工作（和出现故障）时不会相互影响。

微服务之间的通信-轻量化消息驱动架构模式

消息驱动架构，即使用轻量化消息触发业务处理功能，实现服务间异步调用和解耦。

通常，服务之间通信是基于请求-响应模式构建，REST 就是这种模式的典型，对别的代码模块进行调用，接收到响应后再继续下面的处理流程，这也是微服务的基本特征，即服务双方只依赖于接口。

微服务必备组件

一、注册中心

注册中心可以说是微服务架构中的”通讯录“，它记录了服务和服务地址的映射关系。在分布式架构中，服务会注册到这里，当服务需要调用其它服务时，就这里找到服务的地址，进行调用。

微服务注册中心采用Eureka实现，为SpringCloud框架原生注册中心，集成与开最为方便。

二、API网关

API网关是一个服务器，是系统的唯一入口。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。

API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。

API网关采用Gateway实现，用非阻塞的方式可以利用较小的线程或硬件资源来处理并发进而提高其可伸缩性。

在隧道所、路段级平台，我们采用单体应用架构。

在省级平台，我们采用微服务架构，在具体项目应用中，会发现，微服务的拆分合理性严重影响了系统的运行效率。尤其是在时效性要求高的场景下，经常面临个别非关键服务崩溃导致业务失效的现象。

下面先说说，微服务的设计思路：

一、层间通讯

平台层级之间通信，由数据交换服务完成，数据交换服务可以自己开发。但是在实际应用中，如果一个大型项目，我们的建议还是采用商业的中间件来实现，毕竟稳定性是最主要的。

平台采用多接入设计，各平台除配备本层级的交换服务外，还可接入多个下级平台的交换服务，下级交换服务服务将下级平台收集后，传输和分发至多个上级平台，上由级平台的交换服务接收，完成本层内数据传递。

设备、事件等数据，采用直通方式，传输到中级及上级平台。

业务类、统计类、管控类等需要汇聚、审核类等数据，可在平台层级间传输。

无论何种形态数据，均由数据交换服务进行统一接入和输出，以实现出入口统一。

二、模块间通讯

设备采集服务将设备数据通过HTTP传输到数据交换平台。交换平台将数据进行分类后，投入消息中间件。

消息中间件根据消息类型进行分发。

各业务模块通过基础框架的消息订阅框架，对消息进行订阅，用于驱动该业务模块。

比如情报板模块将订阅情报板类型数据，用于展示情报板实时信息。

业务模块间通信，基于HTTP协议，为方便接口调用，该接口使用Feign进行包装。

三、总体设计

软件系统可分为数据采集层、数据集成层、核心服务层、业务应用层，各层作用如下：

数据采集层：各相关服务采集的数据通过数据接入接口向数据库提供采集数据，采集后存入实时数据库，实时数据库提供数据访问接口。同时采集服务业提供发送数据接口，由核心服务调用，向前端设备发送控制数据。

数据交换层：数据交换平台，是系统内部各组件之间数据传输的枢纽，为外部三方平台提供接入服务，并提供数据存储、分发、堆积、缓冲服务。支持大数据量与大负载系统接入，接口无状态化，便于水平扩容。

核心服务层：核心服务层包括综合业务管理、数据统计分析、视频转发等核心功能服务，通过统一的数据访问接口服务对基础数据和统计数据进行访问，对数据进行查询，显示，修改，统计等操作。

业务应用层：提供访问发布信息接口，以便移动平台，互联网平台能够通过接口获取相关信息，提供WEB应用界面，供操作者完成整个系统功能的使用

高速公路综合信息管理平台的业务看似复杂，并不复杂，主要是数据的凌乱，导致了各个业务的穿插。

在设计的时候，经常各个服务之间互调，导致开发人员逐步崩溃，系统不能持续维护。

根据总体设计，我们基本可以将高速公路综管平台拆分为两大类。

一、系统支撑服务

数据交换服务：具体功能间模块间通信的描述。

日志管理服务：实现操作日志记录，包括各类系统日志、交换日志、操作日志

数据存储服务：包括结构化、非结构化的各类数据存储功能。

消息中心服务：实现各类及时、定时消息的发布及管理。

认证鉴权服务：实现用户认证及鉴权。

服务监控服务：对微服务的监控。

二、高速业务服务

设备管理服务：实现各类设备的管理，包括收费、监控、通信、车路协同等各种设备。

系统管理服务：实现系统的相关配置管理。

视频监控服务：实现视频的拉流、展示及各类操控，由于底层面对海大宇各个厂家的视频平台，从最开始的SDK、API等接入，慢慢走向了GB28181。

信息发布服务：实现广播、情报板、公众号等各类信息发布，尤其是在情报板的发布流程中，个别路段的发布流程比较严格，存在审批流，进而导致服务出现分支，这个原因还是前期需求调研不足和设计欠缺。

监测预警服务：实现各类数据及信息的监测研判及预警，此服务可以再拆分为交通状况监测预警子服务、交通气象监测预警子服务等等。

统计分析服务：实现各类数据的多维统计分析。

数字公路的综管平台如何设计架构，其实各个大的软件开发单位都有自己的宝典。

但是最终交付给客户以后，我们看到，稳定性已经超过了一切需求。

大家在设计的过程中，无法确保高稳定性时，必备的应急平台也是可以临时解决燃眉之急的。