青少年活動中心基礎數(shù)據(jù)平臺及數(shù)字駕駛艙項目建設方案

青少年活動中心基礎數(shù)據(jù)平臺及數(shù)字駕駛艙項目

建設方案

目錄

一、項目概況..............................................................4

二、項目建設原則..........................................................4

（-）標準化、規(guī)范性和開放性.............................................4

（二）先進性、成熟性和易用性.............................................5

（三）可靠性、穩(wěn)定性和容錯性.............................................5

（四）可擴展性和易升級性.................................................5

（五）安全性和保密性......................................................6

（六）可管理性、可維護性和獨立性.........................................7

（七）前端定制化..........................................................8

三、基礎數(shù)據(jù)管理平臺......................................................8

1、平臺性能要求.........................................................8

1.1穩(wěn)定可靠............................................................8

1.2高效響應............................................................8

L3高并發(fā)率............................................................9

1.4高用戶數(shù)............................................................9

1.5兼容適應性.........................................................9

2、項目建設內(nèi)容........................................................10

2.1統(tǒng)一認證平臺......................................................10

2.2開發(fā)者門戶........................................................17

2.3消息服務中心......................................................22

2.4監(jiān)控中心..........................................................24

2.5日志管理..........................................................26

2.6數(shù)據(jù)管理中心......................................................27

2.7對接移動端APP....................................................40

四、數(shù)字駕駛艙...........................................................40

1、項目要求............................................................40

2、項目需求............................................................40

3、系統(tǒng)交互............................................................41

4、功能要求............................................................42

4.1登錄/權限..........................................................42

4.2數(shù)據(jù)管理...........................................................43

4.3儀表盤管理.........................................................44

4.4儀表盤場景.........................................................47

4.5業(yè)務預警...........................................................49

4.6插件管理...........................................................50

4.7監(jiān)控中心...........................................................50

4.8日志管理...........................................................50

一、項目概況

根據(jù)杭州青少年活動中心十四五規(guī)劃，為了聚焦數(shù)字賦能，提升

信息化水平，應整合中心現(xiàn)有信息化平臺，以基礎數(shù)據(jù)管理平臺為核

心，以智慧治理、智慧育人、智慧服務為建設內(nèi)容，以改善基礎設施、

挖掘應用場景、提升信息素養(yǎng)為途徑，著力構(gòu)建中心可持續(xù)發(fā)展的

“1+3+3”信息化建設新體系，努力建成服務智慧化、決策數(shù)據(jù)化、

管理精準化、育人多元化的智慧少年宮。

基礎數(shù)據(jù)管理平臺是信息化平臺的基礎，是打造智慧少年宮的基

石。目標是在現(xiàn)有數(shù)據(jù)特征和硬件設備的基礎上，構(gòu)建權限統(tǒng)一、集

約高效、數(shù)據(jù)易控的業(yè)務中樞平臺，實現(xiàn)對杭州青少年活動中心各核

心業(yè)務系統(tǒng)的有效支撐，有力發(fā)展各方面重點應用，實現(xiàn)“統(tǒng)一架構(gòu)、

統(tǒng)一用戶、統(tǒng)一門戶、統(tǒng)一數(shù)源”的整體架構(gòu)體系。

數(shù)字駕駛艙通過采集各應用平臺數(shù)據(jù)，利用云計算、大數(shù)據(jù)、人

工智能、區(qū)塊鏈等新技術，將數(shù)據(jù)進行統(tǒng)一管理、集中調(diào)度、動態(tài)感

知、智能分析，使之成為中心各項工作決策的“分析儀”和“指南針”，

用科學、可靠、有效的數(shù)據(jù)分析帶動管理由人力密集向人機交互轉(zhuǎn)型,

由經(jīng)驗判斷向數(shù)據(jù)實證轉(zhuǎn)變，提高大數(shù)據(jù)支撐管理、決策、公共服務

的整體效能，為全面構(gòu)建中心智能化的治理、育人、服務新體系提供

有力支撐。

二、項目建設原則

（一）標準化、規(guī)范性和開放性

全中心的信息化建設是一個龐大的系統(tǒng)工程，其體系的設計、系

統(tǒng)的實施等必須遵循一系列的規(guī)范、標準，確保各個分系統(tǒng)的有效協(xié)

調(diào)，整個系統(tǒng)能安全地互聯(lián)互通、信息共享。設計、開發(fā)和管理維護

各階段的技術文檔要完整、規(guī)范、條理清晰。作為一個開放的且符合

業(yè)界主流技術標準的系統(tǒng)平臺，對網(wǎng)絡的硬件環(huán)境，通信環(huán)境，軟件

環(huán)境，操作平臺之間的依賴小。

（二）先進性、成熟性和易用性

系統(tǒng)設計既要采用先進技術和系統(tǒng)工程方法，又要注意技術的可

行性和實用性，方法的正確性。在整個系統(tǒng)的生命周期內(nèi)，系統(tǒng)應能

夠不斷完善、擴充、更新，使功能愈來愈豐富，性能愈來愈穩(wěn)定，使

用愈來愈方便。系統(tǒng)具備可伸縮的架構(gòu)，設計既要采用先進技術和系

統(tǒng)工程方法,還要注意技術的合理性,技術的可行性,方法的正確性。

采用面向?qū)ο蟮慕M件技術開發(fā)，著重于開發(fā)構(gòu)成應用程序“業(yè)務對象”

的可重復使用的組件，利用這些組件順利地建立分布式應用程序。

（三）可靠性、穩(wěn)定性和容錯性

在考慮技術先進性和開放性的同時，還應從系統(tǒng)結(jié)構(gòu)，技術措施，

系統(tǒng)管理等方面著手，確保系統(tǒng)運行的可靠性和穩(wěn)定性，達到最大的

平均無故障時間。運行穩(wěn)定、安全可靠、實用性強，在訪問高峰期系

統(tǒng)的接口訪問命中率達到99%以上。尤其是在報名期間，要維持系統(tǒng)

的強穩(wěn)定性和易用性，避免出現(xiàn)頁面卡死、不可用的情況。提高應用

數(shù)據(jù)收集和應用統(tǒng)計的穩(wěn)定性，實現(xiàn)日志收集與數(shù)據(jù)分析的異步處理,

