张永跃

（天津市大数据管理中心 天津市 300000）

1 引言

自2016 年“互联网+政务服务”技术体系规范发布以来，全国各地推行政务服务“一网通办”，打破信息孤岛，有效促进了政务数据跨部门、跨层级的协同应用。部门间政务数据共享主要通过前置机交换和服务接口方式实现，在此过程中，数据供需双方需明确约定数据格式、交换频率以及数据对账机制等，以保证数据交换的安全性、完整性和时效性。为凸显“互联网+政务服务”背景下“一网通办”优势，有必要按业务场景特性选用不同的数据共享模式，优化共享流程，提高用户体验。以跨部门单日办结业务为例，对于涉及多部门参与、前置依赖性强、实时响应要求高的共享应用场景可采用微服务+Redis 模式实现高效协同。

2 现状分析

在系统建设设计中，为降低业务逻辑复杂性，解耦是系统设计的重要考虑因素。部分政务信息系统受历史因素等影响，存在系统庞大、业务逻辑复杂、数据结构冗余等问题，导致业务拆分困难，在互联网+背景下的服务输出效能不高。在此情况下，保持系统运行稳定的同时能够持续提供跨部门业务协同服务，是一网通办业务的基本目标。随着政务云等基础设施的发展，政务信息系统建设逐步向政务云端迁移部署，已经具备提供云架构、平台化、资源弹性扩展的条件，可以为微服务应用提供灵活的资源配置保障。根据业务场景需要，通过构建场景业务模型、编制场景应用数据目录、微服务能力输出的方式，实现在原业务系统最低改造下的跨部门协同，有效降低部门间业务联动成本，提高共享效率。

3 业务模型设计

3.1 场景业务特点

本文中描述的业务主要有以下场景特点：以政务服务中跨部门业务协同为主，部门间以信息同步为核心需求，各部门业务边界清晰，业务逻辑关系明确；不关心各部门业务系统复杂性及性能，无需改造各部门原系统业务逻辑，仅在原系统基础上通过增加微服务方式提交、获取相关数据；实时性要求高，目标是实现“立刻办、马上办”；各部门业务系统所在网络相对统一，多以政务外网环境为主。

3.2 技术特点

3.2.1 微服务

微服务架构风格是一种将单体应用程序开发为一组小型服务的方法，每个服务在独立进程中运行，并通过轻量级机制进行通信，通常是HTTP 协议API。服务围绕业务功能构建，并通过完全自动化地部署机制独立部署。服务可以用不同的编程语言编写，使用不同的数据存储技术，从而对这些服务进行最少地集中管理。

图1：技术架构图

在本设计中，每个微服务代表一个单一职责（部门）的功能模块提供服务，独立运行于服务容器中并配置独立数据库，避免与其他微服务因磁盘数据库共用、I/O 资源占用等导致拥塞，实现对各功能模块服务的有效隔离。为保证各部门产生的业务数据能够及时同步写入数据库，每个微服务应按照场景应用数据目录清单，创建适用于本职责（部门）的数据同步接口，保证各部门业务系统产生数据的同时也同步写入每个微服务的数据库。此外，根据各部门业务协同需要，每个部门应对照场景应用数据目录创建相应的服务接口，通过应用服务容器发布，供不同微服务或部门业务系统之间调用。

3.2.2 容器化工具

在政务云计算环境下，云原生技术将更适用于云计算时代的技术架构体系。本次设计的场景中涉及多部门、多微服务，考虑运维管理需要，便于对众多微服务进行快速部署、稳定运行和服务镜像管理，可选用开源技术Docker 作为应用服务容器，通过对应用服务及其环境及资源依赖打包发布，实现一次打包、任意部署或迁移。结合开源技术Kubernetes 容器编排系统，实现自动部署、扩展和管理微服务，从而降低场景应用在高复用、高伸缩性、高可靠性、跨云等要求下的运行管理成本。

3.2.3 内存数据库

本次设计针对的场景是多部门参与、跨部门业务协同下的实时业务办理，数据读写频繁，跨部门调用频次高，数据实时同步要求突出。使用内存数据库以键值对（key-value）存储形式作为一种缓存机制搭配磁盘数据库，可以有效分担磁盘I/O 压力，通过内存数据库读写操作，及时响应业务办理，并将数据定期持久化到磁盘数据库中，从而满足当日办结类业务场景需要。

Redis 是一种开源的内存数据库系统，可用作数据库、缓存和消息中间件使用。它支持多种类型数据结构，支持字符串（strings）、散列（hashes）、列表（lists）、集合（sets）、有序集合（sortedsets）等类型数据的范围查询。在保证网络延迟、进程间通信消耗稳定的情况下，利用Redis 读写性能高、支持数据类型种类多的优势，采用Redis+Mysql 的数据库设计，是服务本次目标场景中实时数据同步的理想数据库方案。

3.3 系统设计

3.3.1 构建场景业务模型

在“一网通办”业务中，各部门需明确在本部门业务办理中所需的前置条件信息及必要的回传信息，如其他部门的办理结果信息、凭证信息及本部门的办理结果信息等，可由参与部门共同商议，研究确定各部门涉及的业务信息类及信息项，针对每一个信息类，还需要明确其产生部门、更新频率、分发及回传规则等，汇总形成场景应用数据目录清单及场景业务规则清单。根据确定的业务模型和业务逻辑关系，多部门共同创建跨部门的场景应用库。

