智慧交通产品总体解决专业方案交通信息资源平台.docx

智慧交通产品处理方案

交通信息资源平台

【面向城市交通】

目 录
1.1. 概述 2
1.2. 交通信息资源平台 4
1.2.1. 平台概述 4
1.2.2. 平台特点 4
1.2.3. 平台结构 5
1.2.4. 平台功效 6
1.2.5. 基础环境架构设计 7
1.2.6. 平台数据存放设计 17
1.2.7. 平台接口设计 20

1.1. 概述
我企业在用户需求基础上，经过对城市公安交通指挥系统各技术子系统功效进行梳理、分类，依据GA/T445-　《公安交通指挥系统建设技术规范》、GAT1146-《公安交通集成指挥平台结构和功效》要求功效和我企业自行拓展功效，将城市公安交通管理业务应用划分为五大关键平台，即智能交通管控平台、交通信息服务平台、交通运维管理平台、交通地理信息平台和交通信息资源平台，以下表所表示：
表 Error! No text of specified style in document.1关键业务平台及功效
序号
功效
业务平台
1
监视道路交通情况
智能交通管控平台

日常组织和管控，指挥、协调交通安全保卫工作
2
应急指挥调度、组织协调、决议支持和实施监督
3
城市内多级公安交通指挥系统协调控制
4
GIS基础显示、GIS基础操作、GIS基础编辑和GIS地图查询功效
交通地理信息平台
5
地图元素统计、地图打印输出、地图定位、地图切割等
6
将交通设备设施、交通状态、交通路径等在GIS地图上进行标绘
7
采集公安交通管理信息
交通信息服务平台
8
公布道路交通管理信息
9
管理交通设备设施
交通运维管理平台
10
系统应用运维监测
11
配置警力资源，实施警务考评
12
用户权限管理、数据字典及系统参数管理等
13
交通信息采集、存放、分析、交换
交通信息资源平台
1）智能交通管控平台
作为公安交通指挥中心关键应用平台，以总队、支队、大队、路面岗勤为主用户群，以城市交通情况监测、交通日常管控、突发事件处理为关键业务，经过交通信息资源云中心对接交互，为指挥中心、科室、路面等各角色提供各类应用业务平台。
2）交通地理信息平台
针对交管平台专门打造地理信息应用系统，以公安网为基础，以警用电子地图为关键，以地理信息技术为支撑，对空间地理数据进行可视化展现及空间数据分析，为关键业务平台提供基础支撑。
3）交通信息服务平台
为公安交管用户提供面向公众交通信息服务，实现交通信息采、编、审、发，经过诱导屏、微信、微博等方法对外公布。
4）交通运维管理平台
作为交通技术服务部门提供运维管理工具，经过设备管理、设施管理、警力资源管理、应用运行监测和系统管理等手段有效管理交通设备、应用系统和警力资源，提升智能交通系统整体运行效率。
5）交通信息资源平台
交通信息资源平台为应用系统提供统一数据采集和传输服务，支撑跨单位间按需信息交换和共享。实现多个类型数据采集，可靠、快速、安全地数据传输，多个类型数据交换等一系列功效和非功效性需求，从而实现互连互通、数据共享。
1.2. 交通信息资源平台
1.2.1. 平台概述
交通信息资源平台是智慧交通管理系统关键支撑平台，为其它应用系统提供统一数据采集和传输服务，支撑跨单位间信息交换和共享。同时交通信息资源平台也是服务共享统一支撑平台，全部应用业务功效和统一消息平台等公共功效全部以标准化服务形式集成到云中心，供其它应用共享使用并对交换平台运行情况进行监控，对外提供标准数据规范和交换接口。
1.2.2. 平台特点
1．数据标准化
平台设计遵照相关国家标准、部颁标准、行业标准及企业标准，并对全部交通设备数据进行了标准化定义，向下兼容多种格式数据，向上标准化输出给应用系统。
2．设备访问标准化
平台含有统一标准接口，屏蔽了不一样厂家硬件差异和技术差异，经过协议转换方法，将设备访问和控制标准化、透明化，降低技术门槛。
3．资源访问服务化
平台对数据资源和设备资源全部进行了服务化，其它平台和业务系统对设备和资源访问一律采取服务调用方法，从而降低了耦合度和复杂度。
4．海量数据处理和挖掘
系统采取了大数据、云计算架构，可支持百万级并发访问、秒级响应及在线扩容，内置多种交通业务模型和算法，看借助平台大数据分析能力进行数据深入挖掘。
5．数据高安全性
平台中全部数据采取冗余存放机制，可自动复制、分散存放，对其中关键数据实现了加密存放。
1.2.3. 平台结构
1.2.3.1 逻辑结构