建立數(shù)據(jù)倉庫，實現(xiàn)統(tǒng)計數(shù)據(jù)的唯一源獲取，避免前、后臺、用戶個

人中心統(tǒng)計數(shù)據(jù)不一致。

為適應IPv4和IPv6網(wǎng)絡環(huán)境，本項目實施需滿足IPv4和IPv6

網(wǎng)絡環(huán)境下部署，且所有功能均可正常運行。

（四）可擴展性和易升級性

為適應應用不斷拓展的需要，應用平臺的軟硬件環(huán)境必須有良好

的平滑可擴充性。要提供簡便、規(guī)范、暢通的基礎數(shù)據(jù)服務。能夠最

大限度地適應未來業(yè)務發(fā)展的變化。整個系統(tǒng)低耦合、模塊化設計,

當系統(tǒng)規(guī)模擴大，系統(tǒng)可以比較簡單地予以修改、調(diào)整就能適應，充

分滿足用戶的個性化需求，達到良好效果，不會造成硬件和軟件資源

的浪費。

（五）安全性和保密性

信息系統(tǒng)具有完備的用戶權限管理功能，禁止超越權限的操作,

保護原始數(shù)據(jù)，保護系統(tǒng)免遭破壞，信息資源的充分共享，更要注意

信息的保護和隔離，設置系統(tǒng)安全機制，數(shù)據(jù)存取的權限控制。

a.系統(tǒng)開發(fā)人員安全管理

為了保證應用系統(tǒng)的安全，首先應用系統(tǒng)開發(fā)人員必須負責其開

發(fā)內(nèi)容的保密性，不得私自將開發(fā)的相關信息泄漏出去，即使對家人

或開發(fā)團隊中其他開發(fā)人員也不得泄漏，必要時需簽署保密協(xié)議。同

時一，系統(tǒng)開發(fā)人員有責任將開發(fā)的內(nèi)容告訴項目負責人員或開發(fā)小組

負責人員。系統(tǒng)開發(fā)人員在整個開發(fā)的過程中必須完整持續(xù)地進行代

碼錯誤處理所規(guī)定的流程，應對重要的敏感信息進行加密保護，并使

用一些相對復雜的加密和密鑰生成機制，單獨編寫安全性設計說明概

要。

b.系統(tǒng)設計階段

應用系統(tǒng)設計階段應確保敏感數(shù)據(jù)的安全性，確保訪問層的安全

性，確保日志管理機制健全。

c.系統(tǒng)開發(fā)階段

應用系統(tǒng)開發(fā)階段應針對原程序庫和運作程序庫進行嚴格管理;

并通過系統(tǒng)安全開發(fā)工具，對系統(tǒng)的各個版本進行安全審核，以滿足

防御后門代碼或隱藏通道等安全問題的需要，對系統(tǒng)進行嚴格的版本

控制；平臺具有高安全性，應實現(xiàn)對網(wǎng)站后門程序檢測、目錄權限安

全加固、防SQL注入代碼添加、防跨站腳本代碼添加、數(shù)據(jù)庫信息泄

露弱點修復、源代碼泄露弱點修復、后臺地址泄露弱點修復、不安全

的http方法（WebDAV）修復、應用服務器類型和版本泄漏弱點等網(wǎng)

站綜合安全措施。

d.系統(tǒng)安全

本項目平臺的系統(tǒng)安全主要遵循以下原則：

1.所有數(shù)據(jù)實現(xiàn)自動備份功能（在總量的備份基礎上，實現(xiàn)日差

異備份，備份的物理區(qū)域可以是本地備份或異地備份），有方便、可

靠、安全的方法在數(shù)據(jù)災難發(fā)生后實現(xiàn)快速的數(shù)據(jù)恢復；

2.用戶操作進行相應的IP限制；

3.詳細記錄系統(tǒng)安全日志和程序日志；完整記錄所有系統(tǒng)的用戶

訪問以及操作情況。日志分析方便、快速、可行；

4.對有加密需求的字段進行加密；

5.用戶密碼弱的情況下，系統(tǒng)有強制要求用戶修改密碼提示，達

到系統(tǒng)的要求為止。

6.在根據(jù)特定的安全要求下，同時必須遵守國家信息網(wǎng)絡安全管

理相關標準（如：GB/T20269-2006信息安全技術-信息系統(tǒng)安全管

理要求、GB/T20984-2007信息安全技術-信息安全風險評估規(guī)范、

GB/T22239-2008信息安全技術-信息系統(tǒng)安全等級保護基本要求、

GB/T22240-2008信息安全技術-信息系統(tǒng)安全等級保護定級指南、

GA/T388-2002B計算機信息系統(tǒng)安全等級保護管理要求等）。

7.敏感數(shù)據(jù)存儲加密（符合國密要求），數(shù)據(jù)傳輸安全，數(shù)據(jù)展

示脫敏，禁止全表查詢。

8.全站訪問均采用SSL加密方式（證書由采購方提供）。

（六）可管理性、可維護性和獨立性

平臺是由多個部分組成的較為復雜的系統(tǒng)，為了便于系統(tǒng)的日常

運行維護和管理，要求其具有良好的可管理性和可維護性。另外可管

理性和可維護性還包括對平臺的自身。采用先進、開放的體系結(jié)構(gòu)和

結(jié)構(gòu)化、模塊化的設計，充分考慮系統(tǒng)的升級、兼容、處理能力、數(shù)

據(jù)庫、軟件二次開發(fā)等方面的可擴展性和靈活性，以保證在今后可能

出現(xiàn)功能需求變化的情況下，系統(tǒng)可以簡單地予以修改和調(diào)整。系統(tǒng)

的設計和實現(xiàn)應遵循獨立性原則，不依賴非必要的第三方系統(tǒng)，若有

依賴需要及時告知。

（七）前端定制化

前端頁面需要按照采購方需求進行定制化的開發(fā)，包括但不限于

頁面的設計布局、頁面之間的跳轉(zhuǎn)操作、頁面中子控件的位置圖標,

并提供對外頁面可設置為一鍵黑白的功能。

三、基礎數(shù)據(jù)管理平臺

1、平臺性能要求

1.1穩(wěn)定可靠

