上海城市综合监管平台多级数据通信传输机制的设计与实现

2018-06-22刘行国

微型电脑应用 2018年6期

刘行国

(上海三高计算机中心股份有限公司，上海 200092)

0 引言

上海市委、市政府高度重视城市综合管理，全市上下按照“建管并举、重在管理”方针，积极实施环保和建设健康城市3年行动计划，取得了明显成效。但对照新形势下的新要求，当前本市的城市管理还存在着不少疑难顽症和突出矛盾亟待解决。究其深层次的原因，主要在城市管理综合协调性不强，表现在体制上，存在职能交叉、界面不清，以及基层力量薄弱等问题；在管理的每个环节上都不同程度存在不足，在方式上，主要依靠行政管理模式，综合方式运用不够；在手段上，主要依靠传统手段，先进技术运用不够；在管理监督上，除了行业自我监督外，主要是市民投诉、媒体爆光，缺乏主动的、全面的、及时的监督，导致政府管理部门经常处于被动状态。

如何进一步完善特大城市的综合管理，如何建立健全长效管理机制，如何将城市管理与社区建设紧密结合，市建设交通委会同有关部门，在学习借鉴其他城市管理经验，深入调研本市近年来的管理实际，提出应用网格化管理的方式对进行城市综合管理，通过走访部分区政府和相关部门，召开相关单位和部分街道办事处领导会谈，初步形成了上海市开展城市网格化管理的实施方案。

1 多级信息平台的构成

以“两级政府、三级管理、四级网络”为基础，把城市管理的工作重心向街道、社区基层下移，使城市管理运行中的作业、服务和专业管理、综合执法及其监督全部实行网格化，并有机地与社区建设网格化结合；以现代化信息技术为支撑，建立以区为单位，包括部件、事件、作业(服务)、管理、执法责任单位、工作流程在内的城市综合管理监督、指挥平台；在各区的平台基础上，建立全市的综合监督、分析统计平台，以此推动城市管理各行业的改革，进一步转变政府部门职能，切实提高城市管理的水平。

建立全市统一的基础管理数据库，统一编码规则、统一数据版本发布管理；市级平台对由各区执行的部件、事件处理过程进行监管；统计分析城市管理范围内的部件、事件发生数据，为领导决策提供依据；充分利用12319城建服务热线平台，受理市民反映的问题，将市民反映的属网格化管理的内容移送到各区平台进行处理；建立大屏监控系统，直观显示城市管理相关地图信息、案卷信息和相关详细信息等全局情况。

建立区级城市管理监督平台和指挥调度派遣平台，指挥调度派遣平台根据城市管理监督平台传送的信息，统筹协调调度相关专业管理部门，及时处理城市管理中发生的各种问题。城市管理监督平台是城市管理问题信息的发现中心、监控中心和分析中心，通过本区直属的城市管理监督员对网格内发现问题的信息报告，及时掌握城市管理现状、产生的问题和处理结果，对全区的城市管理实现全方位、全时段的即时监控；形成区、街道、社区、单元网格四个层次的发现、处置、解决问题的机制，实现分级、分层管理；建立城市网格化管理基础信息系统的动态维护机制和技术途径；为区拓展网格化管理范围和领域预留空间。

2 涉及的关键技术

建设上海市的多级数据通信的综合监管分析平台，需要选择多种先进技术，其中多个平台和数据库的通信方式是设计中的难点之一，在平台的建设中怎么样保持数据库的稳定以及通信连接的实时性和稳定性是设计中的重点。

2.1 平台数据库的选择

在建立数据库的时候，必须要考虑到与实际平台的联系。使用已有的数据库可以保证对已经积累的技术成果进行重用，从而减少开发的成本和风险。同时还必须考虑到平台的时间成本，对于上海这样的国际化大都市来说，越早建设多级数据通信的综合监管分析平台可以越早地帮助市民解决问题。以最小的时间成本、最小的技术风险对产品进行实现，从而推向使用。

下面是应考虑的几个问题：

1)已有的数据库技术是否已经被淘汰，或者厂商已经不再维护该技术。

2)已有的数据库技术是否可以满足产品的需求。