逻辑结构图
1.2.3.2 物理结构

物理结构图
1.2.4. 平台功效

1.2.4.1 专题访问服务
专题访问服务是对交通数据常规访问场景通用访问方法，屏蔽了数据存放位置、方法等底层信息，提供出通用服务接口形式，供业务系统调用。
1.2.4.2 设备访问服务
设备访问服务是对常见交通设备常规访问场景进行了概括和综合，定义了统一访问方法，屏蔽了设备型号、版本、厂家等硬件信息，提供出通用服务接口形式，供业务系统调用。
1.2.4.3 安全审计服务
安全审计服务提供了日志读、写、存放、统计分析等功效，统一管理业务系统业务日志信息。
1.2.4.4 数据访问服务
数据访问服务提供了通用关系数据、海量数据、内存数据读、写服务接口，供业务系统调用。
1.2.4.5 服务调度总线
服务调度总线提供了服务注册、管理、监控、通讯机制，统一管理交通资源信息平台和应用系统服务。
1.2.4.6 消息通讯总线
消息通讯总线提供了统一消息格式、通讯机制，统一管理交通资源信息平台和应用系统之间消息通讯。
1.2.4.7 数据和设备适配
数据和设备适配模块依据交通信息资源平台接口定义针对不一样厂家、不一样硬件、数据进行适配，转化为标准设备、数据格式。
1.2.5. 基础环境架构设计
1.2.5.1 云计算基础架构
对上述交通信息资源云中心总体逻辑架构中云计算基础层进行分析，扩展设计出以下“流式实时分布式—并行计算处理架构”，以下图所表示：

交通信息资源平台处理架构图
依据现在城市交通业务管理需求，构建分布式大数据存放和高并发流数据处理云中心，其平台结构如上述图所表示。
交通信息资源云平台采取分布式大数据存放和高并发流数据处理，云平台对海量交通业务数据进行处理工作；数据处理分析平台采取分布式架构布署到对应需求数量节点服务器集群上，综合利用每台服务器存放和计算资源，实现对海量数据管理和挖掘分析等功效。同时数据处理云中心扩展能力很强大，当应用层需要更多资源时，能够经过增加物理机器和节点即能够轻而易举地实现在线热扩展功效。
分布式大数据存放和高并发流数据处理云中心关键由分布式文件系统、分布式数据库、流式实时分布式计算框架、并行计算框架和集群管理组件组成。
经过分布式数据库和分布式文件系统对交通数据数据库存放系统导出文本数据进行全量存放；
分布式文件系统通常是由基于用户机/服务器模式组成；服务器端由主管理服务器（主管理节点）、备用管理服务器（备用节点）和多个计算节点服务器组成计算资源池组成。其中，主管理服务器提供元数据存取、备用管理服务器为主管理服务器提供冗余保护、计算节点服务器存放数据块，用于具体文件块存取。
依据上图分析其中主管理服务器节点关键功效以下：
1）元数据管理
管理整个集群文件系统命名空间、全部文件和目录元数据，这些信息以图片和文本文件方法存放于节点当地磁盘中，在集群运行时，主管理节点加载这两个文件，在内存中构建一个完整文件树；当元数据更新时，主管理节点将更新数据写入磁盘中。
2）文件块管理
管理并保留每个文件数据块分布情况，这些信息关键是在主管理节点开启后，依据计算节点数据块汇报汇总生成。
3）故障管理
分布式文件系统经过定时接收计算节点心跳信号和数据块汇报，监测节点可用性，确保计算节点失效后，仍能确保数据可用性。
4）交互管理
关键包含：故障切换、信息归并和信息同时等。
5）容错能力
依据系统故障发生频率不一样，故障大致有下面多个：硬盘故障、服务器故障、网络故障、存放中心故障（大面积停电、空调事故、断网、自然灾难等）。
硬盘故障比较频繁发生，服务器故障其次，网络故障再次。分布式文件系统要能经过下列3种方法来规避故障和确保数据完整性：
数据在写入时被同时复制多份，而且能够经过用户自定义复制策略分布到不一样机架服务器上，确保了在单台甚至单机架服务器故障时，数据也不丢失；
数据在读写时将自动进行数据校验，一旦发觉数据校验错误将重新进行复制；
系统在后台自动连续检测数据一致性，并维持数据副本数量在指定复制水平上。
6）扩展能力
系统存放和计算能力能够动态扩充。在数据处理云中心内部，能够简单地经过增加服务器，在该服务器上安装数据处理云中心软件，然后配置成加入该平台服务器集群即可。而其它服务器配置不去做任何改动。
依据上图分析计算节点服务器关键功效以下：
1）数据存取
接收主管理节点指令，实施文件数据块存放、读取、复制，并在当地定时创建子目录以愈加好地管理各文件数据块，同时将处理结果回写给传统存放环境和交通信息资源云中心存放环境中。
2）定时上报
以心跳方法周期性地向主管理节点汇报本身状态，在计算节点开启时，全自动扫描并生成全部文件块信息，并上报至主管理节点服务器即是数据块汇报。
3）数据交互
经过网络通信协议TCP/IP和应用统一接口向终端展示数据处理结果，在和终端交换时，需要分布式文件系统和分布式数据库搭建分布式云中心含有丰富对外接口。
分布式特征是能够利用集群庞大存放能力，对PB级数据提供便捷有效存放管理手段、且适适用于对大文件处理；经过在不一样机器上对同一份数据进行冗余备份来实现可靠性，计算节点之间经过相互通信来转移数据从而使数据分布均衡。
流式实时分布式——并行计算框架是一个用于在城市交通管理海量数据集上处理可分布式——并行化问题计算框架，利用多台服务器计算资源来并行地完成对特定问题快速处理分析，其关键包含两个功效：
1）由负责统一分配调度主节点即主管理服务器将输入数据分成若干份并分发到不一样计算节点上并发处理全局问题中它所负责子问题；
2）利用主管理服务器以特定方法将各计算节点返回数据处理结果合并得到全局问题结果，并将结果回写到交通信息数据存放系统中缉查布控数据库中进行存放；同时经过相关接口展示给业务终端。
1.2.5.2 服务调度总线

