上海人社電子證照系統(tǒng)架構(gòu)設(shè)計

谷 寧 靜

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

0 引 言

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

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

1.1 整體框架

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

圖1 平臺整體框架

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

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

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

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

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

1.3 功能接口說明

電子證照公共服務(wù)門戶和電子證照服務(wù)平臺主要功能接口和說明如下：

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

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

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

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

(5) 根據(jù)證照號獲取證照圖片信息，主要實現(xiàn)根據(jù)電子證照號來獲取電子證照的jpg圖片，方便手機上展示和掃描亮證展示。

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

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

(8) 獲取上海市電子證照庫平臺證照的照面信息：實現(xiàn)獲取上海市電子證照庫的電子證照證面信息。

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

2.1 平臺架構(gòu)設(shè)計

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

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

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

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

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

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

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

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

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

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

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

2.4 分布式ID設(shè)計

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

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

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

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

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

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

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

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

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

2.6 集中式日志管理

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

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

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

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

3 性能測試

為了驗證系統(tǒng)的制證能力，通過對電子證照系統(tǒng)大流量壓力來測試系統(tǒng)的性能。

3.1 測試流程

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

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

3.2 制證測試統(tǒng)計方法

(1) 通過數(shù)據(jù)庫記錄查詢，使用命令：

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

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

3.3 測試結(jié)論

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

表1 電子證照生成量

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

4 結(jié) 語

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