政务信息整合平台.docx

一、目标
以政务信息整合平台为中心，实现各政务部门的信息资源的交换与共享。各政务部门作为资源提供者，通过数据交换为平台提供符合标准规范的政务资源数据，同时，内部和外部的资源用户可以从平台获得标准格式的数据，或者完成数据操作。
资源用户（外部）
数据提供者
政务信息整合平台
工商部门
数据交换
税务部门
公安部门
卫生部门
……
平台管理
开发
管理
监控
资源用户（内部）
工商部门
税务部门
企业单位
……
民间团体
……
税务部门
数据共享
运维

此外，通过政务信息整合平台的实施，还将实现如下目标：
Ø 通过平台的资源目录，实现对信息资源的统一管理，如统一安全管理等。
Ø 通过平台组件的开发及复用，实现对通用业务功能的积累，避免重复开发。
Ø 基于平台的基础架构，保障资源的高可用性，以及基于硬件资源的横向扩展。

二、体系架构
2.1 功能组成
平台功能包括数据交换与共享、资源目录、资源监控三部分。如下图所示：

政务信息整合平台

用户
应用系统

数据交换与共享
资源目录
资源监控
委办局
应用系统
数据交换
数据服务
管理运维

数据交换与共享
实现政务系统内部各种异构应用系统间的数据整合，并对用户应用系统提供统一的标准化的实体数据。例如：人口数据、法人数据、空间地理数据、宏观经济数据等。
其中，数据交换将各资源提供者（各委办局）的异构数据的整合为统一的标准格式的数据；数据共享则以数据服务的形式向资源用户提供数据操作功能。
资源目录
在对资源数据进行统一编目的基础上，实现对信息资源的管理。
数据提供者可将共享数据的信息注册到资源目录中，使用户知道如何使用数据。
数据用户通过查询资源目录，可以知道有哪些信息资源，以及信息资源在哪里、由谁提供等。
资源管理部门可基于资源目录，对信息资源实行统一管理，如统一用户授权，即限定哪些用户可以使用哪些数据，以及允许对数据进行哪些操作等。
资源监控
为平台的运维部门提供平台运行期间的各种监测和控制手段，以保障平台的正常运行。这些手段包括：监测各项资源的访问情况、控制各项资源的访问量、生成各种统计报告等。
2.2 平台组成
管理工具
运行环境
开发工具
数据
交换

作业调度
作业监控
数据
共享
资源
目录
服务管理
服务监控
资源注册
目录管理
ETL配置
数据源配置
ETL引擎
调度引擎

服务容器
日志代理
服务配置
协议配置

从介质上分，平台分为三个组成部分：开发工具、运行环境、管理工具。
开发工具：提供图形化的开发界面，用以完成平台所实现的业务逻辑开发和配置。
可以是离线开发方式或是在线开发方式。
运行环境：提供业务逻辑的运行环境，为基于JVM的后台进程，没有界面。
管理工具：提供对运行环境的运行期管理，提供Web方式的操作界面。同时，提供部署功能，用以将开发工具的开发成果部署到运行环境中运行。
三、数据交换与共享：
3.1 系统组成：
数据交换与共享分为共享库、ESB（企业服务总线）、DI（数据集成）三部分。
数据交换与共享
ESB
用户系统
应用系统（模式2）
DI
共享库
DB
数据服务
应用系统（模式1）
DB
应用系统（模式3）
DB

共享库：
用于集中存储共享数据。
在简单的情况下，可基于常见的关系型数据库，如Oracle、MySQL等。
在特定场合中，可采用NOSQL数据库、内存数据库、文件系统、云存储等。、
DI（数据集成）：
用于实现应用系统数据库与共享库间的数据同步。
DI的核心是ETL引擎，通过执行ETL作业，完成两点间的数据同步。这种数据同步可以是双向的：
Ø 数据上行：即将应用系统的数据变化（增/删/改）同步到更新到共享库。
Ø 数据下行：即将共享库的数据变化（增/删/改）同步到更新到应用系统。
ETL引擎
输
入
源
数据库
转换
（过滤、去重、排序、行列转换、字段合并/拆分……）
输
出
目
数据库

