上海人社电子证照系统架构设计

谷 宁 静

(上海市人力资源和社会保障局信息中心 上海 200051)

0 引 言

根据国家《“互联网+政务服务”技术体系建设指南》统一要求，按照上海政务“一网通办”对于电子证照的技术要求和规范体系，上海市人社局将传统的纸质发证流程改造为电子发证。鉴于上海人社各类职称、职业资格、职业技能证书、居住证积分单等电子证照数量众多，证书的模板和形式均不同，管理较繁杂，故上海人社电子证照系统采用兼容标准自行制发证，开发电子证照的发证、用证、验证、销证等电子证照的全生命周期管理功能。制证完毕后直接将电子证照归集至上海市电子证照库。系统采用顶层设计、统一标准、统一平台模式建设，建设与第三方其他委办业务系统电子证照库和大数据中心电子证照库的数据同步机制，实现电子证照的共享交换。对外依托“一网通办”门户统一提供电子证照开放服务及持证者相关服务；对内依托统一信息资源交换体系实现市级部门电子证照的制证发证，以及全市各级政府部门自有电子证照信息的集中汇聚。

1 系统设计

1.1 整体框架

电子证照系统主要包含两个部分。电子证照公共服务门户和电子证照服务平台。电子证照公共服务门户提供用户通过多种终端使用数字证书登录，可根据平台预设功能在线申请或委托申请各类电子证照、生成及下载电子证照副本。同时，平台提供开放的证照验证功能验证各类电子证照真伪。电子证照管理服务平台一方面提供部门业务管理人员维护本部门电子证照目录、电子证照资源库以及配置电子证照模板等功能；另一方面提供部门业务人员在线审核并生成签发基于数字签章的电子证照全生命周期管理功能。平台还提供在线的证照应用服务，为业务系统提供在线电子证照申请、审核、注销、查询、验证等各类服务。平台整体框架如图1所示。

图1 平台整体框架

整个系统框架基于Java EE体系，以Spring套件为基础，结合人社LEAF6框架和云计算技术体系及相关技术产品，支持了应用的分布式实现。引入分布式服务、分布式缓存、分布式消息队列、分布式日志等技术，支持应用规划部署和运维管理。采用服务化的思想，将业务进行拆分，利用分布式服务弹性伸缩的特性，提高业务处理性能。

1.2 电子证照标准

本电子证照文件设计标准主要符合以下两种：

(1) PDF标准。Portable Document Format(PDF)是由Adobe Systems在1993年用于文件交换所发展出的文件格式。Adobe’s PDF 1.7文件格式于2007年被国际化标准组织认定为国际标准(ISO 32000)。

(2) OFD标准。Open Fixed-layout Document(OFD)为国家标准版式文档格式。2016年10月14日，OFD国家标准正式发布，打破依赖于ISO 32000标准(PDF 1.7)的局面，使我国电子公文、电子发票、电子证照等领域应用有据可循。

1.3 功能接口说明

电子证照公共服务门户和电子证照服务平台主要功能接口和说明如下：

(1) 新增和修改证照信息：主要实现证照的新增和证明信息修改后重新制证管理。

(2) 变更证照状态：主要实现证照的注销管理等。

(3) 下载电子证照：实现本地电子证照库的下载管理，以及获取上海市电子证照库电子证照下载。

(4) 根据证件号获取证照照面信息集，主要实现根据电子证照号来获取证照照面上的字段信息。

(5) 根据证照号获取证照图片信息，主要实现根据电子证照号来获取电子证照的jpg图片，方便手机上展示和扫描亮证展示。

(6) 根据证照唯一标识获取二维码图片信息，主要实现根据证照号来加密获取二维码图片。

(7) 二维码字符串解密：主要实现电子证照照面上二维码字符串信息的解密，并根据二维码解密出来的信息获取证照照明信息。

(8) 获取上海市电子证照库平台证照的照面信息：实现获取上海市电子证照库的电子证照证面信息。

2 平台技术架构

2.1 平台架构设计

