谷 寧 靜

(上海市人力資源和社會(huì)保障局信息中心 上海 200051)

0 引 言

根據(jù)國(guó)家《“互聯(lián)網(wǎng)+政務(wù)服務(wù)”技術(shù)體系建設(shè)指南》統(tǒng)一要求，按照上海政務(wù)“一網(wǎng)通辦”對(duì)于電子證照的技術(shù)要求和規(guī)范體系，上海市人社局將傳統(tǒng)的紙質(zhì)發(fā)證流程改造為電子發(fā)證。鑒于上海人社各類(lèi)職稱(chēng)、職業(yè)資格、職業(yè)技能證書(shū)、居住證積分單等電子證照數(shù)量眾多，證書(shū)的模板和形式均不同，管理較繁雜，故上海人社電子證照系統(tǒng)采用兼容標(biāo)準(zhǔn)自行制發(fā)證，開(kāi)發(fā)電子證照的發(fā)證、用證、驗(yàn)證、銷(xiāo)證等電子證照的全生命周期管理功能。制證完畢后直接將電子證照歸集至上海市電子證照庫(kù)。系統(tǒng)采用頂層設(shè)計(jì)、統(tǒng)一標(biāo)準(zhǔn)、統(tǒng)一平臺(tái)模式建設(shè)，建設(shè)與第三方其他委辦業(yè)務(wù)系統(tǒng)電子證照庫(kù)和大數(shù)據(jù)中心電子證照庫(kù)的數(shù)據(jù)同步機(jī)制，實(shí)現(xiàn)電子證照的共享交換。對(duì)外依托“一網(wǎng)通辦”門(mén)戶(hù)統(tǒng)一提供電子證照開(kāi)放服務(wù)及持證者相關(guān)服務(wù)；對(duì)內(nèi)依托統(tǒng)一信息資源交換體系實(shí)現(xiàn)市級(jí)部門(mén)電子證照的制證發(fā)證，以及全市各級(jí)政府部門(mén)自有電子證照信息的集中匯聚。

1 系統(tǒng)設(shè)計(jì)

1.1 整體框架

電子證照系統(tǒng)主要包含兩個(gè)部分。電子證照公共服務(wù)門(mén)戶(hù)和電子證照服務(wù)平臺(tái)。電子證照公共服務(wù)門(mén)戶(hù)提供用戶(hù)通過(guò)多種終端使用數(shù)字證書(shū)登錄，可根據(jù)平臺(tái)預(yù)設(shè)功能在線申請(qǐng)或委托申請(qǐng)各類(lèi)電子證照、生成及下載電子證照副本。同時(shí)，平臺(tái)提供開(kāi)放的證照驗(yàn)證功能驗(yàn)證各類(lèi)電子證照真?zhèn)?。電子證照管理服務(wù)平臺(tái)一方面提供部門(mén)業(yè)務(wù)管理人員維護(hù)本部門(mén)電子證照目錄、電子證照資源庫(kù)以及配置電子證照模板等功能；另一方面提供部門(mén)業(yè)務(wù)人員在線審核并生成簽發(fā)基于數(shù)字簽章的電子證照全生命周期管理功能。平臺(tái)還提供在線的證照應(yīng)用服務(wù)，為業(yè)務(wù)系統(tǒng)提供在線電子證照申請(qǐng)、審核、注銷(xiāo)、查詢(xún)、驗(yàn)證等各類(lèi)服務(wù)。平臺(tái)整體框架如圖1所示。

圖1 平臺(tái)整體框架

整個(gè)系統(tǒng)框架基于Java EE體系，以Spring套件為基礎(chǔ)，結(jié)合人社LEAF6框架和云計(jì)算技術(shù)體系及相關(guān)技術(shù)產(chǎn)品，支持了應(yīng)用的分布式實(shí)現(xiàn)。引入分布式服務(wù)、分布式緩存、分布式消息隊(duì)列、分布式日志等技術(shù)，支持應(yīng)用規(guī)劃部署和運(yùn)維管理。采用服務(wù)化的思想，將業(yè)務(wù)進(jìn)行拆分，利用分布式服務(wù)彈性伸縮的特性，提高業(yè)務(wù)處理性能。

1.2 電子證照標(biāo)準(zhǔn)

本電子證照文件設(shè)計(jì)標(biāo)準(zhǔn)主要符合以下兩種：

(1) PDF標(biāo)準(zhǔn)。Portable Document Format(PDF)是由Adobe Systems在1993年用于文件交換所發(fā)展出的文件格式。Adobe’s PDF 1.7文件格式于2007年被國(guó)際化標(biāo)準(zhǔn)組織認(rèn)定為國(guó)際標(biāo)準(zhǔn)(ISO 32000)。