每个ETL作业包含输入、转换、输出三部分功能：
Ø 输入：从源数据库中抽取数据记录。
Ø 转换：对数据记录进行各种加工处理，如：过滤、去重、排序、行列转换、字段合并/拆分等。
Ø 输出：将数据记录更新到目数据库中，可能对应着插入、删除、更改操作。
在复杂的场景下，源和目数据库可以不止一个，此时ETL作业中包含多个输入或输出，并且转换过程也包含了数据流的合并或分支处理。
ETL作业基于组件化开发，利于业务功能的扩展和积累。其中：
Ø 输入/输出组件的开发，可以使数据交换适应不同类型的应用系统数据库和共享库。这些组件可支持：常见的关系型数据库，如Oracle、MySQL、SQL Server、DB2等；各种NOSQL数据库，如MongoDB等；各种文件，如文本文件、XML文件、JSON文件等；以及针对特定数据库的定制化组件。
Ø 转换组件的开发，可以将特定的业务功能独立出来，以便重复使用。这些组件包括：过滤、去重、排序、映射、字段拆分/合并、字串处理、数学计算等，以及针对特定业务功能的定制化组件。
DI包含作业调度机制，使ETL作业按指定的规律运行，如：按指定的时间一次性执行、每天的某个时刻执行、每间隔10分钟执行一次等。
ESB（企业服务总线）：
数据提供者将自己的共享数据以服务的形式注册到ESB上，再由ESB以标准的形式统一对外提供数据服务，实现数据共享。
各种数据提供者可以以不同的形式提供数据服务（如直接访问数据库或提供各种API接口），而经过ESB的转换，给用户提供的将是统一的标准的数据服务（如WebService）。
ESB
接
出
服务编排
（协议转换、数据转换、加密解密、权限校验……）
接
入
数据
用户
数据
提供者