統(tǒng)一平臺作為未來中心所有業(yè)務系統(tǒng)的統(tǒng)一入口，應該具有強

穩(wěn)定性。保證系統(tǒng)功能的正常運行，在高并發(fā)場景如報名的情況

下，也可以保證系統(tǒng)的穩(wěn)定、流暢和可用。不應該出現(xiàn)一個頁面卡

死、反復刷新或者登錄不成功的情況。如遇系統(tǒng)崩潰，應該及時響

應迅速解決。要求交付前進行性能測試，并提供測試報告。

1.2高效響應

對數(shù)據(jù)、資源進行冷熱物理存儲分離，有效使用匹配基礎設施

資源。在服務器近端測試，在百兆網(wǎng)速的情況下，前臺用戶級應用

型頁面響應時間1秒以內(nèi)，前臺流媒體展現(xiàn)、管理級及后臺用戶級

帶有復雜算法查詢的頁面在3秒以內(nèi)響應。普通接口響應時間平均

應該在200ms左右，QPS應該達到2萬以上，查詢復雜的接口應該

在2秒以內(nèi)，控制在等待期間鏈接不斷，調(diào)用其他系統(tǒng)的接口要有

失敗自動重試的機制。

1.3高并發(fā)率

在互聯(lián)網(wǎng)行業(yè)資源密集型云服務標準的基礎設施環(huán)境達標條件

下，支持1萬次以上接口訪問并發(fā)。要求門戶端實現(xiàn)web訪問與空

間圖像處理服務的業(yè)務分離，提高門戶的訪問速度。

1.4高用戶數(shù)

支持10萬級注冊用戶同時在線，支持不小于500萬的日頁面訪

問量，支持不低于日20萬次的接口調(diào)用。

1.5兼容適應性

瀏覽器兼容性好，支持IE9.0及以上版本、Edge、360極速瀏

覽器、Firefox、Chrome>Safari>手機網(wǎng)頁等主流操作系統(tǒng)（包括

Android、iOS、PC端各操作系統(tǒng)）內(nèi)核瀏覽器應用軟件瀏覽和操

作，在特定業(yè)務應用場景的要求下可支持不同分辨率桌面的自適應

顯示，確保界面顯示規(guī)整，不會出現(xiàn)移位、掛角等情況。平臺級別

能力功能不使用其他任何插件，對于以上瀏覽器無法獨立支撐操作

的功能要求的需要加載特定插件的需要向用戶給出明確提示給用戶

進行有選擇性的下載。

2、項目建設內(nèi)容

2.1統(tǒng)一認證平臺

2.1.1建設目標

隨著應用建設的逐步深入，已經(jīng)建成的和將要建成的各種業(yè)務

部門的應用系統(tǒng)存在不同的身份認證方式，用戶必須記憶不同的密

碼和身份。因此，要建設以認證服務為基礎的統(tǒng)一用戶管理、授權

管理和身份認證體系，將用戶權限信息統(tǒng)一存儲，進行分級授權和

集中身份認證，規(guī)范應用系統(tǒng)的用戶認證方式。提高應用系統(tǒng)的安

全性和用戶使用的方便性，實現(xiàn)全部應用的單點登錄。即用戶經(jīng)統(tǒng)

一應用門戶登錄后，從一個功能進入到另一個功能時，系統(tǒng)平臺依

據(jù)用戶的角色與權限，完成對用戶的一次性身份認證，提供該用戶

相應的活動“場所”、信息資源和基于其權限的功能模塊和工具。

2.1.2建設內(nèi)容以及功能要求

一、注冊、認證和登錄

序號功能具體描述

1新用戶注冊流程（含注冊通道一

中心第三方應用平1.中國內(nèi)地：提供姓名、身份證號（學生）進行

臺）實名認證，輸入就讀學校和年級，再綁定手機

號并獲取驗證碼，完成注冊。

2.港澳臺及其他國家地區(qū)：提供姓名、國籍/地

區(qū)、護照號/通行證號（學生）、出生日期、性

另人就讀學校和年級，綁定手機號并獲取驗證

碼，上傳證件照進入人工審核，完成注冊。

3.所有學員的賬號以身份證號做唯一標識（主

鍵可用UUid）o

4.申請賬號時注意密碼的復雜度，規(guī)定必須為

字母、數(shù)字、特殊字符等組成的結(jié)構(gòu)，保證賬號

密碼的安全性。

5.注冊通道可用戶定義開啟或隱藏。

注冊通道二

5.對接政務服務網(wǎng)的注冊流程應該是先跳轉(zhuǎn)到

政務網(wǎng)注冊，再帶著信息回到本系統(tǒng)，提供默

認密碼為手機號。由于政務網(wǎng)返回的信息可能

只有身份證和手機號等基礎信息，本系統(tǒng)需要

提示并補填其他必要信息后，才允許用戶繼續(xù)

使用本系統(tǒng)。

6.系統(tǒng)管理員可自定義注冊通道的顯示。

2其他用戶注冊提供姓名、身份證、綁定手機號并獲取驗證碼，

完成注冊。（根據(jù)需要可對接到政務服務網(wǎng)等

平臺進行統(tǒng)一的注冊和實名驗證）

3內(nèi)部系統(tǒng)賬戶遷移對對中心內(nèi)部系統(tǒng)已注冊的賬戶進行整體遷入，

接對于原系統(tǒng)缺少的信息如身份證號進行統(tǒng)一數(shù)

據(jù)清洗。使原來已注冊的用戶不必重新注冊，

即可使用本系統(tǒng)。

4登錄認證方式1.用戶名/密碼認證。

2.通過第三方平臺認證，如QQ、微信、釘釘、

支付寶、浙里辦、浙江政務服務網(wǎng)等方式認證。

3.教職工可獨立認證通道。

5單點登錄實現(xiàn)在多個已接入統(tǒng)一平臺的應用系統(tǒng)中，用

戶只需要登錄一次就可以訪問所有平臺上的應

用系統(tǒng)。即：在token過期之前，用戶只要一

次登錄，便可以不需要登錄而直接訪問其他任

何已接入統(tǒng)一平臺的系統(tǒng)。包括輸入統(tǒng)一認證

網(wǎng)站網(wǎng)址、輸入任意一個接入統(tǒng)一平臺的系統(tǒng)