(2) OFD標(biāo)準(zhǔn)。Open Fixed-layout Document(OFD)為國(guó)家標(biāo)準(zhǔn)版式文檔格式。2016年10月14日，OFD國(guó)家標(biāo)準(zhǔn)正式發(fā)布，打破依賴(lài)于ISO 32000標(biāo)準(zhǔn)(PDF 1.7)的局面，使我國(guó)電子公文、電子發(fā)票、電子證照等領(lǐng)域應(yīng)用有據(jù)可循。

1.3 功能接口說(shuō)明

電子證照公共服務(wù)門(mén)戶(hù)和電子證照服務(wù)平臺(tái)主要功能接口和說(shuō)明如下：

(1) 新增和修改證照信息：主要實(shí)現(xiàn)證照的新增和證明信息修改后重新制證管理。

(2) 變更證照狀態(tài)：主要實(shí)現(xiàn)證照的注銷(xiāo)管理等。

(3) 下載電子證照：實(shí)現(xiàn)本地電子證照庫(kù)的下載管理，以及獲取上海市電子證照庫(kù)電子證照下載。

(4) 根據(jù)證件號(hào)獲取證照照面信息集，主要實(shí)現(xiàn)根據(jù)電子證照號(hào)來(lái)獲取證照照面上的字段信息。

(5) 根據(jù)證照號(hào)獲取證照?qǐng)D片信息，主要實(shí)現(xiàn)根據(jù)電子證照號(hào)來(lái)獲取電子證照的jpg圖片，方便手機(jī)上展示和掃描亮證展示。

(6) 根據(jù)證照唯一標(biāo)識(shí)獲取二維碼圖片信息，主要實(shí)現(xiàn)根據(jù)證照號(hào)來(lái)加密獲取二維碼圖片。

(7) 二維碼字符串解密：主要實(shí)現(xiàn)電子證照照面上二維碼字符串信息的解密，并根據(jù)二維碼解密出來(lái)的信息獲取證照照明信息。

(8) 獲取上海市電子證照庫(kù)平臺(tái)證照的照面信息：實(shí)現(xiàn)獲取上海市電子證照庫(kù)的電子證照證面信息。

2 平臺(tái)技術(shù)架構(gòu)

2.1 平臺(tái)架構(gòu)設(shè)計(jì)

整體電子證照平臺(tái)主要包括用戶(hù)及服務(wù)層、業(yè)務(wù)應(yīng)用層、應(yīng)用支撐層、數(shù)據(jù)資源層和基礎(chǔ)設(shè)施層。用戶(hù)及服務(wù)層，即電子證照公共服務(wù)門(mén)戶(hù)，主要包括用戶(hù)管理、證照申請(qǐng)、證照使用、證照驗(yàn)證。業(yè)務(wù)應(yīng)用層包括電子證照管理服務(wù)平臺(tái)和證照交換平臺(tái)。電子證照管理服務(wù)平臺(tái)主要包含證照管理、生成簽發(fā)、應(yīng)用服務(wù)。應(yīng)用支撐層包括身份認(rèn)證服務(wù)、電子印章服務(wù)、目錄服務(wù)、工作流引擎等。數(shù)據(jù)資源層主要包括證照庫(kù)、目錄庫(kù)、業(yè)務(wù)庫(kù)、分布式日志賬本?；A(chǔ)設(shè)施層包括硬件設(shè)備和網(wǎng)絡(luò)等。整個(gè)技術(shù)架構(gòu)如圖2所示。

圖2 平臺(tái)技術(shù)架構(gòu)

2.2 服務(wù)化架構(gòu)設(shè)計(jì)

隨著證照系統(tǒng)服務(wù)人群的擴(kuò)大，傳統(tǒng)的單一應(yīng)用架構(gòu)已經(jīng)逐步演變?yōu)榇怪睉?yīng)用架構(gòu)，應(yīng)用不斷被細(xì)化拆分。當(dāng)垂直應(yīng)用越來(lái)越多，應(yīng)用之間交互不可避免，業(yè)務(wù)逐漸服務(wù)化，小服務(wù)資源浪費(fèi)等問(wèn)題逐漸顯現(xiàn)。通過(guò)引入服務(wù)化架構(gòu)，提高業(yè)務(wù)復(fù)用及整合，提供高性能和透明化的遠(yuǎn)程服務(wù)調(diào)用方案，服務(wù)可獨(dú)立部署、自動(dòng)注冊(cè)發(fā)現(xiàn)可快速擴(kuò)容、服務(wù)間可負(fù)載均衡。

