海委统一业务门户建设探索

张洋

（海河水利委员会水利信息网络中心，天津 300170）

1 海委业务应用现状

目前，海委正在运行的系统共65个，其中委机关30个、漳卫南运河管理局19个、海河下游管理局11个、漳河上游管理局5个，覆盖综合办公、水资源管理、水文业务、防汛抗旱、水行政执法、视频监控、地下水等业务方向。在开发技术路线方面，现有系统选型各异，绝大部分系统采用B/S架构，少部分系统采用C/S架构；数据库管理软件集中使用Oracle，少量系统使用SQL Server与MySQL；部分水文类系统使用.Net和VB进行开发，其他业务类系统均采用Java语言进行开发。在数据管理与应用方面，各类系统从业务需求出发进行数据汇集、管理以及应用，但并未保证一数一源，严重影响数据一致性与权威性。

2 海委业务应用存在的问题

近年来，海委积极推进水利信息化建设，形成了由基础设施、信息资源、业务应用和保障环境组成的水利信息化综合体系。随着水利信息化的发展，受限于投资来源不同、建设管理方式各异、应用和运行维护分散等因素影响，海委水利信息化中存在的“信息孤岛”、业务割据、设施分散、安全薄弱等问题日益明显。

2.1 缺乏统一业务平台

长期以来，各单位、部门结合自己的业务需求，为满足局部的应用目标，开发建设了一些专用信息系统，这些系统在水利工作中发挥了积极的作用，但同时这些系统大多分散建设在各个地区或不同业务部门，形成以地域、专业、部门、系统等为边界的孤岛，造成了资源和业务割据的局面。因此，海委机关和直属各管理局需要整合各业务系统，建立统一的业务平台，全面消除业务孤岛，实现集中部署、多级应用，达到服务全局、深化协同的目的。

2.2 缺乏统一数据管理

受部署地点等各方面条件的限制，许多系统不具备持续运行条件，难以向外界用户提供服务，加上系统规范性差，客观上形成了共享困难的鸿沟。同时，由于缺少信息共享政策法规，共享机制还未建立，信息服务合理补偿机制尚未形成，导致资源的占有者都希望共享其他占有者的资源，却不愿意将自己所拥有的资源提供共享，单向的共享愿望形成事实上的信息壁垒。另外，在传统建设模式下，数据资源存储分散、数据提取复杂繁琐，进行数据共享造成很多数据资源信息有多个来源或接口，导致数据不一致，不能准确掌握流域水利的基本情况，使数据得不到充分有效的利用。因此，海委机关和直属各管理局需要建立统一信息资源管理，实现统一数据库的统一目录管理、统一数据管理、统一共享交换管理，达到水利数据“源端维护、全网共享”的目的。

2.3 缺乏统一用户体系

由于投资来源不同、建设管理单位或部门不同、系统开发机制不同，每个系统都使用单独的登录方式、用户管理、权限管理和数据访问管理，管理复杂而繁琐，用户需要记住使用的所有系统用户和密码，易用性差。因此，海委机关和直属各管理局需要建立统一的用户管理体系，实现统一用户管理、统一身份认证与单点登录功能。

3 海委统一业务门户建设思路

海委统一业务门户建设需要在数据资源整合、系统整合的基础上，通过对业务系统共用功能的提炼、业务流程的对接、显示表达的协调，基于海河流域“水利一张图”，建立智慧海河统一业务门户，提供数据资源服务、业务服务、助手服务和移动应用服务；同时，建立统一用户认证平台，适应各种复杂的用户权限关系，实现主要业务系统的单点登录功能。其总体架构由6个层次、2大体系组成。其中，6个层次分别为网络层、设施层、数据资源层、支撑层、应用层、展现层，2大体系分别为标准规范体系和网络安全防护体系，如图1所示。

图1 海委统一业务门户总体架构

3.1 部署层

系统整合在部署层面，通过调整现有系统的部署方式，尽可能降低各业务系统在网络安全方面的风险隐患。对互联网开放的应用，统一部署至DMZ区，所需的数据由政务外网区服务器进行单向同步。每类业务系统或平台部署一个应用代理服务，对外提供访问入口，各子系统或GIS应用不再对外暴露访问端口。

3.2 数据资源层