的網(wǎng)址、從其他網(wǎng)站通過超鏈接跳轉(zhuǎn)、從已接

入的系統(tǒng)A跳轉(zhuǎn)到已接入的系統(tǒng)B等。

6token過期時間token過期時間默認為5小時，但需實現(xiàn)可用

戶自定義配置token過期時間。

7用戶注銷/登出/切換1.單點登出。用戶登錄狀態(tài)下，在某一成員網(wǎng)

賬號站或統(tǒng)一平臺進行注銷時，均可實現(xiàn)處處注銷。

2.一個家長對應多個學生的情況下可能需要切

換賬號，切換賬號時可根據(jù)瀏覽器保存的密碼

登錄或重新輸入密碼。需要注意的是，系統(tǒng)賬

號以學員身份證為維度，如果一個家長有多個

孩子，應該是賬號之間的切換，而不是角色之

間的切換，也即不能以家長手機號作為登錄賬

號，而應該使用身份證或字符串作為唯一賬戶

名。同樣是一處切換，處處切換。

8登錄信息安全統(tǒng)一認證平臺對某用戶認證后，返回給其他系

統(tǒng)認證信息即token等，要注意信息的安全性，

謹防被攔截、竊取、篡改信息。

9對接政務服務網(wǎng)實名身份認證需要通過對接政務服務網(wǎng)實現(xiàn)，

意味著新用戶需要跳轉(zhuǎn)過去注冊，下次登錄時

帶著政務服務網(wǎng)的返回信息回到本系統(tǒng)，本系

統(tǒng)依然保留自身的登錄驗證功能，但可對用戶

隱藏，以保證本系統(tǒng)的主動性和可擴展性。

二、用戶角色和應用門戶

序號功能具體描述

1用戶權限1.用戶注冊后擁有已經(jīng)對接到統(tǒng)一平臺的舊系

統(tǒng)的先前就綁定好的權限。

2.用戶初始時擁有中心所有對外開放的系統(tǒng)的

訪問權限，展示包括系統(tǒng)名稱、所屬部門和基

本的簡介等信息并可以點選跳轉(zhuǎn)。其他內(nèi)部系

統(tǒng)，需要由該系統(tǒng)管理員人工為用戶賦予訪問

權限。

3.如果用戶是開發(fā)者，還可以申請接口、數(shù)據(jù)

表。

2用戶權限顆粒度統(tǒng)一平臺給用戶賦予的權限顆粒度僅精確到是

否可以訪問該系統(tǒng)，用戶在第三方系統(tǒng)中更具

體的角色以及第三方系統(tǒng)內(nèi)的權限，不由統(tǒng)一

平臺管理。

3角色和角色組統(tǒng)一平臺級別角色，有開發(fā)者、管理者、應用使

用者等。有管理員分組、各系統(tǒng)管理員分組、開

發(fā)者分組和普通用戶分組，因此一個用戶可以

具有多種角色，一種角色也可以對應多個用戶，

用戶可以根據(jù)角色分組。

4權限管理1.用戶-系統(tǒng)管理的模塊，管理員可以查看其管

轄范圍內(nèi)的所有用戶的系統(tǒng)權限，并可以對訪

問權限進行分配和回收。實現(xiàn)用戶與角色、用

戶組與角色、用戶組與角色的授權，支持根據(jù)

用戶屬性自動授權與收回。

2.除了角色授權以外，管理員可為本單位賬號

進行分組，對組下賬號的個人門戶統(tǒng)一添加可

用應用。

3.對于異常用戶，管理員有權限對其賬號進行

凍結(jié)，用戶可以自己申請解除凍結(jié)，由系統(tǒng)管

理員進行解凍。

4.具有黑名單功能。

5.對于異常登錄用戶，可周期性暫緩登錄，可

配置。

5應用門戶用戶從基礎平臺登錄成功后，顯示用戶有權限

訪問的業(yè)務系統(tǒng)列表，每個系統(tǒng)以圖標和系統(tǒng)

名稱的形式顯示，點擊圖標即可進入該系統(tǒng)中。

在應用門戶里具有應用的消息數(shù)提示，訪問后

可清空。同時應具備應用消息內(nèi)容的列表接口，

必要時可進行內(nèi)容顯示。

6應用超市管理員可管理本單位的基礎應用、自建應用、

第三方應用，支持應用啟用/禁用功能。系統(tǒng)支

持應用分類管理，以便分類查看。

三、用戶中心和基礎數(shù)據(jù)管理

序號功能具體描述

1用戶中心1.信息修改：系統(tǒng)頁面右上角的用戶圖標可點

擊，點擊后進入用戶中心。顯示內(nèi)容包括用戶

自己的個人信息等，用戶信息的更新、修改密

碼、找回密碼操作也在用戶中心進行，找回密

碼根據(jù)個人信息中填寫的手機短信驗證碼、郵

箱郵件驗證碼的方式進行找回。

2.消息查看：在收到消息通知如管理員收到訪

問系統(tǒng)權限申請的時候，系統(tǒng)右上方的用戶圖

標應該有紅色小點或數(shù)字，以表示用戶有未讀

消息或未處理事項，點進去可以進入消息管理

頁面進行處理，閱讀完所有未讀消息后紅點消

失。可以查看自己已處理和未處理的所有待辦

事項列表。（消息和待處理事項的維度為統(tǒng)一

認證平臺，和第三方系統(tǒng)消息無關聯(lián)）

3.切換賬號：如果綁定了其他賬號，系統(tǒng)支持

賬號一鍵切換登錄其他賬號個人門戶。具體實

現(xiàn)見上文所述。

4.權限管理：可以查看自己擁有的系統(tǒng)列表和

權限。

2基礎數(shù)據(jù)管理1.自動更新：如學生的年級變化、年級情況等

信息要隨著時間的增長而自動更新。

2.互綁定更新：其他系統(tǒng)更新的數(shù)據(jù)，通過數(shù)

據(jù)交換平臺實現(xiàn)同步或異步的更新。

3.提示更新：如升班等情況，彈出提醒詢問是

否更新，點擊一鍵更新。提供批量更新的功能。

4.學員用戶數(shù)據(jù)，根據(jù)最后使用時間等要素進

行判斷是否將該用戶數(shù)據(jù)歸檔至歷史數(shù)據(jù)表，