系統(tǒng)采用Dubbo做分布式服務(wù)框架，Dubbo是阿里巴巴公司開(kāi)源的一個(gè)高性能優(yōu)秀輕量級(jí)的SOA服務(wù)框架，通過(guò)高性能的RPC實(shí)現(xiàn)服務(wù)的輸出和輸入功能，可以和Spring框架無(wú)縫集成[1]。Dubbo使用Zookeeper做注冊(cè)中心，服務(wù)提供方在注冊(cè)中心注冊(cè)服務(wù)，服務(wù)消費(fèi)方從注冊(cè)中心查詢(xún)服務(wù)提供者后，將與服務(wù)提供方直接連接，不再通過(guò)注冊(cè)中心中轉(zhuǎn)，實(shí)現(xiàn)無(wú)中心化的結(jié)構(gòu)，即使注冊(cè)中心發(fā)生故障，也不影響已建立連接的應(yīng)用訪問(wèn)，大大降低了單點(diǎn)故障風(fēng)險(xiǎn)。雖然注冊(cè)中心故障不影響已連接應(yīng)用，但新接入應(yīng)用將不可用，因此對(duì)Zookeeper做三節(jié)點(diǎn)的高可用集群，加強(qiáng)穩(wěn)定性。一個(gè)典型的服務(wù)化實(shí)現(xiàn)如圖3所示。

圖3 典型服務(wù)化設(shè)計(jì)圖

根據(jù)系統(tǒng)功能的業(yè)務(wù)負(fù)載情況，將服務(wù)分為高頻、中頻和低頻服務(wù)。對(duì)于高頻服務(wù)提供更多的系統(tǒng)資源，包括一些核心業(yè)務(wù)、熱門(mén)業(yè)務(wù)；低頻服務(wù)最主要包括一些訪問(wèn)頻次很低，但單次訪問(wèn)又有復(fù)雜系統(tǒng)操作的功能，其bug隱患較大，將其抽取出來(lái)便于故障隔離；一般的模塊功能歸于中頻服務(wù)，默認(rèn)按模塊進(jìn)行部署。服務(wù)編排不是一成不變的，可按需動(dòng)態(tài)調(diào)整。

2.3 應(yīng)用無(wú)狀態(tài)架構(gòu)設(shè)計(jì)

在無(wú)狀態(tài)的應(yīng)用架構(gòu)中，使用單點(diǎn)登錄技術(shù)，將會(huì)話信息存儲(chǔ)在分布式緩存，所有應(yīng)用共享用戶(hù)登錄信息，不受負(fù)載均衡和集群漂移影響，做到應(yīng)用發(fā)布重啟、故障恢復(fù)、網(wǎng)絡(luò)切換等場(chǎng)景對(duì)外無(wú)感知。

系統(tǒng)選用Redis作為分布式緩存實(shí)現(xiàn)。Redis是當(dāng)前最流行的開(kāi)源分布式緩存產(chǎn)品，使用key-value結(jié)構(gòu)的存儲(chǔ)系統(tǒng)，提供了一些豐富的數(shù)據(jù)結(jié)構(gòu)，如lists、sets、ordered sets等，其查詢(xún)速度可以達(dá)到每秒十萬(wàn)次，性能非常好。Redis支持主從模式和集群模式，兼顧了高可用和高性能[2]，應(yīng)用無(wú)狀態(tài)架構(gòu)設(shè)計(jì)圖如圖4所示。

圖4 應(yīng)用無(wú)狀態(tài)架構(gòu)設(shè)計(jì)圖

2.4 分布式ID設(shè)計(jì)

在上海人社電子證照系統(tǒng)中，證照數(shù)據(jù)日漸增長(zhǎng)，需要對(duì)大量的數(shù)據(jù)和消息進(jìn)行唯一標(biāo)識(shí)。如對(duì)數(shù)據(jù)分庫(kù)分表后需要有一個(gè)唯一ID來(lái)標(biāo)識(shí)一條數(shù)據(jù)或消息，數(shù)據(jù)庫(kù)的自增ID顯然不能滿足需求；每筆自主經(jīng)辦業(yè)務(wù)都需要有唯一ID做標(biāo)識(shí)。此時(shí)一個(gè)能夠生成全局唯一ID的系統(tǒng)是非常必要的，目前自主經(jīng)辦平臺(tái)ID是采用數(shù)據(jù)庫(kù)的auto_increment來(lái)生成的。優(yōu)點(diǎn)：相對(duì)簡(jiǎn)單，能夠保證唯一性和遞增性，ID之間的步長(zhǎng)是固定且可自定義的。缺點(diǎn)：可用性難以保證;數(shù)據(jù)庫(kù)常見(jiàn)架構(gòu)是一主多從+讀寫(xiě)分離，生成自增ID是寫(xiě)請(qǐng)求,主庫(kù)故障將使系統(tǒng)停止運(yùn)行;擴(kuò)展性差，性能有上限[3]。