ESB提供的服务实现包括接入、编排、接出三部分：
Ø 接入：基于某种协议为数据用户提供数据服务，如：WebService。
Ø 服务编排：对服务的请求和应答数据进行处理，如：协议转换、数据转换、加密解密、权限校验等。
Ø 接出：基于某种协议访问数据提供者提供的数据服务，如：WebService、JDBC。
在复杂的场景下，服务编排中可能要处理条件分支、循环等逻辑，而且访问的数据提供者可能不只一个。
ESB的服务实现基于组件化开发，利于业务功能的扩展和积累。其中：
Ø 接入/接出组件的开发，可以使平台以不同的方式访问数据提供者，也可以使平台以不同的方式为数据用户提供数据服务。这些组件可支持：WebService、HTTP、JMS、FTP、JDBC、Socket等，以及针对特定协议的定制化组件。
Ø 服务编排组件的开发，可以将特定的业务功能独立出来，以便重复使用。这些功能包括：不同协议间的转换、不同数据格式间的转换、对数据的加密/解密处理、对用户身份的认证及权限校验等，以及针对特定业务功能的定制化组件。
针对数据提供者提供数据的方式不同，可以将数据共享方式分为如下3类：
模式1：ESB直接访问应用系统的数据库。即平台上不保存应用系统数据，而是当数据用户访问ESB的数据服务时，ESB直接（通过JDBC或其他数据库支持的接口）访问应用系统数据库，完成数据操作。
模式2：此模式与模式1类似，不同的是ESB通过应用数据提供的数据服务接口完成数据操作，而不是直接访问应用系统数据库。因此更更保证应用系统数据库的安全，但功能也受此接口的。
模式3：ESB访问共享库中的数据。因此在此模式下，对于上行数据，需事先通过DI将应用系统的共享数据同步到共享库中；对于下行数据，应事后通过DI将共享库中的数据变化同步到应用系统中。
此模式下，在数据用户调用数据服务时，由于ESB访问的是共享库中的缓存数据，而非直接访问应用系统数据库，从而减少了对应用系统的压力。
由于数据同步存在一定延时，对数据用户来说，查询到的数据可能不是实时数据，对数据的更改可能不会立即生效。
另外，由于不同数据提供者的数据集中存储在共享库中，更利于数据的综合处理，例如结合人口信息和法人信息进行查询。
3.2 特性总结：
支持各种异构的应用系统数据源：
基于DI的输入/输出组件和ESB的接出组件，可以支持不同的应用系统以不同的方式提供共享数据，如基于常见的关系型数据库（如Oracle、MySQL、SQL Server、DB2等）、各种NOSQL数据库（如MongoDB等）、各种文件（如文本文件、XML文件、JSON文件等）、基于各种协议的API接口（如WebService、HTTP、JMS、FTP、JDBC、Socket等），以及针对特定数据库/协议接口做定制化开发。
对外统一的数据服务接口：
尽管各种数据提供者可以以不同的形式提供数据服务，但数据用户总是以统一的标准的数据服务（如WebService）完成数据操作，而不必关心数据提供者的差异。
支持复杂的数据清洗、转换处理：
通过DI的ETL流程和ESB的服务编排，可对数据提供者提供的原始数据进行加工处理。例如原数据中的身份证号为15位，在平台的处理过程中可以被自动转换为18位。
某些综合性信息可能需基于多个部门的数据综合处理（如结合人口信息和法人信息），无法由一个部门提供。在DI的ETL流程和ESB的服务编排中，可以访问不同的数据提供者，再经过流程的综合处理，得到综合性结果。
如果数据用户所需的数据，需基于数据提供者提供的原始数据做大量复杂的转换处理后才能得到，可基于模式3，周期性地对应用系统的数据进行预先处理，并将结果保存到共享库中。用户调用数据服务时，ESB直接从共享库中取最新结果，从而使用户尽快得到响应。
四、资源目录
4.1目录结构
元数据
资源元数据描述某项信息资源的特性，以便对信息资源进行管理、查询、使用。
元数据标准可在设计阶段具体确定，通常包括如下内容：
Ø 标识类信息：用于全局唯一标识某项资源，如资源编码等。
Ø 描述类信息：对信息来源、用途、特性等进行描述，以便使用者参考。如提供者的单位名称及负责人联系方式、数据的用途、数据的适用条件等。
Ø 分类及关键字信息：用于该项资源在资源目录中的定位，以及检索效果。
Ø 安全管理信息：描述数据适用的用户范围及权限，加密、校验方式等。
Ø 接口信息：描述为该项资源提供的数据服务的接口信息，包括接口协议、服务地址、输入输出参数等，以便用户通过该服务接口信息实现对数据服务的调用。例如，对于WebService服务，可提供WSDL地址。
Ø 维护状态信息：标识该项资源的使用状态。如正常使用还是暂停使用。
注：可参考《GBT 21063-2007 政务信息资源目录体系国标》中的第3 部分：核心元数据）
目录组织
将各项资源元数据按一定的分类体系组织在一起（通常为分级树状结构），即形成资源目录。基于元数据的分类、关键字及内容，可对目录中的元数据进行检索，从而获得符合条件的资源元数据。进而根据资源元数据的内容，决定是否使用以及如何使用该项资源信息数据。
目录组织的具体方式可在设计阶段确定。
注：可参考《GBT 21063-2007 政务信息资源目录体系国标》中的第4部分：政务信息资源分类。该标准从4个维度对信息资源进行了分类，分别是：
Ø 主题分类：体现了其内容的属性或特征；
Ø 行业分类：体现了政务部门职能的特点；
Ø 服务分类：体现了政务信息资源面向用户提供的功能服务的划分；
Ø 资源形态分类：体现了政务信息的存在形式。
其中主题分类是基础，其余三类作为辅助。
标准中还针对各项分类的分类编码分别制定了标准，并提供了分类示例列表。
4.2目录管理与使用
目录管理功能组成
元数据的注册、注销和修改：
对元数据的管理是目录管理的核心功能。
元数据的注册是指针对一项新的信息资源，生成对应的元数据并添加到资源目录中，从而使数据用户可以从目录中检索到该项元数据。
元数据的注销是指当元数据对应的信息资源不再使用时，从资源目录中删除元数据。
元数据的维护是指当元数据相关的信息资源特性发生变化时，相应更新目录中的元数据内容。
基础数据的管理：
考虑到管理的方便性，针对元数据中的一些公共基础类信息可以单独管理，在元数据中直接引用。当这些基础类信息的变化时，更新基础数据，而不是更新元数据。例如：
Ø 提供者信息 管理提供信息资源的政务部门描述信息，一个元数据必须对应一个提供者，可以直接应用该项信息。
Ø 服务模型信息 描述提供数据服务的接口协议规范。一个元数据对外提供数据服务，必定基于某种协议（如WebService），对服务模型进行统一管理，有助于资源用户根据服务接口查找所需的数据服务。
Ø 分类信息 各分类的描述性信息。出于对元数据检索的需要，一个元数据通常对应一个或多个分类，这些分类通常以统一编号的形式被元数据引用，分类的描述信息则单独统一管理。
元数据的查询：
依据一定的查询条件（元数据名称、分类及其他内容等），从资源目录中检索符合条件的元数据。
权限管理
用户管理：
记录用户详细信息，包括用户名、用户密码、电子邮箱等信息。
可以通过用户组、角色等实现对用户的多层分级管理。
注：人员管理可以考虑和外部权限系统（如OA的权限系统）整合，而不在资源目录系统中保存用户信息。
权限管理：
根据用户、用户组、用户角色，掀动用户对目录的使用权限。
例如，可将用户分为三种角色：资源提供者、资源使用者、目录管理者。针对三类角色的授权为：
Ø 资源提供者：元数据的修改。另外，对元数据的注册和注销，提供者可向管理者提出申请，并提供元数据内容或唯一标识。对于基础类数据，资源提供者只有查询权限，而没有修改权限。
Ø 资源用户：查询元数据及各类基础信息。
Ø 目录管理者：各基础类信息的增加、删除、修改。审核和批准资源提供者的元数据注册和注销请求。