服务调度总线图
是一个分布式服务框架，提供高性能和透明化RPC远程服务调用方案，和SOA服务治理方案。
其关键部分包含:
远程通讯: 提供对多个基于长连接NIO框架抽象封装，包含多个线程模型，序列化，和“请求-响应”模式信息交换方法。
集群容错: 提供基于接口方法透明远程过程调用，包含多协议支持，和软负载均衡，失败容错，地址路由，动态配置等集群支持。
自动发觉: 基于注册中心目录服务，使服务消费方能动态查找服务提供方，使地址透明，使服务提供方能够平滑增加或降低机器。
1.2.5.3 分布式内存数据库
是一个key-value存放系统，支持存放value类型相广泛，包含string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。这些数据类型全部支持push/pop、add/remove及取交集并集和差集及更丰富操作，而且这些操作全部是原子性。在此基础上，支持多种不一样方法排序。为了确保效率，数据全部是缓存在内存中。周期性把更新数据写入磁盘或把修改操作写入追加统计文件，在此基础上实现了master-slave(主从)同时。
是一个高性能key-value数据库，专为频繁访问热数据而设计，提供了多个开发语言支持，现在能够使用有Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等用户端。
支持主从同时。数据能够从主服务器向任意数量从服务器上同时，从服务器能够是关联其它从服务器主服务器。可实施单层树复制。存盘能够有意无意对数据进行写操作。因为完全实现了公布/订阅机制，使得从数据库在任何地方同时树时，可订阅一个频道并接收主服务器完整消息公布统计。同时对读取操作可扩展性和数据冗余很有帮助。
1.2.5.4 消息通讯总线
1.2.5.4.1. 订阅分发式消息队列
该消息系统关键作用是三点：解耦，异步和并行。
这种模式有个专业名词，就叫最终一致。
关键原理
Notify在设计思绪上和传统MQ有一定不一样，关键设计理念是
1. 为了消息堆积而设计系统
2. 无单点，可自由扩展设计
为了消息堆积而设计系统在市面上大部分MQ产品，大部分关键场景就是点对点消息传输通道，然后很激进使用内存来提升整体系统性能，这么做即使标称tps全部能达成很高，但这种设计思绪是极难符合大规模分布式场景实际需要。
在实际分布式场景中，这么系统会存在着较大应用场景瓶颈，在后端有大量消费者前提下，消费者出现问题是个很常见情况，而消息系统则必需能够在后端消费不稳定情况下，仍然能够确保用户写入正常而且TPS不降，是个很考验消息系统能力实际场景。
也因为如此，在Notify整体设计中，我们最优先考虑就是消息堆积问题，在现在设计中我们使用了持久化磁盘方法，在每次用户发消息到Notify时候全部将消息先落盘，然后再异步进行消息投递，而没有采取激进使用内存方案来加紧投递速度。
这种方法，作为整个业务逻辑关键单元，稳定，安全可靠是系统关键诉求。
· 无单点，可自由扩展设计
Notify系统组成结构
上图展示了组成Notify整个生态体系有五个关键部分。
发送消息集群这关键是业务方机器，这些APP机器上是没有任何状态信息，能够伴随用户请求量增加而随时增加或降低业务发送方机器数量，从而扩大或缩小集群能力。
配置服务器集群(Config server)这个集群关键目标是动态感知应用集群，消息集群机器上线和下线过程，并立即广播给其它集群。如当业务接收消息机器下线时，config server会感知到机器下线，从而将该机器从目标用户组内踢出，并通知给notify server，notify server 在获取通知后，就能够将已经下线机器从自己投递目标列表中删除，这么就能够实现机器自动上下线扩容了。
消息服务器(Notify Server)消息服务器，也就是真正承载消息发送和消息接收服务器，也是一个集群，应用发送消息时能够随机选择一台机器进行消息发送，任意一台server 挂掉，系统全部能够正常运行。当需要增加处理能力时，只需要简单地增加notify Server就能够了
存放(Storage)Notify存放集群有多个不一样实现方法，以满足不一样应用实际存放需求。针对消息安全性要求高应用，我们会选择使用多份落盘方法存放消息数据，而对于要求吞吐量而不要求消息安全场景，我们则能够使用内存存放模型存放。自然，全部存放也被设计成了随机无状态写入存放模型以保障能够自由扩展。
消息接搜集群业务方用于处理消息服务器组，上下线机器时候也能够动态由config server 感知机器上下线时机，从而能够实现机器自动扩展。
1.2.5.4.2. 次序读取式消息队列
完全队列模型消息中间件，服务器使用Java语言编写，可在多个软硬件平台上布署。用户端支持Java、C++编程语言。
结合应用场景对性能要求，对数据存放结构进行了全新设计。在功效层面，增加了更适合海量消息交互功效点。