本系統(tǒng)使用Redis來(lái)生成ID。這主要依賴(lài)于Redis是單線程的，并且可以用來(lái)生成全局唯一的ID。用Redis的原子操作INCR和INCRBY來(lái)實(shí)現(xiàn)生成[4]，優(yōu)點(diǎn)主要包括：依賴(lài)于數(shù)據(jù)庫(kù)，靈活方便，且性能優(yōu)于數(shù)據(jù)庫(kù)；數(shù)字ID天然排序，對(duì)分頁(yè)或者需要排序的結(jié)果很有幫助。

2.5 自動(dòng)化構(gòu)建管理

分布式架構(gòu)中，工程數(shù)量會(huì)非常多，手工構(gòu)建和部署很容易出現(xiàn)問(wèn)題，需要專(zhuān)門(mén)的工具輔助運(yùn)維。應(yīng)用開(kāi)發(fā)引入Maven管理，應(yīng)用部署引入部署工具，實(shí)現(xiàn)版本構(gòu)建、測(cè)試、質(zhì)量檢查、版本發(fā)布等自動(dòng)化管理。

版本構(gòu)建：由svn插件從代碼服務(wù)器上下載最新開(kāi)發(fā)(測(cè)試、生產(chǎn))分支代碼，通過(guò)Maven配置各個(gè)環(huán)境的構(gòu)建模式，在各個(gè)環(huán)境下使用不同的構(gòu)建命令，構(gòu)建出相應(yīng)的程序包。

自動(dòng)化測(cè)試：在源代碼中規(guī)范單元測(cè)試代碼，在版本構(gòu)建時(shí)，自動(dòng)執(zhí)行單元測(cè)試代碼，測(cè)試程序正確性。在版本發(fā)布完成后，也可運(yùn)行測(cè)試腳本，檢查應(yīng)用是否正常運(yùn)行。

質(zhì)量檢查：通過(guò)Maven插件JaCoCo分析單元測(cè)試覆蓋率，結(jié)合SonarQube，對(duì)代碼的bug、漏洞、重復(fù)率、單元測(cè)試覆蓋率等進(jìn)行量化的質(zhì)量檢查，并可在SonarQube平臺(tái)直觀展示。

第三是多層互動(dòng)評(píng)價(jià)。首先，組織學(xué)生現(xiàn)場(chǎng)觀看各小組處理旅游者投訴過(guò)程，學(xué)生通過(guò)現(xiàn)場(chǎng)觀看各組處理投訴的方法及程序后，完成對(duì)各小組現(xiàn)場(chǎng)處理方法的評(píng)價(jià)，并進(jìn)行自評(píng)、互評(píng)，將評(píng)價(jià)結(jié)果上傳APP平臺(tái)；其次，邀請(qǐng)各行業(yè)專(zhuān)家以第二教師身份在APP平臺(tái)上了解各組學(xué)生處理投訴的全過(guò)程，并實(shí)現(xiàn)在線點(diǎn)評(píng)，同學(xué)們?cè)诼?tīng)取行業(yè)專(zhuān)家及教師的意見(jiàn)和講解，對(duì)問(wèn)題的處理方法及技巧進(jìn)行改進(jìn)后，將修改結(jié)果再次上傳平臺(tái)。教師同時(shí)還請(qǐng)出得分最高的同學(xué)分享本次課學(xué)習(xí)體會(huì)。最后，教師依據(jù)典型性錯(cuò)誤進(jìn)行共性講解，提出優(yōu)化方法。

版本發(fā)布：采用Jenkins自動(dòng)化部署平臺(tái)，結(jié)合其插件做到集版本構(gòu)建、自動(dòng)化測(cè)試、質(zhì)量檢查、版本發(fā)布、歸檔于一體，實(shí)現(xiàn)自動(dòng)化構(gòu)建并發(fā)布[5]。

2.6 集中式日志管理

電子證照系統(tǒng)每天會(huì)產(chǎn)生海量的安全事件、操作系統(tǒng)日志、用戶(hù)操作行為日志等。傳統(tǒng)日志方式一般是直接將日志文件輸出到本地文件系統(tǒng)或者共享磁盤(pán)中，在分布式環(huán)境下，需要根據(jù)日志定位問(wèn)題時(shí)，很難精確地定位到發(fā)生問(wèn)題的設(shè)備。通過(guò)引入集中式日志管理工具，將各類(lèi)日志收集匯總到日志服務(wù)器集中管理，便于分析[6]。