不作為熱數(shù)據(jù)繼續(xù)管理。

5.通用數(shù)據(jù)基礎化。保證數(shù)據(jù)的基礎化和可擴

展性，我們只保存和提供最原始數(shù)據(jù)，其他細

分結(jié)構(gòu)則由各業(yè)務系統(tǒng)自定。

6.所有涉及到的基礎數(shù)據(jù)都要進行數(shù)據(jù)清洗和

遷移的工作，包括但不限于學生、教職工、教

室、組織架構(gòu)、收入等信息。

四、非功能性要求

1.易接入性和非侵入性：使其他業(yè)務系統(tǒng)可以通過很少的時間

代價和較少的開發(fā)代碼改動，而完成對統(tǒng)一平臺的對接。對于使用

不同編程語言開發(fā)的系統(tǒng)，都要具有對接兼容性。提供標準的接入

接口等，應該提供詳盡的技術文檔和視頻等進行指導。考慮包括客

戶端、app應用端系統(tǒng)的對接。

2.高并發(fā)下強穩(wěn)定性：統(tǒng)一平臺作為未來中心所有業(yè)務系統(tǒng)的

統(tǒng)一入口，應該具有強穩(wěn)定性。保證系統(tǒng)功能的正常運行，在幾十

萬高并發(fā)的請求場景下，也可以保證系統(tǒng)的穩(wěn)定、流暢和可用。如

遇系統(tǒng)崩潰，應該及時響應迅速解決。要求交付前進行性能測試，

并提供測試報告。

3.安全性：在平臺的設計中，既要充分考慮信息資源的共享，

更要注意信息資源的保護和隔離，應分別針對不同的應用和不同的

網(wǎng)絡通信環(huán)境，采取不同的措施，包括用戶、數(shù)據(jù)、運行的安全性

等。要求對數(shù)據(jù)庫提供靈活的備份和恢復機制，確保系統(tǒng)發(fā)生故障

時能及時恢復，業(yè)務功能不受影響。

4.數(shù)據(jù)展示脫敏和查詢頁面緩存：數(shù)據(jù)展示的時候應該考慮脫

敏，尤其是公開的頁面中、日志展示中，如身份證和手機號的展示

就要考慮根據(jù)查看權限的不同進行脫敏處理。對于系統(tǒng)中所有查詢

相關的頁面，都應該做成分頁查詢，并且有緩存，避免短時間內(nèi)多

次直連數(shù)據(jù)庫，查詢頁面也應該設置默認的查詢條件，不能任何條

件都不輸入而進行全表查詢，以免造成系統(tǒng)崩潰。

5.統(tǒng)一平臺的監(jiān)控：提供完善的監(jiān)控功能，可對平臺內(nèi)的用

戶、應用、服務進程和服務器硬件資源進行實時監(jiān)控，且可通過各

類圖表進行直觀的結(jié)果展現(xiàn)?？蓪τ脩羯矸輲ぬ柕墓芾怼⑹跈嘁约?/p>

用戶的認證行為中可能存在的問題進行審計一，所有操作均日志記

錄，日志必須可視化且易看，并提供根據(jù)時間、關鍵字、log等級

查詢的功能。能夠?qū)γ總€角色管理員的操作行為、用戶自助管理行

為和用戶登錄訪問行為進行記錄。代碼中關鍵操作步驟必須打

log,info、warn、error幾個等級的日志都應有所涉及。對于異常

行為應有告警機制，及時通知各系統(tǒng)的管理員，并提供基本的一鍵

解決措施等。（具體需求見下文的監(jiān)控中心和日志管理模塊）

6.平臺平穩(wěn)和備用方案：作為所有業(yè)務系統(tǒng)的基礎平臺，應該

具有備用方案和策略，當系統(tǒng)因各種原因而崩潰時，應該啟動雙活

備份等方案，使登錄和注冊等功能正常使用，不影響其他業(yè)務系統(tǒng)

的正常使用。

8.易擴展性：留好對接其他統(tǒng)一認證平臺的接口，如果后面需

要對接上級單位的統(tǒng)一認證平臺，希望做到較少開發(fā)量和對接成

本，以及只對本基礎平臺進行修改，而對所有已接入的其他業(yè)務系

統(tǒng)透明無感，不需要它們再次對接，也不應該影響其他系統(tǒng)的正常

登錄注冊和運行。

9.提供開發(fā)文檔：包括接入流程、認證配置、創(chuàng)建應用流程、

申請和上傳接口流程、消息模板配置、開發(fā)者規(guī)范等。需要實現(xiàn)多

種開發(fā)語言的第三方系統(tǒng)對接，包括但不限于Java、Python、

C++、C、Go、Php等。

2.2開發(fā)者門戶

2.2.1建設目標

開發(fā)者門戶包括開發(fā)者門戶和接口管理兩個模塊，如上所

述，統(tǒng)一平臺具有三種角色，管理員、開發(fā)者和應用訪問者，開發(fā)

者作為各接入業(yè)務系統(tǒng)的開發(fā)管理員，應具有單獨的模塊對其功能

進行管理，包括接口的開發(fā)、申請和管理、部門/單位內(nèi)系統(tǒng)和應用

的上線和管理等，實現(xiàn)對接口的統(tǒng)一管理。

2.2.2建設內(nèi)容以及功能要求

一、開發(fā)者門戶

序號功能具體描述

1開發(fā)者注冊系統(tǒng)支持專業(yè)公司或團隊個人在平臺上完成開

發(fā)者賬號注冊，成為第三方開發(fā)者。

2系統(tǒng)注冊開發(fā)者可通過平臺提交系統(tǒng)注冊申請，并根據(jù)

本用戶單位部門機構(gòu)信息選擇所屬部門，該系

統(tǒng)應用上線后可在該單位應用超市中查看。

3應用添加開發(fā)者可在注冊完成的系統(tǒng)內(nèi)添加應用，并且

為了數(shù)據(jù)安全考慮，應設置應用的服務器出口

ip，接口需校驗調(diào)用ip才可獲取數(shù)據(jù)。

4數(shù)據(jù)權限系統(tǒng)默認賦予應用所屬角色組數(shù)據(jù)權限，系統(tǒng)