整体电子证照平台主要包括用户及服务层、业务应用层、应用支撑层、数据资源层和基础设施层。用户及服务层，即电子证照公共服务门户，主要包括用户管理、证照申请、证照使用、证照验证。业务应用层包括电子证照管理服务平台和证照交换平台。电子证照管理服务平台主要包含证照管理、生成签发、应用服务。应用支撑层包括身份认证服务、电子印章服务、目录服务、工作流引擎等。数据资源层主要包括证照库、目录库、业务库、分布式日志账本。基础设施层包括硬件设备和网络等。整个技术架构如图2所示。

图2 平台技术架构

2.2 服务化架构设计

随着证照系统服务人群的扩大，传统的单一应用架构已经逐步演变为垂直应用架构，应用不断被细化拆分。当垂直应用越来越多，应用之间交互不可避免，业务逐渐服务化，小服务资源浪费等问题逐渐显现。通过引入服务化架构，提高业务复用及整合，提供高性能和透明化的远程服务调用方案，服务可独立部署、自动注册发现可快速扩容、服务间可负载均衡。

系统采用Dubbo做分布式服务框架，Dubbo是阿里巴巴公司开源的一个高性能优秀轻量级的SOA服务框架，通过高性能的RPC实现服务的输出和输入功能，可以和Spring框架无缝集成[1]。Dubbo使用Zookeeper做注册中心，服务提供方在注册中心注册服务，服务消费方从注册中心查询服务提供者后，将与服务提供方直接连接，不再通过注册中心中转，实现无中心化的结构，即使注册中心发生故障，也不影响已建立连接的应用访问，大大降低了单点故障风险。虽然注册中心故障不影响已连接应用，但新接入应用将不可用，因此对Zookeeper做三节点的高可用集群，加强稳定性。一个典型的服务化实现如图3所示。

图3 典型服务化设计图

根据系统功能的业务负载情况，将服务分为高频、中频和低频服务。对于高频服务提供更多的系统资源，包括一些核心业务、热门业务；低频服务最主要包括一些访问频次很低，但单次访问又有复杂系统操作的功能，其bug隐患较大，将其抽取出来便于故障隔离；一般的模块功能归于中频服务，默认按模块进行部署。服务编排不是一成不变的，可按需动态调整。

2.3 应用无状态架构设计

在无状态的应用架构中，使用单点登录技术，将会话信息存储在分布式缓存，所有应用共享用户登录信息，不受负载均衡和集群漂移影响，做到应用发布重启、故障恢复、网络切换等场景对外无感知。

系统选用Redis作为分布式缓存实现。Redis是当前最流行的开源分布式缓存产品，使用key-value结构的存储系统，提供了一些丰富的数据结构，如lists、sets、ordered sets等，其查询速度可以达到每秒十万次，性能非常好。Redis支持主从模式和集群模式，兼顾了高可用和高性能[2]，应用无状态架构设计图如图4所示。

图4 应用无状态架构设计图

2.4 分布式ID设计

在上海人社电子证照系统中，证照数据日渐增长，需要对大量的数据和消息进行唯一标识。如对数据分库分表后需要有一个唯一ID来标识一条数据或消息，数据库的自增ID显然不能满足需求；每笔自主经办业务都需要有唯一ID做标识。此时一个能够生成全局唯一ID的系统是非常必要的，目前自主经办平台ID是采用数据库的auto_increment来生成的。优点：相对简单，能够保证唯一性和递增性，ID之间的步长是固定且可自定义的。缺点：可用性难以保证;数据库常见架构是一主多从+读写分离，生成自增ID是写请求,主库故障将使系统停止运行;扩展性差，性能有上限[3]。

本系统使用Redis来生成ID。这主要依赖于Redis是单线程的，并且可以用来生成全局唯一的ID。用Redis的原子操作INCR和INCRBY来实现生成[4]，优点主要包括：依赖于数据库，灵活方便，且性能优于数据库；数字ID天然排序，对分页或者需要排序的结果很有帮助。

2.5 自动化构建管理

分布式架构中，工程数量会非常多，手工构建和部署很容易出现问题，需要专门的工具辅助运维。应用开发引入Maven管理，应用部署引入部署工具，实现版本构建、测试、质量检查、版本发布等自动化管理。

版本构建：由svn插件从代码服务器上下载最新开发(测试、生产)分支代码，通过Maven配置各个环境的构建模式，在各个环境下使用不同的构建命令，构建出相应的程序包。

