上海人社電子證照系統架構設計

谷 寧 靜

(上海市人力資源和社會保障局信息中心 上海 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]。