本系統(tǒng)采用ELK開(kāi)源日志解決方案，主要利用其Logstash工具進(jìn)行日志的搜集、分析、過(guò)濾，支持大量的數(shù)據(jù)獲取。使用C/S架構(gòu)，Client端安裝在需要收集日志的主機(jī)上，Server端負(fù)責(zé)將收到的各節(jié)點(diǎn)日志進(jìn)行過(guò)濾、修改等操作再一并發(fā)往Elasticsearch[7]。

為了讓日志系統(tǒng)更可靠，我們還引入Redis作為日志中轉(zhuǎn)服務(wù)，應(yīng)用將日志寫(xiě)入Redis，Logstash從Redis讀取日志，最終的日志平臺(tái)架構(gòu)如圖5所示。

圖5 日志平臺(tái)架構(gòu)

3 性能測(cè)試

為了驗(yàn)證系統(tǒng)的制證能力，通過(guò)對(duì)電子證照系統(tǒng)大流量壓力來(lái)測(cè)試系統(tǒng)的性能。

3.1 測(cè)試流程

利用測(cè)試數(shù)據(jù)庫(kù)中已有的證照模板，模擬大批量待生成電子證照，在運(yùn)行證照系統(tǒng)后，統(tǒng)計(jì)單位時(shí)間內(nèi)生成的證照數(shù)量，進(jìn)行電子證照系統(tǒng)性能測(cè)試的評(píng)估。此過(guò)程包含了生成縮略圖和加蓋電子簽章。

通過(guò)測(cè)試終端的瀏覽器訪問(wèn)電子證照系統(tǒng)管理平臺(tái)，監(jiān)控電子證照的生成過(guò)程；通過(guò)數(shù)據(jù)庫(kù)客戶(hù)端連接工具連接測(cè)試數(shù)據(jù)庫(kù)，生成大批量模擬待處理證照數(shù)據(jù)；運(yùn)行電子證照系統(tǒng)制證程序，持續(xù)時(shí)間60分鐘，測(cè)試三次。生成大批量模擬待處理證照數(shù)據(jù)，運(yùn)行電子證照系統(tǒng)制證程序，持續(xù)時(shí)間60分鐘，統(tǒng)計(jì)60分鐘生成的證照數(shù)量，測(cè)試三次，取平均值。

3.2 制證測(cè)試統(tǒng)計(jì)方法

(1) 通過(guò)數(shù)據(jù)庫(kù)記錄查詢(xún)，使用命令：

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

(2) 通過(guò)電子證照管理平臺(tái)查詢(xún)運(yùn)行制證程序前統(tǒng)計(jì)待生成證照數(shù)量。運(yùn)行制證程序10分鐘后，統(tǒng)計(jì)待生成證照數(shù)量，與前一次運(yùn)行制證程序前的數(shù)量的差值，便是在此時(shí)間內(nèi)新生成的證照量。

3.3 測(cè)試結(jié)論

測(cè)試結(jié)果見(jiàn)表1和表2，分別列出了三次測(cè)試生成的證照數(shù)量和平均響應(yīng)時(shí)間。模擬測(cè)試結(jié)果表明，電子證照系統(tǒng)平均每分鐘制證50張，即每小時(shí)制證3 000張。同時(shí)監(jiān)測(cè)服務(wù)器系統(tǒng)狀態(tài)為CPU使用率25%左右，內(nèi)存使用率15%左右。根據(jù)以上測(cè)試結(jié)果證明，該系統(tǒng)可以滿足上海人社的電子制證業(yè)務(wù)需求。

表1 電子證照生成量

表2 電子證照響應(yīng)時(shí)間

4 結(jié) 語(yǔ)

本系統(tǒng)投入應(yīng)用以來(lái)，已成功制出近十萬(wàn)張電子證照，得到了社會(huì)各方的廣泛好評(píng)，極大地提高了制證速度、為百姓帶來(lái)便利。本文詳細(xì)地介紹了電子證照系統(tǒng)的架構(gòu)設(shè)計(jì)和關(guān)鍵技術(shù)框架，實(shí)際應(yīng)用證明該設(shè)計(jì)的合理性和安全性。在后期的電子證照設(shè)計(jì)研究中，將會(huì)結(jié)合區(qū)塊鏈驗(yàn)證技術(shù)，更好更安全地發(fā)揮電子證照系統(tǒng)的作用[8]。