3.3.2 技术架构设计

如图1 所示，总体设计分为四层，分别为：业务层、网关层、服务层和持久层，各层的主要功能：

业务层：作为跨部门协同场景应用的前端，负责接收处理来自各部门及办事主体的业务请求。业务发生主要通过各部门业务系统、网上办事大厅、自助终端以及政务服务手机APP 实现。当办事主体发起办事申请后，部门业务系统按照本部门环节业务逻辑关系，以办事主体身份标识为索引，调用服务层提供的微服务接口获取相关业务依赖信息,完成本部门业务环节处理并生成办理结果信息；办事主体通过网厅或手机APP 查询了解当前总体办事进度及相关状态信息。

网关层：利用共享交换体系中的云服务总线技术，提供接口服务注册、配置管理、用户认证、链路加密、负载均衡等接口网关服务能力，发挥各业务系统网络统一的优势，利用服务总线提高服务接口管理及调用的安全性和稳定性。

服务层：利用微服务和Redis构建,是跨部门场景应用的核心层。在不破坏和改造原业务系统逻辑前提下，创建本部门微服务，按照业务隔离原则分别提供独立的、原子的业务支撑服务接口，如数据查询、写入和校对等。在本设计中，Redis 主要作为内存数据库扮演数据缓存角色，以支撑高并发读写操作，实现实时地跨部门业务查询和办理。最后可根据场景业务需要，将Redis 中的数据持久化到磁盘数据库中。

持久层：每个微服务应具备独立数据库，按部门业务条线分别入库存储，用于单一部门数据比对校核。场景应用库是按场景主题梳理、整合各部门在场景业务运行中生产的业务数据，形成综合的场景应用数据模型，并按模型对Redis 缓存数据、各部门业务分库数据进行加工和持久化，最终形成场景应用库并通过服务层对外提供综合服务。

3.3.3 关键业务功能

（1）数据同步。当业务发生时，部门业务系统产生新数据，调用本部门业务系统相应的微服务接口提交数据并在Redis 中缓存，供其他微服务实时查询调用，同时可将数据持久化到本部门微服务对应的数据库中，作为单一部门生产数据存储。此外，以当日办结类业务场景为例，可定时在非业务办理时间进行Redis 缓存数据的持久化，按场景应用数据模型归集当日办结的全部业务数据并写入数据库。数据同步是作为实现数据共享的重要功能，在同步实时性上要优于前置机数据推送方式。

（2）数据查询。由各部门开发匹配本部门业务系统的微服务，提供跨部门的基本数据查询接口，从而为各部门业务串联衔接提供数据支撑保障。同时，每个查询接口返回的信息都是来自原始数据产生部门的、原子的业务数据，以保证每个环节业务办理所需数据的来源和属性都是唯一的、最新的。

（3）场景应用库服务。在场景业务运转过程中，业务办理用户、部门业务系统、微服务、Redis 数据缓存、持久层数据库等都是支撑本场景跨部门业务协同的组成部门，但还应通过场景应用库服务将业务流程办结后的结果和过程数据进行梳理并向外提供服务，例如：向办事用户提供业务办理全流程状态查询服务、向政务服务管理部门提供办件流程或结果信息等。

（4）数据沉淀。各业务系统在参与场景业务运转中，可通过微服务向各业务分库快速沉淀数据，分流数据库I/O 并发压力。分库数据代表某一特定业务数据，不与其他业务数据相混杂，数据结构清晰、定义明确，便于提供单一数据的比对校核、定向输出等服务，简化了数据梳理工作，是建设主题数据库、专题数据库的良好数来源。

4 技术模式对比

按照《“互联网+政务服务”技术体系建设指南》，政务服务数据共享通过前置机（数据库表）、Web Service、文件交换等形式实现数据共享。前置机交换方式需要各部门制定详细的交换库表结构、交换规则并按时进行手动或自动数据推送，共享环节包括提供部门业务系统、提供部门前置机、共享交换平台、需求部门前置机、需求部门业务系统，此模式交换过程路径节点多、执行规则要求高，适用于数量大、变化慢、结果型数据的批量定时交换。WebService与微服务的最终实现形式都是接口，但WebService 需要对业务系统本身进行改造，增加定制接口，并且性能受业务系统事务复杂度、数据库读写速度、调用并发量等条件制约。微服务方式能够用较小的系统改造和独立部署方式换来高实时性的数据同步性能。同时，微服务+Redis 的模式在服务各业务系统及办事用户之外，还可承载场景应用数据加工整理职能，便于形成主题或专题数据库，不仅实现场景内应用服务，也能面向场景外部提供服务和数据输出能力。

5 结论

本次设计中，运用微服务、Redis 等构建适用于高并发、时效性要求高的场景数据交换方案，可作为常规前置机数据库表交换方式的有益补充。随着云原生技术发展带来的新的应用建设模式，相信以微服务、容器技术、容器编排管理等新一代技术将更多地应用于政务信息化建设中去，同时也对云计算时代信息化建设提出了新的要求，在应用安全架构、运维管理架构、业务架构等方面需要进行重新思考和设计，以满足新形势下技术栈与业务的有效融合。