整体结构
如上图所表示，对外提供是一个队列服务，内部实现也是完全队列模型，这里队列是持久化磁盘队列，含有很高可靠性，而且充足利用了操作系统cache来提升性能。
· 是一个队列模型消息中间件，含有高性能、高可靠、高实时、分布式特点。
· Producer、Consumer、队列全部能够分布式。
· Producer向部分队列轮番发送消息，队列集合称为Topic，Consumer假如做广播消费，则一个consumer实例消费这个Topic对应全部队列，假如做集群消费，则多个Consumer实例平均消费这个topic对应队列集合。
· 能够确保严格消息次序
· 提供丰富消息拉取模式
· 高效订阅者水平扩展能力
· 实时消息订阅机制
· 亿级消息堆积能力
消息队列存放结构
存放结构是依据海量消息交互应用需求，完全重新设计一套存放结构，使用这套存放结构能够支持上万队列模型，而且能够支持消息查询、分布式事务、定时队列等功效，以下图所表示。
MetaQ存放体系
单机上万队列
内部大部分功效全部靠队列来驱动，那么必需支持足够多队列，才能愈加好满足业务需求，图所表示，能够在单机支持上万队列，这里队列全部为持久化磁盘方法，从而对IO性能提出了挑战。
· Message全部写入到一个独立队列，完全次序写
· Message在文件位置信息写入到另外文件，串行方法写。
经过以上方法，既做到数据可靠，又能够支持更多队列，以下图所表示。
图单机上万队列
1.2.6. 平台数据存放设计
不一样系统数据上传频率、数据量、数据增加量、数据形式全部是不一样，如数据存放和数据计算环境采取一个方法，则肯定会出现系统瓶颈，构建数据中心采取单一技术路线无法满足业务需求，所以针对不一样数据情况采取传统存放环境和云计算、云存放环境相结合方法。
1.2.6.1 传统存放环境设计
传统存放环境，关键以PC服务器+ SAN存放方法为主，其中SAN存放经过光纤和服务器进行存放资源关联，数据服务器采取HBA卡，实现共享SAN存放高速读写性能。
1.2.6.1.1. Oracle关系型数据库存放
数据量在千万级以下结构化数据存放在关系数据库中，设计使用一般X86 PC服务器搭建即可，关键业务数据能够考虑放在小型机上，地市级全市业务数据提议存放在关系数据数据库；考虑系统可用性，提议使用双机热备方法实现系统单点故障时实时切换。
1、交通静态数据容量设计
交通静态数据容量设计表
数据项
单项数据（KB）
目标数量
（个）
数据量（GB）
说明
路网数据
1
50000
0.05