自动化测试：在源代码中规范单元测试代码，在版本构建时，自动执行单元测试代码，测试程序正确性。在版本发布完成后，也可运行测试脚本，检查应用是否正常运行。

质量检查：通过Maven插件JaCoCo分析单元测试覆盖率，结合SonarQube，对代码的bug、漏洞、重复率、单元测试覆盖率等进行量化的质量检查，并可在SonarQube平台直观展示。

第三是多层互动评价。首先，组织学生现场观看各小组处理旅游者投诉过程，学生通过现场观看各组处理投诉的方法及程序后，完成对各小组现场处理方法的评价，并进行自评、互评，将评价结果上传APP平台；其次，邀请各行业专家以第二教师身份在APP平台上了解各组学生处理投诉的全过程，并实现在线点评，同学们在听取行业专家及教师的意见和讲解，对问题的处理方法及技巧进行改进后，将修改结果再次上传平台。教师同时还请出得分最高的同学分享本次课学习体会。最后，教师依据典型性错误进行共性讲解，提出优化方法。

版本发布：采用Jenkins自动化部署平台，结合其插件做到集版本构建、自动化测试、质量检查、版本发布、归档于一体，实现自动化构建并发布[5]。

2.6 集中式日志管理

电子证照系统每天会产生海量的安全事件、操作系统日志、用户操作行为日志等。传统日志方式一般是直接将日志文件输出到本地文件系统或者共享磁盘中，在分布式环境下，需要根据日志定位问题时，很难精确地定位到发生问题的设备。通过引入集中式日志管理工具，将各类日志收集汇总到日志服务器集中管理，便于分析[6]。

本系统采用ELK开源日志解决方案，主要利用其Logstash工具进行日志的搜集、分析、过滤，支持大量的数据获取。使用C/S架构，Client端安装在需要收集日志的主机上，Server端负责将收到的各节点日志进行过滤、修改等操作再一并发往Elasticsearch[7]。

为了让日志系统更可靠，我们还引入Redis作为日志中转服务，应用将日志写入Redis，Logstash从Redis读取日志，最终的日志平台架构如图5所示。

图5 日志平台架构

3 性能测试

为了验证系统的制证能力，通过对电子证照系统大流量压力来测试系统的性能。

3.1 测试流程

利用测试数据库中已有的证照模板，模拟大批量待生成电子证照，在运行证照系统后，统计单位时间内生成的证照数量，进行电子证照系统性能测试的评估。此过程包含了生成缩略图和加盖电子签章。

通过测试终端的浏览器访问电子证照系统管理平台，监控电子证照的生成过程；通过数据库客户端连接工具连接测试数据库，生成大批量模拟待处理证照数据；运行电子证照系统制证程序，持续时间60分钟，测试三次。生成大批量模拟待处理证照数据，运行电子证照系统制证程序，持续时间60分钟，统计60分钟生成的证照数量，测试三次，取平均值。

3.2 制证测试统计方法

(1) 通过数据库记录查询，使用命令：

Select count(*) from “Ecert_certInfo” where “Status”=2 and “UseStatus”=”新增”

(2) 通过电子证照管理平台查询运行制证程序前统计待生成证照数量。运行制证程序10分钟后，统计待生成证照数量，与前一次运行制证程序前的数量的差值，便是在此时间内新生成的证照量。

3.3 测试结论

测试结果见表1和表2，分别列出了三次测试生成的证照数量和平均响应时间。模拟测试结果表明，电子证照系统平均每分钟制证50张，即每小时制证3 000张。同时监测服务器系统状态为CPU使用率25%左右，内存使用率15%左右。根据以上测试结果证明，该系统可以满足上海人社的电子制证业务需求。

表1 电子证照生成量

表2 电子证照响应时间

4 结 语

本系统投入应用以来，已成功制出近十万张电子证照，得到了社会各方的广泛好评，极大地提高了制证速度、为百姓带来便利。本文详细地介绍了电子证照系统的架构设计和关键技术框架，实际应用证明该设计的合理性和安全性。在后期的电子证照设计研究中，将会结合区块链验证技术，更好更安全地发挥电子证照系统的作用[8]。