管理員可管理控制數(shù)據(jù)范圍，保障數(shù)據(jù)在規(guī)定

范圍內(nèi)傳輸。

5消息模板系統(tǒng)默認提供消息接口權限，但寫入消息時，

必須先申請消息模板。消息是為了通知其他接

口對接方或相關系統(tǒng)有訂閱內(nèi)容發(fā)生改變，通

過審核后即可使用。

6應用管理開發(fā)者可申請應用上線。已上線的應用需管理

員撤銷審核后才可下線。上線應用可在應用超

市的相關應用類型中查看。相應機構(gòu)的管理員

可下發(fā)應用權限，使應用可在授權賬號的個人

門戶中查看。管理員可設置應用暫停使用，使

在應用門戶中不可點選。（應用包括但不限于

中心其他部門或處室的系統(tǒng)，還應包括小功能

模塊組件，可供展示和調(diào)用）

7發(fā)送信息接口在開發(fā)者門戶中提供一個單獨頁面，作為發(fā)送

信息接口的申請和管理。第三方系統(tǒng)可進行接

口調(diào)用申請，包括發(fā)送短信、app、郵箱等幾個

渠道。目的是本系統(tǒng)作為一個網(wǎng)關，向應用方

提供統(tǒng)一的消息發(fā)送接口，使應用方開發(fā)者們

不用考慮發(fā)送消息底層渠道變更的情況。

二、接口管理

序號功能具體描述

1接口上傳1.上傳前需要綁定平臺中已有的數(shù)據(jù)表數(shù)據(jù)

源，可選之前添加的數(shù)據(jù)庫連接信息，或新建數(shù)

據(jù)表。發(fā)布接口時可以綁定過去已開發(fā)好的接

口，也可以新創(chuàng)建接口，通過配置或?qū)憇ql的

方式，從已有數(shù)據(jù)庫表中獲取字段，配置好接口

后，點擊發(fā)布，即上傳成功新接口。

2.上傳接口時可以選擇接口的生效時間段，并

且可配置接口的日/分鐘可調(diào)用次數(shù)，每個接口

日/分鐘調(diào)用次數(shù)最多不能超過1萬〃千次。

2接口維護實現(xiàn)接口的添加、發(fā)布、取消發(fā)布、測試、版本

更新、刪除下架的全生命周期管理。滿足

RESTfuKhttps傳輸協(xié)議，能設置接口的可調(diào)

用次數(shù)。

3接口詳情接口的信息應包括接口名稱、請求方式、url、

生產(chǎn)者信息、輸入輸出字段及其類型、數(shù)據(jù)來源

表、接口概述等。發(fā)布接口時必須具備這些信

息，如果后期修改，也要及時更新信息，然后自

動觸發(fā)消息中心的通知機制，對該接口的所有

訂閱者進行通知。

4接口查詢1.開發(fā)者可檢索平臺上所有開放的接口，并可

對接口基本信息進行預覽。開發(fā)者通過開發(fā)者

賬號登錄后可申請調(diào)用接口。

2.用戶/開發(fā)者可以對自己擁有的接口進行分

類整理，如新建文件夾移動保存等。接口也可以

樹形結(jié)構(gòu)的方式進行分層展示。

5接口申請開發(fā)者可以檢索到數(shù)據(jù)平臺的所有數(shù)據(jù)表，展

示出來的只是表名和簡介，開發(fā)者可根據(jù)自己

的需求向表的所有者申請訪問權限，經(jīng)表所有

者和系統(tǒng)管理員審批通過后可以看到表的全部

信息。在擁有數(shù)據(jù)表的訪問權限后，對自己所需

的接口進行申請。申請方式有兩種：

1.開發(fā)者和對方系統(tǒng)直接提出需求，由對方系

統(tǒng)的開發(fā)者直接提供所需接口。申請流程是先

由接口的提供者在已發(fā)布的接口上為新消費者

添加訪問權限，再流轉(zhuǎn)到系統(tǒng)總管理員進行復

核，最后擁有訪問此接口的權限。此時不是必須

擁有訪問對方數(shù)據(jù)表的權限，只要能通過協(xié)商

好的接口獲取到自己所需的數(shù)據(jù)即可。

2.開發(fā)者先對數(shù)據(jù)庫表進行訪問權限申請，此

時所需的數(shù)據(jù)不一定在同一張表，甚至不一定

在同一個業(yè)務系統(tǒng)（庫）中，開發(fā)者可根據(jù)幾張

表的字段進行手動配置，如當A表的x字段和

B表的y字段相等時，返回A、B表中的哪幾個

字段等，通過配置的方式自動生成所需接口。配

置可以通過寫sql或者其他方式實現(xiàn)。

應用場景少但保留透傳功能，即不保存在交換

中心雙方直接通過接口傳遞數(shù)據(jù)，此申請必須

通過管理員審核，并且無特殊情況不應該通過

審核。

3.第三方應用開發(fā)的接口，通過接口申請，由管

理員審核后，存入接口中心，由接口中心統(tǒng)一管

理與代理。

6接口管理1.管理者可以查看到系統(tǒng)中所有開發(fā)者和接口

的對應關系列表，并進行增刪改的管理。

2.管理者可以看到接口的監(jiān)控信息，如接口的

申請次數(shù)、每日調(diào)用次數(shù)、響應時間、是否出現(xiàn)

擁塞等情況。

7接口權限提供接口預覽功能，開發(fā)者申請接口，管理員審

核通過后方可調(diào)用。

8接口時效生產(chǎn)者在上傳接口的時候，要指定接口的上架

時間和下架時間，超過下架時間后接口即變?yōu)?/p>

不可調(diào)用的狀態(tài)。消費者申請接口也有有效時

間，在生效時間窗口內(nèi)方可調(diào)用接口，過了時效

期要重新進行接口的權限申請。

9接口測試生產(chǎn)者、消費者都可以在系統(tǒng)頁面中對接口進

行測試，以設定的請求地址、請求方式、請求頭

請求體發(fā)起請求時，測試連通性等其他信息。

10接口調(diào)用次數(shù)可設置接口在一天內(nèi)或一分鐘內(nèi)的被調(diào)用次

數(shù)，防止被頻繁調(diào)用或惡意攻擊。

三、非功能性要求