注：可参考《GBT 21063-2007 政务信息资源目录体系国标》中的第2部分：技术要求，其中针对目录管理、查询等操作，详细规定了服务接口规范。
4.3资源目录的实现
制定统一的元数据标准，该标准应符合《GBT 21063-2007 政务信息资源目录体系国标》中的相关规定，但要考虑到针对具体应用可以进行扩展。
目录数据的存储不应依赖特定的存储机制，可以同共享数据一同存储在共享库中，也可以存储在其他存储系统中。
针对目录的管理、查询等操作，平台基于某种形式（如WebService）提供API。该接口与数据服务不同，通常面向平台的应用开发人员，而非直接面向数据的提供者、使用者或管理者。
资源目录
元数据
维护
接口
目录管理接口
目录数据
查询
接口
目录管理工具
元数据
维护
工具
资源
提供者
资源
用户
元数据
维护
工具
目录贵管理者

五、资源监控
5.1 ETL作业管理
功能结构

管理服务器提供作业定义工具。一个作业定义决定了用什么方式执行一个ETL流程，以及如何处理执行结果及执行中的异常等。
作业定义完成后，交给调度服务器调度执行。调度服务器维持一个作业队列，并依据一定调度策略，安排某个作业到某个作业服务器上执行（直接发送到作业服务器上运行或通过代理服务器运行）。同时，调度服务器监听各作业执行过程中的事件（执行结束、异常等），并根据作业中的定义对事件进行处理。
作业定义
作业执行频度：一次性，每分、每时、每日、每周、每月等。
日历：工作日，假日处理。
运维消息：基于特定事件通知运维，邮件、短信。
优先级：高、中、低。
调度服务器：指定由哪个调度服务器调度处理。
作业监控和人工干预
作业状态：
就绪：作业第一次被创建或重置后的状态
等待：作业被调度，但需要等待相关条件准备好（如时间窗、其他依赖作业的完成）
运行：作业正在运行
完成：作业成功完成
失败：作业运行失败
人工干预：
运行：启动作业或作业流，无论什么条件下都可以启动作业流
中断：中断正在运行的作业流
断点重跑：如果作业流状态是失败，可以通过断点续跑，从上次失败的作业开始重跑，已跑作业不会再次运行
重置状态：作业流状态重置为就绪

作业性能统计分析：
针对指定作业，统计运行时长、成功率等，为系统调优提供支持

5.2 服务状态监控
功能结构
监控服务器
ESB

服务
控制
接口
日志汇总
监控数据
统计
分析
控制操作/报表展现
日志
代理

日志监测
监测目标：服务使用者、服务提供者、某一个特定服务、某一组服务。
监测指标：在一定时间段内，服务被访问的次数、平均响应时间、成功率等。
统计分析
统计综合查询：从服务消费者和提供者维度，对运行状况进行统计查询。