在数据层面将分散至各部门、单位的数据资源进行梳理，通过一次性汇集和实时同步的方式将已有数据资源汇集至新建的海委统一数据库中。各业务系统保持原有的数据汇集方式与通道，各类填报与上报系统仍继续使用。利用同步软件将各业务已有数据同步至新建的统一数据库（包含基础、监测、业务、政务、空间、元数据库等）。同步策略分为全量、实时在线、离线等。日后新建的业务系统均使用统一数据库。

3.3 支撑层

在支撑层面将原有系统的支撑体系进行替换，各业务系统针对统一服务管理、统一用户管理、统一身份认证服务、单点登录以及统一审计功能进行重新集成。

（1）统一用户管理。基于海委统一的用户管理体系，改造原业务系统的用户与组织机构管理功能，完成用户与角色的重新绑定。

（2）统一身份认证。基于海委提供的统一身份认证服务，将已有的业务系统重新进行单点登录功能集成。

（3）统一服务管理平台。基于新构建的统一服务管理平台（具备服务的注册、发现、监控、鉴权等功能），发布数据类服务、分析统计类服务、业务类服务，为业务门户提供数据支撑。各业务需根据门户需要梳理并发布各类服务。

（4）业务专题图发布。将各业务现有的专题图进行梳理并发布规范的服务，供整合后的系统使用，同时为后期统一注册至海委一张图服务平台做准备。

3.4 应用层面

统一整合在应用层面，主要实现数据一致性、加强业务专业性以及提升多业务协同性，将分3种情况进行。

（1）数据一致性。一部分系统通过发布数据服务体现，为全委提供权威一致的数据服务，如水文业务的实时雨水情、统计信息等，水资源业务的取用水信息等。

（2）业务专业性。一部分系统通过业务服务体现，整合后，将业务数据以服务的形式向其他业务提供接入口，原系统继续运行，如防洪调度系统、抗旱业务系统、水资源调配系统、档案管理系统、电子邮件系统。

（3）多业务协同性。通过新建统一的平台体现，将各业务需要协同的功能进行统一整合，整合后的平台包含原系统功能，涉及综合政务平台、水文综合业务平台、视频监控平台、水资源和防汛抗旱类系统。

4 海委统一业务门户技术路线

4.1 数据资源层

在数据接入方面，使用关系型实时同步、数据抽取、日志采集、数据接口等技术手段实现数据的接入。在数据存储方面，使用关系型数据库、内存数据库、文件存储等形式实现结构化、半结构化、非结构化数据的存储。在数据治理方面，使用数据提供、清洗、关联、标识以及融合等技术来实现数据的处理。在数据服务方面，使用API接口、WebService、文件服务等技术来构建数据服务。

4.2 支撑层

采用微服务架构，对已建业务系统的通用、共性与类同需求进行服务的抽取，同时结合整合后的业务系统与业务门户所需的功能发布新的服务，发布的服务基于统一平台进行管理，提供服务注册、配置、监控管理、用户鉴权以及日志审计功能，确保各业务系统之间的互联、互通和互操作。

4.3 应用层

针对新开发的应用，采用微服务架构进行实施，使用前后端分离的方式进行，后端服务采用Webservice或RESTful形式提供，返回的数据以Json格式进行组织，服务的调用需携带服务端签发的Token，以保证数据安全，同时后端根据应用场景需要持续完善服务。已有的业务应用，仍保持现有的服务提供方式。

4.4 展现层

展现层的开发将选择浏览器兼容性较强的Javascript库（Layui、Bootstrap、Vue.js）进行，并配合统一的包管理工具、构建工具、测试工具完成。构建完成的前端依据应用场景变化以及技术更迭等，可快速重构界面展现形式。

5 结语

以智慧海河总体方案为指导，利用资源整合形成的7大类业务服务成果，快速构建门户业务全景，解决数据不唯一、标准不统一、重复建设、资源共享难等诸多老问题，形成操作性强的工作机制，推进业务门户的建设。海委业务门户从功能角度涵盖业务全景、重点提升综合政务平台，实现集领导办公、公文处理、信息发布、督查督办、会议管理、综合事务、个人事项、服务帮助、党的建设、人事管理、财务管理、档案管理于一体的政务平台，进一步加强业务深化协同与数据全面共享，提升水利信息化体系效能。