设备数据
1
10000
0.01

设施数据
2
40000
0.08

人员、机构数据
2
10000
0.02

预案数据
5
1000
0.005

累计

0.16

2、交通动态数据及历史数据
交通动态数据及历史数据表
数据类
周期数据量(K）
天天数据量(M）
总数据量（G）
数据计算说明
路况数据
488.28
686.65
1,206.99
全市5000个路段每1分钟存放一次道路通行状态
警情数据
156.25
3.66
6.44
全市每小时平均报警量为200起
指挥调度数据
585.94
13.73
24.14
每起警情全部有对应出警统计数据
警力定位数据
585.94
823.97
289.68
根据全市1000辆警车、手台定位终端，每30秒上传一次数据
交通违法统计数据
2,734.38
2.67
4.69
根据全市天天违法 4000起计算
勤务数据
6,835.94
6.68
11.73
执勤状态描述、执勤排版信息等
设备状态数据
100,000.00
97.66
68.66
5000个设备平均天天20 条
累计

1635
1,612.34

1.2.6.2 云计算和云存放环境
对于符合大数据4V特征数据， 通常为非结构化、半结构化数据或数据增加较大业务数据，均需要存放在大数据系统中，使用X86服务器构建服务器群，利用PC服务器廉价存放构建云存放架构，使用Hadoop技术实现数据分布式存放及云计算功效。
1.2.6.2.1. 大数据云计算存放物理架构设计

大数据云计算存放物理架构示意图
1.2.6.2.2. 大数据存放大表结构设计
HBase 数据表数据依据行主键被自动切分成多个块(Region)，块由数据中心内部服务器 自动分发管理，每个服务器可管理多个块（数百或数千）。HBase 用户端自动和数据中心通讯，查找 ROOT 表从而找到分块信息表(META 表)存放位置。META 表统计了行主键区间 范围(start keyà end key)和分块服务器地址对应关系。找到分块服务器后，HBase 用户端 直接和该服务器进行通讯，进行数据查询或写入。
1.2.7. 平台接口设计
1.2.7.1 专题访问接口
专题访问接口目标是将全部交通数据属性化、结构化、标准化，对上层应用提供统一方法、统一标准、便捷化访问。接口层利用底层服务调度框架支撑，自动注册、自动负载、压力均衡。关键包含以下多个数据接口：

机动车通行数据访问接口
六合一数据访问接口（机动车、驾驶员、违章、事故）
GPS数据访问接口
警情数据访问接口
勤务信息访问接口
交通设备信息访问接口
1.2.7.2 设备访问接口
设备访问接口目标是屏蔽不一样厂家硬件差异和技术差异，经过协议转换方法，将设备访问和控制标准化、透明化，降低技术门槛。关键包含以下几类设备接口：
诱导屏接口，下发节目和控制信息
交通信号设备接口
视频接口
大屏控制接口
1.2.7.3 安全日志访问接口
日志访问接口目标是全平台日志采集和存放，将安全和操作日志标准化，按系统-模块-功效分级分类存放，提供标准写入和读取接口。
1.2.7.4 数据访问接口
数据访问接口提供了通用关系数据、海量数据、内存数据读、写服务接口，供业务系统调用。
1.2.7.5 适配接入方法设计
适配接口分为被动接口和主动接口两种方法。
1.2.7.5.1. 被动接口
由外部系统主动调用写入业务数据即为被动接口。
被动接口实现简单、可靠性高，可最大程度地降低接入服务复杂度（将复杂度抛给了外部系统），大幅降低了服务端单点故障概率。同时被动接口配合外部系统主动推送能够降低数据接入延时。
提议使用标准WebService接口、Http Servlet接口等Web服务，以利用Web容器本身高并发性、高可靠性，尤其是Web容器便于进行集群应用和负载均衡。
提议采取基于TCP或UDP协议并符合相关国家和公安行业标准开发接口。
1.2.7.5.2. 主动接口
主动调用外部接口抽取数据即为主动接口。
主动接口即使实现较复杂、可靠性低，并发性能和吞吐量也较低，但含有可控性，尤其利于保障接入数据完整性和无反复。
提议对于数据完整性要求较高小数据（即数据量少业务数据）比如交管信息采取主动接口，即定时主动抽取。
主动接口支持异构接口访问和多协议转换。