系统设计通用模块
1.1.1 系统非功能需求
1.1.1.1 系统可靠性
“xxxx项目”采用数据集中处理模式，业务覆盖养护管理各层级，系统可用性要求较高，要求信息系统7×24 小时连续运行；系统的可用性（A=MTBF（平均无故障工作时间）/（MTBF+MTTR（平均维修时间））×100%）至少为99.99%。
公路交通应急装备物资管理信息系统实现全天候运行维护保障制度，具备7×24小时的系统保障能力，并派驻现场值班人员进行现场7×24小时安全保障。
1.1.1.2 系统响应时间
根据项目心理学的相关理论，考虑到不同类型用户对响应时间的忍耐程度，结合业务对系统响应时间的要求，数据统计、决策分析等功能，简单分析平均响应时间一般不超过3秒；复杂查询平均响应时间一般不超过5秒；信息检索、数据录入、业务流程操作等功能操作，简单功能操作平均响应时间一般不超过1秒，复杂功能操作平均响应时间一般不超过2秒。系统CPU平均利用率不超过70%，内存平均使用率不超过80%。
1.1.1.3 系统存储能力
根据国家、行业的对业务数据存储的最低要求，考虑业务系统生命周期通常为5年，确定本次项目业务数据存储5年，备份存期5年。
1.1.1.4 系统兼容性和可扩展性
随着公路管理体制从管理型向服务型转化，公路事业发展势必出现新的管理需求，因此在系统设计开发过程中，应采用模块化设计理念，避免今后由于新增功能导致重新开发。
硬件设备不但要考虑到和现有设备的兼容，还应考虑到今后公路网扩展、车
辆保有量的增加、流动监测站以及巡查人员单兵设备接入的需要，服务器、交换机、存储备份设备以及网络带宽应具备一定的超前性和兼容性。
本项目的页面在设计实现时，需要考虑采用多种浏览器兼容的网页设计技术，保障网站页面支持各种操作系统和多种浏览器在浏览时的无障碍。需要考虑和适配现在多种系统的不同浏览器如IE、360、谷歌等。
1.1.1.5 系统易用性
根据不同层级的用户的管理需求，提供不同的界面。APP应与PC协同工作，优化软件界面、操作逻辑保证软件运行速度。
系统应提供友好的人机操作界面，系统设计应以用户为中心，符合不同类型的用户角固有的管理和使用习惯，能使用户以较快的速度到自己最关注的功能操作和数据信息，方便用户学习和掌握，提高系统使用效率。
1.1.2 项目建设技术路线
1.1.
2.1 微服务架构技术路线
SOA去中心化的实现方式的根本诉求是扩展性，实现方式就是微服务。微服务架构为所有业务系统服务提供统一管理，包括服务注册、服务配置、断路器、链路追踪、日志分析、消息队列等。特别是在异常服务的监控、访问限流、服务故障熔断方面，能有效提升系统的稳定性和可用性，有效解决当前单点故障导致整个系统崩溃的问题。微服务具体技术选型如下：微服务中间件：Spring Cloud Nacos、Sentinel、Sleuth、RocketMQ、ES、Kibana、Logstash。
微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以
实现对解决方案的解耦。从本质上说其实就是分布式架构，与其说是一种新架构，不如说是一种微服务架构风格。
简单来说，微服务架构风格是要开发一种由多个小服务组成的应用。每个服务运行于独立的进程，并且采用轻量级交互。多数情况下是一个HTTP的资源API。这些服务具备独立业务能力并可以通过自动化部署方式独立部署。这种风格使最小化集中管理，从而可以使用多种不同的编程语言和数据存储技术。
实现微服务技术架构，现有产品需要进行技术上的改进以及相关配套服务的实现，采用分阶段实施、以及试点产品优先实施的策略，主要包括如下：
⏹技术上的改进：
1、前后端分离，web前端通过Http/Https协议调用微服务的API网关，由API网关再经过路由服务调用相应的微服务
2、不同微服务之间通过REST方式互相调用
3、微服务之间通过消息中间件实现消息交互机制
⏹配套服务与功能实现：
1、需要进行相应的自动化服务实现，包括自动化构建、自动化安装部署、自动化测试、自动化平台发布（Docker实现）
2、管理服务，对于微服务架构，必须配套相应的监控与管理服务、日志管理服务等
3、协作服务，运用DevOps思想提升开发、测试、运维的高效沟通与协作，实现开发与运维的一体化
在微服务治理体系下，各个微服务交付期间也是各自独立交付的，从而使得每个微服务从开发到交付整条链路上都是独立进行，这大大加快了微服务的迭代和交付效率。服务交付之后需要部署运行，对微服
务来说，它们运行期间也是各自独立的。实现基于微服务的技术架构，并采用业务流程管理BPM、单点登录SSO、商业智能BI等成熟、先进的技术，构建一个架构灵活、功能实用、界面友好、便于扩展、安全可靠的公路事业发展综合管理平台。
1.1.
2.2 应用系统层技术路线
业务应用层的设计应服从于目标架构与业务架构，有利于各项业务功能的实现；业务应用层要基于统一支撑平台建设，应采用构件的设计方法，便于功能的复用；业务应用层应注重考虑使用便捷、协同快捷、功能人性化等方面因素。
基于目前各业务单位应用系统建设现状，新建业务应用系统统一采用微服务柔性敏捷开发技术路线；已建系统升级改造时应综合评估，具备条件的应用系统应统一过渡至微服务技术架构。
1.1.
2.2.1 业务应用层建设基本要求
（1）业务应用层的建设要基于统一的网络基础设施、数据环境、应用支撑平台开发部署部门业务系统，充分利用支撑层资源。
（2）开放与政务信息共享平台的互操作接口，满足信息交换和业务协同需要。
（3）严格按照标准组织建设；结合项目建设应用需要，完善制定相关标准；支持开放标准，开发开放支持互操作的标准接口，确保互联互通和集成应用。
1.1.
2.2.2 业务应用层建设规范
（1）业务应用层应采用成熟的、通用的技术进行建设，以便于应用系统与统一支撑平台联通，以及各部门应用系统之间协同。
（2）业务应用层在设计建设时应充分复用服务构件库所提供的服务构件，对于服务构件库已经提供的服务构件不得再自行建设，服务构件未能完全满足的功能需求应向统一支撑平台提交需求，由统一支撑平台完善服务构件功能。
（3）统筹全系统的业务需求，充分考虑基层应用需求，统一开发全系统都能够使用的应用软件，避免基层单位重复开发应用系统。
1.1.
2.2.3 应用系统整合技术路线
对目前已建、在建的各类普通公路行业应用系统进行整合，实现统一应用；实现统一的用户管理、权限管理、身份认证、审计管理、单点登录以及信息综合展示。其中，公路事业发展综合管理门户可在计算机、显示大屏、移动设备等终
端上展现和访问，实现“三屏合一”。
（1）功能整合
微服务项目技术架构
——已建系统基于统一用户管理实现基于某一用户的功能整合；
——新建系统基于统一的微服务、数据中台等技术规范进行功能服务开发。
（2）统一用户管理
建立统一用户管理平台，对接公内外网统一身份认证系统，实现对市xxxxx 单位内部组织机构信息、用户信息、角信息的统一管理。
（3）统一授权管理
根据不同业务功能的访问要求，通过平台可为用户分配相应角和权限，所有用户须经过授权才可以访问业务系统和功能。
（4）统一认证管理
集中管理用户帐号和相关审批、操作流程，实现“组织-用户-角-权限”的统一管理，为实现“单点访问权限授权、多点使用权限授权和一点清权”提供基础，所有用户登入平台都须通过统一认证才能够办理相关业务。
（5）统一审计管理
对平台用户使用平台的过程进行全生命周期的管理，所有用户操作都应有日志记录，留迹存痕。
（6）统一界面展现
为市xxxxx单位人员等提供统一的门户展现界面，实现统一访问入口、统一菜单展现、统一工作台栏目和综合信息展示发布等功能。
公路事业发展综合管理统一访除可以计算机上访问外，还可在路网指挥中心大屏幕和移动设备上进行访问。
1.1.
2.3 应用支撑层技术路线
1.1.
2.
3.1 服务接口技术路线
应用支撑层是是整体系统建设核心。沿用WebService技术来定义数据库元数据，使用基于XML 的消息处理作为基本的数据通信方式，以解决使用不同组件模型、操作系统和编程语言的系统之间存在的差异。建议采用的技术路线归纳如下：
（1）采用多层架构的B/S结构；
（2）采用Web Service技术；