智慧交通产品总体解决方案交通信息资源平台.docx
《智慧交通产品总体解决方案交通信息资源平台.docx》由会员分享，可在线阅读，更多相关《智慧交通产品总体解决方案交通信息资源平台.docx（17页珍藏版）》请在冰豆网上搜索。
智慧交通产品总体解决方案交通信息资源平台
智慧交通产品总体解决方案-交通信息资源平台
智慧交通产品解决方案
交通信息资源平台
【面向城市交通】
针对交管平台专门打造的地理信息应用系统，以公安网为基础，以警用电子地图为核心，以地理信息技术为支撑，对空间地理数据进行可视化展现及空间数据分析，为核心业务平台提供基础支撑。
3）交通信息服务平台
为公安交管用户提供面向公众的交通信息服务，实现交通信息采、编、审、发，通过诱导屏、微信、微博等方式对外发布。
4）交通运维管理平台
作为交通技术服务部门提供运维管理工具，通过设备管理、设施管理、警力资源管理、应用运行监测和系统管理等手段有效管理交通设备、应用系统和警力资源，提高智能交通系统的整体运行效率。
5）交通信息资源平台
交通信息资源平台为应用系统提供统一的数据采集和传输服务，支撑跨单位间按需信息交换与共享。
实现多种类型的数据采集，可靠、快速、安全地数据传输，多种类型的数据交换等一系列的功能和非功能性需求，从而实现互连互通、数据共享。
1.1.交通信息资源平台
1.1.1.平台概述
交通信息资源平台是智慧交通管理系统的关键支撑平台，为其它应用系统提供统一的数据采集和传输服务，支撑跨单位间信息交换与共享。
同时交通信息资源平台也是服务共享的统一支撑平台，所有应用的业务功能以及统一消息平台等公共功能都以标准化的服务形式集成到云中心，供其它应用共享使用并对交换平台的运行情况进行监控，对外提供标准的数据规范和交换接口。
1.1.2.平台特点
1．数据标准化
平台设计遵循相关国家标准、部颁标准、行业标准及企业标准，并对所有的交通设备数据进行了标准化定义，向下兼容各种格式数据，向上标准化输出给应用系统。
2．设备访问标准化
平台具备统一标准接口，屏蔽了不同厂家的硬件差异和技术差异，通过协议转换方式，将设备访问与控制标准化、透明化，降低技术门槛。
3．资源访问服务化
平台对数据资源与设备资源全部进行了服务化，其他平台与业务系统对设备与资源的访问一律采用服务调用方式，从而降低了耦合度与复杂度。
4．海量数据处理与挖掘
系统采用了大数据、云计算架构，可支持百万级并发访问、秒级响应及在线扩容，内置各种交通业务模型与算法，看借助平台的大数据分析能力进行数据深入挖掘。
5．数据高安全性
平台中的所有数据采用冗余存储机制，可自动复制、分散存储，对其中的重要数据实现了加密存储。
1.1.3.平台结构
1.1.3.1逻辑结构
逻辑结构图
1.1.3.2物理结构
物理结构图
1.1.4.平台功能
1.1.4.1专题访问服务
专题访问服务是对交通数据的常规访问场景的通用访问方式，屏蔽了数据存储位置、方式等底层信息，提供出通用服务接口形式，供业务系统调用。
1.1.4.2设备访问服务
设备访问服务是对常用交通设备的常规访问场景进行了概括与综合，定义了统一的访问方式，屏蔽了设备型号、版本、厂家等硬件信息，提供出通用服务接口形式，供业务系统调用。
1.1.4.3安全审计服务
安全审计服务提供了日志的读、写、存储、统计分析等功能，统一管理业务系统的业务日志信息。
1.1.4.4数据访问服务
数据访问服务提供了通用的关系数据、海量数据、内存数据的读、写服务接口，供业务系统调用。
1.1.4.5服务调度总线
服务调度总线提供了服务的注册、管理、监控、通讯机制，统一管理交通资源信息平台和应用系统的服务。
1.1.4.6消息通讯总线
消息通讯总线提供了统一的消息格式、通讯机制，统一管理交通资源信息平台和应用系统之间的消息通讯。
1.1.4.7数据与设备适配
数据与设备适配模块根据交通信息资源平台的接口定义针对不同厂家、不同硬件、数据进行适配，转化为标准设备、数据格式。
1.1.5.基础环境架构设计
1.1.5.1云计算基础架构
对上述交通信息资源云中心的总体逻辑架构中的云计算基础层进行分析，扩展设计出以下“流式实时分布式—并行计算处理架构”，如下图所示：
交通信息资源平台处理架构图
根据目前城市交通业务管理需求，构建分布式大数据存储与高并发流数据处理云中心，其平台结构如上述图所示。
交通信息资源云平台采用分布式大数据存储与高并发流数据处理，云平台对海量交通业务数据进行处理工作；数据处理分析平台采用分布式架构部署到相应需求数量的节点服务器集群上，综合利用每台服务器的存储和计算资源，实现对海量数据的管理与挖掘分析等功能。
同时数据处理云中心的扩展能力非常强大，当应用层需要更多的资源时，能够通过增加物理机器和节点即可以轻而易举地实现在线热扩展功能。
分布式大数据存储与高并发流数据处理云中心主要由分布式文件系统、分布式数据库、流式实时分布式计算框架、并行计算框架以及集群管理组件构成。
通过分布式数据库和分布式文件系统对交通数据数据库存储系统导出的文本数据进行全量存储；
分布式文件系统通常是由基于客户机/服务器模式构成；服务器端由主管理服务器（主管理节点）、备用管理服务器（备用节点）以及多个计算节点服务器组成的计算资源池构成。
其中，主管理服务器提供元数据存取、备用管理服务器为主管理服务器提供冗余保护、计算节点服务器存储数据块，用于具体文件块的存取。
根据上图分析其中主管理服务器节点的主要功能如下：
1）元数据管理
管理整个集群的文件系统命名空间、所有文件以及目录的元数据，这些信息以图片和文本文件方式存储于节点的本地磁盘中，在集群运行时，主管理节点加载这两个文件，在内存中构建一个完整的文件树；当元数据更新时，主管理节点将更新数据写入磁盘中。
2）文件块管理
管理并保存每个文件的数据块分布状况，这些信息主要是在主管理节点启动后，根据计算节点的数据块报告汇总生成。
3）故障管理
分布式文件系统通过定期接收计算节点心跳信号与数据块报告，监测节点的可用性，确保计算节点失效后，仍能保证数据的可用性。
4）交互管理
主要包括：
故障切换、信息归并以及信息同步等。
5）容错能力
根据系统故障发生频率的不同，故障大致有下面几种：
硬盘故障、服务器故障、网络故障、存储中心故障（大面积停电、空调事故、断网、自然灾害等）。
硬盘故障比较频繁发生，服务器故障其次，网络故障再次。
分布式文件系统要能通过下列3种方法来规避故障和保证数据完整性：
数据在写入时被同步复制多份，并且可以通过用户自定义的复制策略分布到不同机架的服务器上，保证了在单台甚至单机架服务器故障时，数据也不丢失；
数据在读写时将自动进行数据的校验，一旦发现数据校验错误将重新进行复制；
系统在后台自动连续的检测数据的一致性，并维持数据的副本数量在指定的复制水平上。
6）扩展能力
系统的存储和计算能力能够动态扩充。
在数据处理云中心内部，可以简单地通过增加服务器，在该服务器上安装数据处理云中心软件，然后配置成加入该平台的服务器集群即可。
而其他服务器的配置不去做任何改动。
根据上图分析计算节点服务器的主要功能如下：
1）数据存取
接收主管理节点指令，执行文件数据块的存储、读取、复制，并在本地定期创建子目录以更好地管理各文件数据块，同时将处理结果回写给传统存储环境和交通信息资源云中心存储环境中。
2）定期上报
以心跳的方式周期性地向主管理节点报告自身状态，在计算节点启动时，全自动扫描并生成所有文件块信息，并上报至主管理节点服务器即是数据块报告。
3）数据交互
通过网络通信协议TCP/IP和应用统一接口向终端展示数据处理结果，在与终端交换时，需要分布式文件系统和分布式数据库搭建的分布式云中心具有丰富的对外接口。
分布式的特性是能够利用集群庞大的存储能力，对PB级的数据提供便捷有效的存储管理手段、且适合用于对大文件的处理；通过在不同机器上对同一份数据进行冗余备份来实现可靠性，计算节点之间通过相互通信来转移数据从而使数据分布均衡。
流式实时分布式——并行计算框架是一个用于在城市交通管理海量数据集上解决可分布式——并行化的问题的计算框架，利用多台服务器的计算资源来并行地完成对特定问题的快速处理分析，其主要包括两个功能：
1）由负责统一分配调度的主节点即主管理服务器将输入数据分成若干份并分发到不同计算节点上并发的解决全局问题中它所负责的子问题；
2）利用主管理服务器以特定方式将各计算节点返回的数据处理结果合并得到全局问题的结果，并将结果回写到交通信息数据存储系统中的缉查布控数据库中进行存储；同时通过相关接口展示给业务终端。
1.1.5.2服务调度总线
服务调度总线图
是一个分布式服务框架，提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。
其核心部分包含:
远程通讯:
提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
集群容错:
提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
自动发现:
基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
1.1.5.3分布式内存数据库
是一个key-value存储系统，支持存储的value类型相广泛，包括string（字符串）、list（链表）、set（集合）、zset（sortedset--有序集合）和hash（哈希类型）。
这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。
在此基础上，支持各种不同方式的排序。
为了保证效率，数据都是缓存在内存中。
周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，在此基础上实现了master-slave（主从）同步。
是一个高性能的key-value数据库，专为频繁访问的热数据而设计，提供了多种开发语言支持，目前可以使用的有Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客户端。
支持主从同步。
数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。
可执行单层树复制。
存盘可以有意无意的对数据进行写操作。
由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。
同步对读取操作的可扩展性和数据冗余很有帮助。
1.1.5.4消息通讯总线
1.1.5.4.1.订阅分发式消息队列
该消息系统的核心作用是三点：
解耦，异步和并行。
这种模式有个专业的名词，就叫最终一致。
核心原理
Notify在设计思路上与传统的MQ有一定的不同，核心设计理念是
1.为了消息堆积而设计系统
2.无单点，可自由扩展的设计
为了消息堆积而设计系统在市面上的大部分MQ产品，大部分的核心场景就是点对点的消息传输通道，然后非常激进的使用内存来提升整体的系统性能，这样做虽然标称的tps都能达到很高，但这种设计的思路是很难符合大规模分布式场景的实际需要的。
在实际的分布式场景中，这样的系统会存在着较大的应用场景瓶颈，在后端有大量消费者的前提下，消费者出现问题是个非常常见的情况，而消息系统则必须能够在后端消费不稳定的情况下，仍然能够保证用户写入的正常并且TPS不降，是个非常考验消息系统能力的实际场景。
也因为如此，在Notify的整体设计中，我们最优先考虑的就是消息堆积问题，在目前的设计中我们使用了持久化磁盘的方式，在每次用户发消息到Notify的时候都将消息先落盘，然后再异步的进行消息投递，而没有采用激进的使用内存的方案来加快投递速度。
这种方式，作为整个业务逻辑的核心单元，稳定，安全可靠是系统的核心诉求。
∙无单点，可自由扩展的设计
Notify系统组成结构
上图展示了组成Notify整个生态体系的有五个核心的部分。
发送消息的集群这主要是业务方的机器，这些APP的机器上是没有任何状态信息的，可以随着用户请求量的增加而随时增加或减少业务发送方的机器数量，从而扩大或缩小集群能力。
配置服务器集群（Configserver）这个集群的主要目的是动态的感知应用集群，消息集群机器上线与下线的过程，并及时广播给其他集群。
如当业务接受消息的机器下线时，configserver会感知到机器下线，从而将该机器从目标用户组内踢出，并通知给notifyserver，notifyserver在获取通知后，就可以将已经下线的机器从自己的投递目标列表中删除，这样就可以实现机器的自动上下线扩容了。
消息服务器（NotifyServer）消息服务器，也就是真正承载消息发送与消息接收的服务器，也是一个集群，应用发送消息时可以随机选择一台机器进行消息发送，任意一台server挂掉，系统都可以正常运行。
当需要增加处理能力时，只需要简单地增加notifyServer就可以了
存储（Storage）Notify的存储集群有多种不同的实现方式，以满足不同应用的实际存储需求。
针对消息安全性要求高的应用，我们会选择使用多份落盘的方式存储消息数据，而对于要求吞吐量而不要求消息安全的场景，我们则可以使用内存存储模型的存储。
自然的，所有存储也被设计成了随机无状态写入存储模型以保障可以自由扩展。
消息接收集群业务方用于处理消息的服务器组，上下线机器时候也能够动态的由configserver感知机器上下线的时机，从而可以实现机器自动扩展。
1.1.5.4.2.顺序读取式消息队列
完全的队列模型消息中间件，服务器使用Java语言编写，可在多种软硬件平台上部署。
客户端支持Java、C++编程语言。
结合应用场景对性能的要求，对数据的存储结构进行了全新设计。
在功能层面，增加了更适合海量消息交互的功能点。
整体结构
如上图所示，对外提供的是一个队列服务，内部实现也是完全的队列模型，这里的队列是持久化的磁盘队列，具有非常高的可靠性，并且充分利用了操作系统cache来提高性能。
∙是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式特点。
∙Producer、Consumer、队列都可以分布式。
∙Producer向一些队列轮流发送消息，队列集合称为Topic，Consumer如果做广播消费，则一个consumer实例消费这个Topic对应的所有队列，如果做集群消费，则多个Consumer实例平均消费这个topic对应的队列集合。
∙能够保证严格的消息顺序
∙提供丰富的消息拉取模式
∙高效的订阅者水平扩展能力
∙实时的消息订阅机制
∙亿级消息堆积能力
消息队列存储结构
存储结构是根据海量消息交互应用需求，完全重新设计的一套存储结构，使用这套存储结构可以支持上万的队列模型，并且可以支持消息查询、分布式事务、定时队列等功能，如下图所示。
MetaQ存储体系
单机上万队列
内部大部分功能都靠队列来驱动，那么必须支持足够多的队列，才能更好的满足业务需求，如图所示，可以在单机支持上万队列，这里的队列全部为持久化磁盘方式，从而对IO性能提出了挑战。
∙Message全部写入到一个独立的队列，完全的顺序写
∙Message在文件的位置信息写入到另外的文件，串行方式写。
通过以上方式，既做到数据可靠，又可以支持更多的队列，如下图所示。
图单机上万队列
1.1.6.平台数据存储设计
不同系统的数据上传频率、数据量、数据增长量、数据形式都是不同的，如数据存储和数据计算环境采用一种方式，则必然会出现系统瓶颈，构建数据中心采用单一技术路线无法满足业务需求，因此针对不同数据情况采用传统存储环境和云计算、云存储环境相结合方式。
1.1.6.1传统存储环境设计
传统存储环境，主要以PC服务器+SAN存储方式为主，其中SAN存储通过光纤与服务器进行存储资源关联，数据服务器采用HBA卡，实现共享SAN存储高速读写性能。
1.1.6.1.1.Oracle关系型数据库存储
数据量在千万级以下的结构化数据存储在关系数据库中，设计使用普通X86PC服务器搭建即可，重要业务数据可以考虑放在小型机上，地市级全市的业务数据建议存储在关系数据数据库；考虑系统可用性，建议使用双机热备方式实现系统单点故障时实时切换。
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辆警车、2000手台定位终端，每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.1.6.2云计算和云存储环境
对于符合大数据4V特征的数据，一般为非结构化、半结构化数据或者数据增长较大的业务数据，均需要存储在大数据系统中，使用X86服务器构建服务器群，利用PC服务器的廉价存储构建云存储架构，使用Hadoop技术实现数据分布式存储及云计算功能。
1.1.6.2.1.大数据云计算存储物理架构设计
大数据云计算存储物理架构示意图
1.1.6.2.2.大数据存储大表结构设计
HBase数据表的数据根据行主键被自动切分成多个块（Region），块由数据中心内部的服务器自动分发管理，每个服务器可管理多个块（数百或者数千）。
HBase客户端自动与数据中心通讯，查找ROOT表从而找到分块信息表（META表）的存放位置。
META表记录了行主键区间范围（startkey与分块服务器地址的对应关系。
找到分块服务器后，HBase客户端直接与该服务器进行通讯，进行数据查询或者写入。
1.1.7.平台接口设计
1.1.7.1专题访问接口
专题访问接口目标是将所有交通数据属性化、结构化、标准化，对上层应用提供统一方式、统一标准、便捷化访问。
接口层利用底层的服务调度框架支撑，自动注册、自动负载、压力均衡。
主要包含以下几种数据接口：
机动车通行数据访问接口
六合一数据访问接口（机动车、驾驶员、违章、事故）
GPS数据访问接口
警情数据访问接口
勤务信息访问接口
交通设备信息访问接口
1.1.7.2设备访问接口
设备访问接口目标是屏蔽不同厂家的硬件差异和技术差异，通过协议转换方式，将设备访问与控制标准化、透明化，降低技术门槛。
主要包含以下几类设备接口：
诱导屏接口，下发节目与控制信息
交通信号设备接口
视频接口
大屏控制接口
1.1.7.3安全日志访问接口
日志访问接口目标是全平台日志采集与存储，将安全与操作日志标准化，按系统-模块-功能分级分类存储，提供标准写入与读取接口。
1.1.7.4数据访问接口
数据访问接口提供了通用的关系数据、海量数据、内存数据的读、写服务接口，供业务系统调用。
1.1.7.5适配接入方式设计
适配接口分为被动接口和主动接口两种方式。
1.1.7.5.1.被动接口
由外部系统主动调用写入业务数据的即为被动接口。
被动接口实现简单、可靠性高，可最大限度地降低接入服务复杂度（将复杂度抛给了外部系统），大幅降低了服务端单点故障概率。
同时被动接口配合外部系统的主动推送可以降低数据接入的延时。
建议使用标准的WebService接口、HttpServlet接口等Web服务，以利用Web容器本身的高并发性、高可靠性，特别是Web容器便于进行集群应用与负载均衡。
建议采用基于TCP或UDP协议并符合有关国家与公安行业标准开发接口。
1.1.7.5.2.主动接口
主动调用外部接口抽取数据即为主动接口。
主动接口虽然实现较复杂、可靠性低，并发性能与吞吐量也较低，但具有可控性，尤其利于保障接入数据的完整性和无重复。
建议对于数据完整性要求较高的小数据（即数据量少的业务数据）比如交管信息采用主动接口，即定时主动抽取。
主动接口支持异构接口访问和多协议转换。
升级会员 