3)旧有的技术架构和代码是否存在非常大的问题，导致已有产品质量不佳、稳定性较差。

通过对现有的数据库比对发现传统的SQL数据库(MySQL, SQL Server, Oracle)适用于存储业务模型数据。当业务模型比较确定、变化程度较小，对可扩展性的要求也不高的情况下，使用SQL数据库较为合适，因此在上海市的多级数据通信的综合监管分析平台使用的是SQL数据库。

2.2 Web Service通信方式

Web Service是平台独立的Web应用程序，具有低耦合、自包含、可编程的特点。使用开放的XML语言描述、发布、发现、协调和配置这些应用程序，适用于开发分布式、互操作的应用程序[1]。由于Web Service技术平台独立性，特别适用于在不同信息平台之间交换数据。在开发此类应用程序时，运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件，就可相互交换数据或集成。Web Service基于XML、HTTP等常规协议标准，在平台之间数据交换的接口定义方面也很方便实用，程序部署方便，使得多个不同组织之间的业务流程的集成变得相对容易实现[2]。

Web Services使用的两种技术分别为XML语言和SOAP。XML是在web上传送结构化数据的方式，Web Services以一种可靠的自动的方式操作数据，HTML难以满足要求，而XML可以使Web services十分方便的处理数据[3]。SOAP使用XML消息调用远程方法，这样Web Services可以通过HTTP协议的post和get方法与远程机器交互，而且SOAP更加健壮和灵活易用。

2.3 服务器群的负载均衡

当系统面临大量用户访问、负载过高的时候，通常会使用增加服务器数量来进行横向扩展，使用集群和负载均衡提高整个系统的处理能力。

早期一般利用DNS实现负载均衡，就是在DNS服务器配置多个A记录，不同的DNS请求会解析到不同的IP地址。大型网站一般使用DNS作为第一级负载均衡。其缺点是DNS生效时间略长，扩展性差；后期出现了基于IP的负载均衡，早期比较有代表性并且被大量使用的的就是LVS了。原理是LVS在Linux内核态获取到IP报文后，根据特定的负载均衡算法将IP报文转发到整个集群的某台服务器中去。其缺点是LVS的性能依赖Linux内核的网络性能，但Linux内核的网络路径过长导致了大量开销，使得LVS单机性能较低[4]。

当面临大量数据处理的时候，负载均衡的好坏显得至关重要。目前云平台负载均衡中，在技术实现上，国内云提供商UCloud的Vortex与Google Maglev颇为相似。以一台普通性价比的x86 1U服务器为例，Vortex可以实现吞吐量达14M PPS(10G, 64字节线速)，新建连接200k CPS以上，并发连接数达到3000万、10G线速的转发[5]。

为了保证数据处理的及时可靠，本系统选择了Array的硬件负载均衡设备。

在数据交换接口的设计中，不仅考虑到平台与平台之间的通信，还要考虑到平台和市民之间的交互，因此本平台通讯过程中是包含了前端和数据库、前端和电话网等多级的信息连接。为了保证数据传输的正确性，本文中所讲述的平台通信接口由以下几个部分构成：

1)对市民反映问题，统一使用12319城建服务热线电话号码受理。各区平台设置与监管员定向的语音通讯电话。

2)建立市级平台与移动通讯的接口，实现城管监督员手持终端和区级平台的数据通信。

3)建立基础数据交换接口，向区级平台分发基础信息数据，区级平台通过接口上传部件变化数据。

4)建立事件、部件数据交换接口，实现市级和区级平台事件部件处置数据的交换[6]。

3 平台中多级通信的设计

3.1 市、区两级平台的相互关系

如图1所示。

市级平台着重对发现问题的监管及综合分析功能，统一管理基础数据,区级平台着重对发现问题的处理解决。

两者之间的关联在于：

1)对城管监督员发现的问题、市民反映的问题，区级平台向市级平台上报部件、事件的信息收集、案卷建立、任务派遣、核实结案四个环节的数据。

图1 两级平台的相互关系

2)市级平台向区级平台分发基础数据，区级平台向市级平台上报修改的部件数据。

3)区级平台通过市级移动数据、短信接口和本区城市监管员的手机进行数据、短信通讯。