1.接口管理中心的可擴展性：面對高速發(fā)展的信息化建設，不

斷有新的應用系統(tǒng)接口在服務訂閱中心中創(chuàng)建和第三方接口加入到

服務訂閱中心中，要求接口服務總線具有高擴展性和增長性的接口

創(chuàng)建和發(fā)布能力，讓各種業(yè)務數(shù)據(jù)可以方便的在服務訂閱中心中通

過接口方式發(fā)布，迅速為用戶提供服務。

2.接口傳輸數(shù)據(jù)安全性：數(shù)據(jù)格式易于傳輸，能夠?qū)崿F(xiàn)各個應

用系統(tǒng)之間的同步/異步信息交換，格式技術兼容各種網(wǎng)絡系統(tǒng)和通

訊協(xié)議。交換的數(shù)據(jù)文檔需要基于應用系統(tǒng)之間約定的規(guī)則進行驗

證，要能建立數(shù)據(jù)格式、數(shù)據(jù)內(nèi)容、網(wǎng)絡傳輸?shù)炔煌瑢用娴陌踩?/p>

護機制。平臺對外提供的API需使用信息安全算法進行保護。

3.所有的接口申請、數(shù)據(jù)申請、數(shù)據(jù)庫表申請等都需要在申請

前簽訂協(xié)議，通過頁面彈框等方式進行簽署，本系統(tǒng)進行持久化存

儲。協(xié)議的具體內(nèi)容由我方提供。

2.3消息服務中心

2.3.1建設目標

消息服務中心分為消息中心和消息機制兩種，其中消息中心

是可以向任何用戶發(fā)送任何一種消息（文本、圖片、語音、視頻

等），并能有效到達任何接收終端（手機短信、郵件、站內(nèi)信、釘

釘?shù)龋┑南⑼扑头掌脚_?？晒?jié)約通信成本，同時對消息發(fā)送的

及時性、統(tǒng)一性、嚴謹性進行統(tǒng)一管理和審計。消息中心將消息規(guī)

整化處理，提供消息的采集、內(nèi)容規(guī)整、分布式調(diào)度、消息規(guī)則配

置、消息內(nèi)容審計，還能夠進行微服務化、分布式的消息處理以及

文件、音頻、視頻、新聞、公文、多媒體等多種消息格式處理。消

息機制是一種技術實現(xiàn)方法，通過消息隊列、消息循環(huán)（分發(fā)）和

消息處理實現(xiàn)數(shù)據(jù)的傳輸，主要應用在數(shù)據(jù)交換和消息處理的場景

中。

2.3.2建設內(nèi)容以及功能要求

一、消息中心

序號功能具體描述

1消息模板可自定義消息的發(fā)送模板，并提供消息管理頁

面，對所有已讀、未讀消息和消息模板進行統(tǒng)

一管理。

2消息推送根據(jù)用戶訂閱，推送如接口更新、權限申請、站

內(nèi)通信、監(jiān)控預警、訂閱信息、重要數(shù)據(jù)變動、

觸發(fā)預定規(guī)則閾值等消息。提供消息推送供各

應用系統(tǒng)調(diào)用，實現(xiàn)消息發(fā)送和管理。

3多渠道推送實現(xiàn)消息的收發(fā)，接入手機短信、站內(nèi)信、釘

釘、微信等通道，實現(xiàn)消息一鍵發(fā)布，全終端接

收。允許管理員配置消息發(fā)送間隔，以及單個

用戶每天被發(fā)送信息的上限次數(shù)。

4消息傳輸安全支持接口數(shù)據(jù)加密傳輸，保證數(shù)據(jù)能在客戶端

與服務訂閱中心服務器之間安全通信，接口的

不同調(diào)用者可采用的不同的加密技術。

5第三方系統(tǒng)消息聚集所有接入基礎數(shù)據(jù)平臺的第三方系統(tǒng)，將自己

系統(tǒng)的消息通知以接口、消息機制等形式推送

給本平臺，本平臺根據(jù)消息接收者進行分類匯

總，使每個用戶可以在個人門戶的消息中心看

到所有第三方系統(tǒng)發(fā)給該用戶的消息，并可以

通過鏈接跳轉(zhuǎn)到消息對應的系統(tǒng)進行處理。從

而完成消息的匯總和統(tǒng)一處理。

二、消息機制

消息機制由消息隊列、消息循環(huán)和消息處理三大塊組成，消息

隊列應用在當不需要立即獲得結(jié)果，但是并發(fā)量又需要進行控制的

場景下，主要解決了應用耦合、異步處理、流量削鋒等問題?？梢?/p>

用于：應用耦合，多應用間通過消息隊列對同一消息進行處理，避

免調(diào)用接口失敗導致整個過程失??；異步處理，多應用對消息隊列

中同一消息進行處理，應用間并發(fā)處理消息，相比串行處理，減少

處理時間；限流削峰，廣泛應用于秒殺或搶購活動中，避免流量過

大導致應用系統(tǒng)掛掉的情況；消息驅(qū)動的系統(tǒng)，系統(tǒng)分為消息隊

列、消息生產(chǎn)者、消息消費者，生產(chǎn)者負責產(chǎn)生消息，消費者（可

能有多個）負責對消息進行處理。以上幾種場景在本系統(tǒng)中都可能

有應用，尤其是應用間傳遞消息和數(shù)據(jù)等，根據(jù)實際開發(fā)情況引入

該技術，數(shù)據(jù)交換相關的具體需求見下文數(shù)據(jù)管理中心模塊。

2.4監(jiān)控中心

2.4.1建設目標

基礎數(shù)據(jù)平臺應具有獨立且完備的監(jiān)控中心模塊，提供全鏈

路和全方面的監(jiān)控功能，實現(xiàn)對平臺內(nèi)的用戶、應用、服務進程和

服務器硬件資源的實時監(jiān)控，且可通過各類圖表進行直觀的結(jié)果展

現(xiàn)，并提供專門的日志查詢頁面，供具有權限的用戶檢索和查看所

有日志，并提供按照日期、關鍵字和日志等級查詢幾項功能，方便

后續(xù)運維和查看問題，保障系統(tǒng)的安全。

對于一些常用的監(jiān)控數(shù)據(jù)進行可視化展示，使系統(tǒng)的開發(fā)人員