接口运行统计：从服务消费者和提供者维度，汇总统计接口间调用情况。

接口运行诊断：对通过调用时长，接口运行进行诊断和分析定位故障。

针对某时间段内服务调用次数变化情况生成的报表：

针对某服务在特定时间段内的调用情况进行统计：

资源调配
针对特定服务，限定所用的并发线程数、连接数、缓存队列大小。
针对某个应用系统的特定接口，限定ESB访问时所用的并发线程数、连接数、缓存队列大小。
六、应用开发与部署
6.1 应用开发
基于图形化开发环境，完成数据交换与共享相关的逻辑定义。这些定义包括：
Ø ETL流程定义（DI）；

Ø 服务定义（ESB）。

开发环境可以是独立的开发工具，也可以是在线开发。
基于开发工具开发的业务模块可以部署到运行环境，或从运行环境中删除。
6.2部署方案
单节点部署：

用户
应用系统

委办局
应用系统
平台
节点

只有一个平台节点。所有提供数据的应用系统通过该节点进行数据整合，所有用户应用系统通过该节点获取数据。
分布式部署：

市级用户
应用系统

市委办局
应用系统
市级
节点
区县1用户
应用系统

区县1委办局
应用系统
区县1
节点

区县2委办局
应用系统
区县2
节点
数据同步 目录同步
统一服务调用 统一监控

区县2用户
应用系统

多个平台节点。除了每个节点独立实现数据交换与共享、资源目录、资源监控外，还通过节点间的交互机制，整体上形成统一的信息整合。这些交互机制包括：
Ø 数据同步：某个节点将自己的共享数据同步到其他节点。
Ø 目录同步：某个节点将自己的资源目录内容同步到其他节点，使该节点的用户可以查看到这些资源。
Ø 统一服务调用：用户可以通过某个节点调用其他节点提供的数据服务。
Ø 统一监控：可以通过某个节点对其他节点进行监控。
在逻辑上，各节点间的关系可以分如下几类：
Ø 联邦式：各节点对等，两节点间的交互内容由双方协商。
Ø 中心式：有一个节点作为中心节点，包含完整的数据，并对资源进行统一管理；其余节点作为前置节点为中心节点提供数据并接受中心的管理。
Ø 级联式：节点间形成多级的上下级关系，下级为上级提供数据，并接受上级的管理。
6.3高可用的部署方案
ESB的高可用部署方案

LB
ESB
数据提供者
LB
ESB
ESB
……
数据用户

ESB可以部署到多个服务器上，通过LB（负载均衡）将来自数据用户的服务请求分发到某个ESB处理。一个ESB节点的故障不会导致数据服务不可用。LB则采用主备机制防止单点故障。
基于LB可以实现各ESB节点间的负载均衡。
增加ESB节点，即可增强对数据服务的处理能力，实现横向扩展。
DI的高可用部署方案

调度
服务器

作业
服务器

调度
服务器

作业
服务器
作业
服务器

……
源
数据库
目
数据库
作业管理

DI作业服务器可以部署到多个服务器上，通过调度服务器将某个要执行的ETL作业调度到某个作业服务器上执行。一个作业服务器的故障不会导致ETL作业不可用。调度服务器则采用主备机制防止单点故障。
基于调度服务器可以实现各作业服务器间的负载均衡。
增加作业服务器，即可增强对ETL作业的处理能力，实现横向扩展。
6.4特性总结
支持多种数据交换接口
可基于各类数据库、通信协议连接应用系统，且能针对特定场景做定制化开发。便于与各类异构应用系统整合，适应各种复杂环境。
支持多种服务接口
除常见的WebService外，可以以多种协议接口提供数据服务，适应不同的数据用户。
图形化开发
基于图形化开发环境，使业务模块的处理逻辑便于理解，提高开发效率，降低开发成本。
组件化
基于组件扩展机制，可以针对客户场景做定制化开发，增强平台的适应能力，也可以将常用的业务功能以组件的形式积累下来，避免重复开发。
可用性
支持分布式部署，且各环节均有完备的故障转移、负载均衡及横向扩展方案，便于平台系统的逐步实施推广。
移植性
运行环境基于JVM，因此可运行于各主流操作系统中。底层不依赖商业化平台，因此适应面广。