4)市级平台向各区平台下发市民通过12319反映的问题。

两级平台的相互关系，如图1示所示。市级平台框中为其具体应用构成，承担全市网格数据分发汇总、综合分析、数据管理、状态监管等业务功能。区平台中监督受理中心以问题发现、立案、核查、结案为核心内容，处置指挥中心构建以处置职责清晰、处置时限明确和处置结果规范为核心的问题指挥体系。

3.2 Web Service通信技术在多级信息平台中的应用

1、平台之间需要交互的信息

数据接口主要包括移动数据平台与市级平台、市级平台和区级平台之间的接口。

以上接口实现的具体位置，如图2所示。

图2 Web Service通信技术在多级信息平台中的应用

从图2可以看出，数据提供方作为Web Service的服务端，数据获取方作为客户端进行调用、获取数据。例如移动数据平台到市平台的数据传输，由移动平台提供Web Service供市平台调用。

移动数据平台与市级平台之间的接口完成手持移动终端和市级平台数据通信。

市级平台与区级平台之间的接口完成两类功能：第一、接收手持移动终端上报信息并向区平台转发，转发区平台向手持移动终端下达的信息和数据；第二、收集区级平台在案件处理过程中发现、立案、派遣、结案四个环节的数据。

移动数据平台与市级平台之间的接口、市级平台与区级平台之间的接口中数据转发功能的实现方式是完全一致的，市级平台以背靠背的方式实现数据的转发，在以下描述中统称为手持移动终端信息分发接口。

2、实现方法

本系统用于实现市、区两级城管平台间的问题基本信息和动态信息的信息交换功能。

本系统采用业界成熟的XML、SOAP、WebService等信息技术建立信息交换平台，包括数据交换引擎、远程数据传输、信息交换标准等核心模块[7]。

随着XML的迅速发展，XML正在逐步成为Internet中描述数据的标准。在将来XML文档势必成为电子政务中数据传输的主要载体[8]。

3.2.1 消息打包格式设计

消息打包基于SOAP和SOAP with Attachment协议，所有通过信息交换的消息都必须符合SOAP和SOAP with Attachment协议。对审批消息提供基于SOAP with Attachment协议的格式扩展，所有审批消息需按照审批消息打包格式打包。凡是打包格式符合SOAP和SOAP with Attachment协议的消息可通过信息交换平台进行传输。

3.2.2 审批消息打包格式设计

审批消息在逻辑上分为消息头、消息体和附件三部分，每个审批消息有且只有一个消息头，有且只有一个消息体，但可以有0到多个附件。

消息头为一个XML文档，其格式，如表1所示。

表1 消息头为一个XML格式表

消息体为一个XML文档，其格式在消息打包规范中不做约束，但是审批消息的消息体格式在业务规范中有定义[9]。

审批消息的附件部分可以为任意文件，消息打包规范中对所有作为附件文件都看作是二进制文件，不对文件类型进行区分。

审批消息的三部分按照SOAP和SOAP with Attachment协议进行组织，分别映射到SOAP消息的SOAP Header、SOAP Body和SOAP Attachment部分，如图3所示。

图3 审批消息包

消息头部分映射至SOAP消息的SOAP Header部分，并将XML字段加上前缀，mustUndersand置为“1”确保“平台编码”等重要信息被接收方处理，actor属性置为“sppt”标明消息正确的接收者，如表2所示。

表2 消息头

消息体部分映射至SOAP消息的SOAP Body部分，并将XML字段加上前缀，如表3所示。

表3 消息体

SOAP Body元素中包含打算传送到消息最终端点的实际SOAP消息。请注意，上面的sppt:SN和Timestamp元素是平台应用专用的元素,它们并不是SOAP标准的一部分，用于封装具体的消息内容。

每个附件都以MIME边界(由MIME头的Context-Type参数的boundary子参数定义)分隔。每个附件都有说明信息，比如Context-Type(它指定嵌入数据的类型)、Content Transfer-encoding(用于标明数据的编码)、Content-ID(作为引用附件的标识符)。

消息附件部分映射至SOAP消息的SOAP Attachment部分，在消息体部分引用消息附件采用Content-ID形式，如图4所示。