可以及時關注到異常數(shù)據(jù)和關鍵性數(shù)據(jù)。比如數(shù)據(jù)的傳輸速度、某

系統(tǒng)數(shù)據(jù)的訪問頻度、數(shù)據(jù)傳輸時的出錯報告及重試次數(shù)、信道的

占用比例、數(shù)據(jù)交換平臺的健康指數(shù)以及系統(tǒng)每日的運行日志。

可以用Grafana、Prometheus等開源監(jiān)控可視化工具進行展

示，也可用其他類似方式實現(xiàn)，并通過Alertmanager等工具進行告

警，告警可以使用消息中心通過站內(nèi)信、郵件、QQ、釘釘?shù)龋ň唧w

方式應該在訂閱數(shù)據(jù)時選擇）其他方式通知相應訂閱者、管理員。

2.4.2建設內(nèi)容以及功能要求

一、監(jiān)控范圍

序號功能具體描述

1系統(tǒng)應用監(jiān)控對于對接在統(tǒng)一平臺的系統(tǒng)應用，監(jiān)控對接情

況是否有異常，能否通過統(tǒng)一平臺正常跳轉(zhuǎn)訪

問等。

2應用操作監(jiān)控對應用操作層面的行為進行監(jiān)控，比如申請系

統(tǒng)、應用、訪問權限、下線系統(tǒng)等，并能夠?qū)γ?/p>

個角色管理員的操作行為、用戶自助管理行為

和用戶登錄訪問行為進行記錄。

3服務器監(jiān)控可實時監(jiān)控認證服務器、緩存服務器的運行及

負載情況，監(jiān)控范圍包括磁盤、CPU運行情況、

網(wǎng)絡輸入與輸出、內(nèi)存占用率等。

4數(shù)據(jù)庫監(jiān)控監(jiān)控統(tǒng)一身份認證數(shù)據(jù)庫連接情況、SQL執(zhí)行響

應時間、連接數(shù)等信息，通過監(jiān)控及時發(fā)現(xiàn)業(yè)

務處理過程中數(shù)據(jù)庫相關問題。

5數(shù)據(jù)質(zhì)量監(jiān)控可監(jiān)測從各個業(yè)務系統(tǒng)匯集的原始數(shù)據(jù)，通過

自動/手動方式發(fā)現(xiàn)庫中存在的數(shù)據(jù)質(zhì)量問題。

系統(tǒng)提供非空檢查、外鍵檢查、長度檢查、一致

性檢查、自定義規(guī)則檢查等監(jiān)測方式。

6數(shù)據(jù)一致性監(jiān)控監(jiān)控數(shù)據(jù)記錄的規(guī)范和數(shù)據(jù)是否符合邏輯。規(guī)

范指的是，一項數(shù)據(jù)存在它特定的格式；邏輯

指的是，多項數(shù)據(jù)間存在著固定的邏輯關系。

7接口監(jiān)控每次接口調(diào)用時記錄相應的信息，以便進行統(tǒng)

計查詢，用于查詢具體的調(diào)用記錄信息。

8數(shù)據(jù)傳輸監(jiān)控對于在數(shù)據(jù)管理平臺上進行數(shù)據(jù)傳輸進行監(jiān)

控，數(shù)據(jù)傳輸出現(xiàn)問題如卡頓或反復重傳失敗。

2.5日志管理

2.5.1建設目標

平臺應提供完備安全的審計日志機制，包括人員調(diào)整日志，資

源調(diào)整日志等，并提供完整的統(tǒng)計分析功能，對系統(tǒng)操作進行完整

記錄，作為監(jiān)控中心所監(jiān)控行為的記錄和展示，并提供單獨的日志

管理頁面，以便獲取整個應用系統(tǒng)的運行情況。

系統(tǒng)日志記錄用戶操作和系統(tǒng)自動執(zhí)行的各種操作，即2.4節(jié)

監(jiān)控中心所述的監(jiān)控范圍，在日志管理頁面中對日志進行增刪改查

等管理操作，而不需要去系統(tǒng)文件夾中查詢?nèi)罩?，實現(xiàn)日志的可視

化，并實現(xiàn)對日志進行查看、檢索和導出等。

2.5.2建設內(nèi)容以及功能要求

、日志打印要求

序號功能具體描述

1日志打印顆粒度1.查詢操作的日志不打印查詢頁面所有信息詳

情，只打印"XX用戶XX時間進行了XX查詢”0

2.所有寫入操作、接口調(diào)用、寫DB、修改狀態(tài)

都必須打印日志，標明操作人、操作內(nèi)容和操作

時間。

3.上節(jié)2.4.2中監(jiān)控范圍的應用操作監(jiān)控、數(shù)

據(jù)傳輸監(jiān)控、接口監(jiān)控、數(shù)據(jù)質(zhì)量監(jiān)控等的關鍵

步驟也應進行日志打印。其他無法用日志打印

表示的，可以用可視化等的方式展示。

2輸入輸出日志所有調(diào)用本系統(tǒng)的接口或本系統(tǒng)調(diào)用的接口，

系統(tǒng)間通過基礎數(shù)據(jù)平臺進行接觸的操作都以

切面的方式攔截，進行自動的日志打印。打印格

式遵循我方要求的日志格式規(guī)范。

3日志查詢速度為了不影響系統(tǒng)的正常運行，消費到日志后，應

存儲在如Elasticsearch等的數(shù)據(jù)庫中，再通

過日志管理頁面進行展示，實現(xiàn)高效查詢。

4查詢條件日志查詢的條件提供包括日期時間段、關鍵字、

日志等級三種。不輸入查詢條件時展示最新日

志信息，實時性要求不高。

5內(nèi)容格式每條日志的詳細信息包括：日志類型（用戶/系

統(tǒng)操作）、操作用戶/系統(tǒng)、被操作對象、操作

時間、具體內(nèi)容、執(zhí)行結(jié)果（成功和失敗）等。

另，還有程序運行過程中打印的系統(tǒng)日志。

6查看權限具有日志查看權限的用戶可查看到日志信息。

7持久化時間日志應保存至少六個月以上，保證問題的可追

溯性。

8日志導出管理員可以對日志進行導出，可根據(jù)技術實現(xiàn)