青少年活动中心基础数据平台及数字驾驶舱项目建设方案

青少年活动中心基础数据平台及数字驾驶舱项目

建设方案

目录

一、项目概况..............................................................4

二、项目建设原则..........................................................4

（-）标准化、规范性和开放性.............................................4

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

（三）可靠性、稳定性和容错性.............................................5

（四）可扩展性和易升级性.................................................5

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

（六）可管理性、可维护性和独立性.........................................7

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

三、基础数据管理平台......................................................8

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

1.1稳定可靠............................................................8

1.2高效响应............................................................8

L3高并发率............................................................9

1.4高用户数............................................................9

1.5兼容适应性.........................................................9

2、项目建设内容........................................................10

2.1统一认证平台......................................................10

2.2开发者门户........................................................17

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

2.4监控中心..........................................................24

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

2.6数据管理中心......................................................27

2.7对接移动端APP....................................................40

四、数字驾驶舱...........................................................40

1、项目要求............................................................40

2、项目需求............................................................40

3、系统交互............................................................41

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

4.1登录/权限..........................................................42

4.2数据管理...........................................................43

4.3仪表盘管理.........................................................44

4.4仪表盘场景.........................................................47

4.5业务预警...........................................................49

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

4.7监控中心...........................................................50

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

一、项目概况

根据杭州青少年活动中心十四五规划，为了聚焦数字赋能，提升

信息化水平，应整合中心现有信息化平台，以基础数据管理平台为核

心，以智慧治理、智慧育人、智慧服务为建设内容，以改善基础设施、

挖掘应用场景、提升信息素养为途径，着力构建中心可持续发展的

“1+3+3”信息化建设新体系，努力建成服务智慧化、决策数据化、

管理精准化、育人多元化的智慧少年宫。

基础数据管理平台是信息化平台的基础，是打造智慧少年宫的基

石。目标是在现有数据特征和硬件设备的基础上，构建权限统一、集

约高效、数据易控的业务中枢平台，实现对杭州青少年活动中心各核

心业务系统的有效支撑，有力发展各方面重点应用，实现“统一架构、

统一用户、统一门户、统一数源”的整体架构体系。

数字驾驶舱通过采集各应用平台数据，利用云计算、大数据、人

工智能、区块链等新技术，将数据进行统一管理、集中调度、动态感

知、智能分析，使之成为中心各项工作决策的“分析仪”和“指南针”，

用科学、可靠、有效的数据分析带动管理由人力密集向人机交互转型,

由经验判断向数据实证转变，提高大数据支撑管理、决策、公共服务

的整体效能，为全面构建中心智能化的治理、育人、服务新体系提供

有力支撑。

二、项目建设原则

（一）标准化、规范性和开放性

全中心的信息化建设是一个庞大的系统工程，其体系的设计、系

统的实施等必须遵循一系列的规范、标准，确保各个分系统的有效协

调，整个系统能安全地互联互通、信息共享。设计、开发和管理维护

各阶段的技术文档要完整、规范、条理清晰。作为一个开放的且符合

业界主流技术标准的系统平台，对网络的硬件环境，通信环境，软件

环境，操作平台之间的依赖小。

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

系统设计既要采用先进技术和系统工程方法，又要注意技术的可

行性和实用性，方法的正确性。在整个系统的生命周期内，系统应能

够不断完善、扩充、更新，使功能愈来愈丰富，性能愈来愈稳定，使

用愈来愈方便。系统具备可伸缩的架构，设计既要采用先进技术和系

统工程方法,还要注意技术的合理性,技术的可行性,方法的正确性。

采用面向对象的组件技术开发，着重于开发构成应用程序“业务对象”

的可重复使用的组件，利用这些组件顺利地建立分布式应用程序。

（三）可靠性、稳定性和容错性

在考虑技术先进性和开放性的同时，还应从系统结构，技术措施，

系统管理等方面着手，确保系统运行的可靠性和稳定性，达到最大的

平均无故障时间。运行稳定、安全可靠、实用性强，在访问高峰期系

统的接口访问命中率达到99%以上。尤其是在报名期间，要维持系统

的强稳定性和易用性，避免出现页面卡死、不可用的情况。提高应用

数据收集和应用统计的稳定性，实现日志收集与数据分析的异步处理,

建立数据仓库，实现统计数据的唯一源获取，避免前、后台、用户个

人中心统计数据不一致。

为适应IPv4和IPv6网络环境，本项目实施需满足IPv4和IPv6

网络环境下部署，且所有功能均可正常运行。

（四）可扩展性和易升级性

为适应应用不断拓展的需要，应用平台的软硬件环境必须有良好

的平滑可扩充性。要提供简便、规范、畅通的基础数据服务。能够最

大限度地适应未来业务发展的变化。整个系统低耦合、模块化设计,

当系统规模扩大，系统可以比较简单地予以修改、调整就能适应，充

分满足用户的个性化需求，达到良好效果，不会造成硬件和软件资源

的浪费。

（五）安全性和保密性

信息系统具有完备的用户权限管理功能，禁止超越权限的操作,

保护原始数据，保护系统免遭破坏，信息资源的充分共享，更要注意

信息的保护和隔离，设置系统安全机制，数据存取的权限控制。

a.系统开发人员安全管理

为了保证应用系统的安全，首先应用系统开发人员必须负责其开

发内容的保密性，不得私自将开发的相关信息泄漏出去，即使对家人

或开发团队中其他开发人员也不得泄漏，必要时需签署保密协议。同

时一，系统开发人员有责任将开发的内容告诉项目负责人员或开发小组

负责人员。系统开发人员在整个开发的过程中必须完整持续地进行代

码错误处理所规定的流程，应对重要的敏感信息进行加密保护，并使

用一些相对复杂的加密和密钥生成机制，单独编写安全性设计说明概

要。

b.系统设计阶段

应用系统设计阶段应确保敏感数据的安全性，确保访问层的安全

性，确保日志管理机制健全。

c.系统开发阶段

应用系统开发阶段应针对原程序库和运作程序库进行严格管理;

并通过系统安全开发工具，对系统的各个版本进行安全审核，以满足

防御后门代码或隐藏通道等安全问题的需要，对系统进行严格的版本

控制；平台具有高安全性，应实现对网站后门程序检测、目录权限安

全加固、防SQL注入代码添加、防跨站脚本代码添加、数据库信息泄

露弱点修复、源代码泄露弱点修复、后台地址泄露弱点修复、不安全

的http方法（WebDAV）修复、应用服务器类型和版本泄漏弱点等网

站综合安全措施。

d.系统安全

本项目平台的系统安全主要遵循以下原则：

1.所有数据实现自动备份功能（在总量的备份基础上，实现日差

异备份，备份的物理区域可以是本地备份或异地备份），有方便、可

靠、安全的方法在数据灾难发生后实现快速的数据恢复；

2.用户操作进行相应的IP限制；

3.详细记录系统安全日志和程序日志；完整记录所有系统的用户

访问以及操作情况。日志分析方便、快速、可行；

4.对有加密需求的字段进行加密；

5.用户密码弱的情况下，系统有强制要求用户修改密码提示，达

到系统的要求为止。

6.在根据特定的安全要求下，同时必须遵守国家信息网络安全管

理相关标准（如：GB/T20269-2006信息安全技术-信息系统安全管

理要求、GB/T20984-2007信息安全技术-信息安全风险评估规范、

GB/T22239-2008信息安全技术-信息系统安全等级保护基本要求、

GB/T22240-2008信息安全技术-信息系统安全等级保护定级指南、

GA/T388-2002B计算机信息系统安全等级保护管理要求等）。

7.敏感数据存储加密（符合国密要求），数据传输安全，数据展

示脱敏，禁止全表查询。

8.全站访问均采用SSL加密方式（证书由采购方提供）。

（六）可管理性、可维护性和独立性

平台是由多个部分组成的较为复杂的系统，为了便于系统的日常

运行维护和管理，要求其具有良好的可管理性和可维护性。另外可管

理性和可维护性还包括对平台的自身。采用先进、开放的体系结构和

结构化、模块化的设计，充分考虑系统的升级、兼容、处理能力、数

据库、软件二次开发等方面的可扩展性和灵活性，以保证在今后可能

出现功能需求变化的情况下，系统可以简单地予以修改和调整。系统

的设计和实现应遵循独立性原则，不依赖非必要的第三方系统，若有

依赖需要及时告知。

（七）前端定制化

前端页面需要按照采购方需求进行定制化的开发，包括但不限于

页面的设计布局、页面之间的跳转操作、页面中子控件的位置图标,

并提供对外页面可设置为一键黑白的功能。

三、基础数据管理平台

1、平台性能要求

1.1稳定可靠

统一平台作为未来中心所有业务系统的统一入口，应该具有强

稳定性。保证系统功能的正常运行，在高并发场景如报名的情况

下，也可以保证系统的稳定、流畅和可用。不应该出现一个页面卡

死、反复刷新或者登录不成功的情况。如遇系统崩溃，应该及时响

应迅速解决。要求交付前进行性能测试，并提供测试报告。

1.2高效响应

对数据、资源进行冷热物理存储分离，有效使用匹配基础设施

资源。在服务器近端测试，在百兆网速的情况下，前台用户级应用

型页面响应时间1秒以内，前台流媒体展现、管理级及后台用户级

带有复杂算法查询的页面在3秒以内响应。普通接口响应时间平均

应该在200ms左右，QPS应该达到2万以上，查询复杂的接口应该

在2秒以内，控制在等待期间链接不断，调用其他系统的接口要有

失败自动重试的机制。

1.3高并发率

在互联网行业资源密集型云服务标准的基础设施环境达标条件

下，支持1万次以上接口访问并发。要求门户端实现web访问与空

间图像处理服务的业务分离，提高门户的访问速度。

1.4高用户数

支持10万级注册用户同时在线，支持不小于500万的日页面访

问量，支持不低于日20万次的接口调用。

1.5兼容适应性

浏览器兼容性好，支持IE9.0及以上版本、Edge、360极速浏

览器、Firefox、Chrome>Safari>手机网页等主流操作系统（包括

Android、iOS、PC端各操作系统）内核浏览器应用软件浏览和操

作，在特定业务应用场景的要求下可支持不同分辨率桌面的自适应

显示，确保界面显示规整，不会出现移位、挂角等情况。平台级别

能力功能不使用其他任何插件，对于以上浏览器无法独立支撑操作

的功能要求的需要加载特定插件的需要向用户给出明确提示给用户

进行有选择性的下载。

2、项目建设内容

2.1统一认证平台

2.1.1建设目标

随着应用建设的逐步深入，已经建成的和将要建成的各种业务

部门的应用系统存在不同的身份认证方式，用户必须记忆不同的密

码和身份。因此，要建设以认证服务为基础的统一用户管理、授权

管理和身份认证体系，将用户权限信息统一存储，进行分级授权和

集中身份认证，规范应用系统的用户认证方式。提高应用系统的安

全性和用户使用的方便性，实现全部应用的单点登录。即用户经统

一应用门户登录后，从一个功能进入到另一个功能时，系统平台依

据用户的角色与权限，完成对用户的一次性身份认证，提供该用户

相应的活动“场所”、信息资源和基于其权限的功能模块和工具。

2.1.2建设内容以及功能要求

一、注册、认证和登录

序号功能具体描述

1新用户注册流程（含注册通道一

中心第三方应用平1.中国内地：提供姓名、身份证号（学生）进行

台）实名认证，输入就读学校和年级，再绑定手机

号并获取验证码，完成注册。

2.港澳台及其他国家地区：提供姓名、国籍/地

区、护照号/通行证号（学生）、出生日期、性

另人就读学校和年级，绑定手机号并获取验证

码，上传证件照进入人工审核，完成注册。

3.所有学员的账号以身份证号做唯一标识（主

键可用UUid）o

4.申请账号时注意密码的复杂度，规定必须为

字母、数字、特殊字符等组成的结构，保证账号

密码的安全性。

5.注册通道可用户定义开启或隐藏。

注册通道二

5.对接政务服务网的注册流程应该是先跳转到

政务网注册，再带着信息回到本系统，提供默

认密码为手机号。由于政务网返回的信息可能

只有身份证和手机号等基础信息，本系统需要

提示并补填其他必要信息后，才允许用户继续

使用本系统。

6.系统管理员可自定义注册通道的显示。

2其他用户注册提供姓名、身份证、绑定手机号并获取验证码，

完成注册。（根据需要可对接到政务服务网等

平台进行统一的注册和实名验证）

3内部系统账户迁移对对中心内部系统已注册的账户进行整体迁入，

接对于原系统缺少的信息如身份证号进行统一数

据清洗。使原来已注册的用户不必重新注册，

即可使用本系统。

4登录认证方式1.用户名/密码认证。

2.通过第三方平台认证，如QQ、微信、钉钉、

支付宝、浙里办、浙江政务服务网等方式认证。

3.教职工可独立认证通道。

5单点登录实现在多个已接入统一平台的应用系统中，用

户只需要登录一次就可以访问所有平台上的应

用系统。即：在token过期之前，用户只要一

次登录，便可以不需要登录而直接访问其他任

何已接入统一平台的系统。包括输入统一认证

网站网址、输入任意一个接入统一平台的系统

的网址、从其他网站通过超链接跳转、从已接

入的系统A跳转到已接入的系统B等。

6token过期时间token过期时间默认为5小时，但需实现可用

户自定义配置token过期时间。

7用户注销/登出/切换1.单点登出。用户登录状态下，在某一成员网

账号站或统一平台进行注销时，均可实现处处注销。

2.一个家长对应多个学生的情况下可能需要切

换账号，切换账号时可根据浏览器保存的密码

登录或重新输入密码。需要注意的是，系统账

号以学员身份证为维度，如果一个家长有多个

孩子，应该是账号之间的切换，而不是角色之

间的切换，也即不能以家长手机号作为登录账

号，而应该使用身份证或字符串作为唯一账户

名。同样是一处切换，处处切换。

8登录信息安全统一认证平台对某用户认证后，返回给其他系

统认证信息即token等，要注意信息的安全性，

谨防被拦截、窃取、篡改信息。

9对接政务服务网实名身份认证需要通过对接政务服务网实现，

意味着新用户需要跳转过去注册，下次登录时

带着政务服务网的返回信息回到本系统，本系

统依然保留自身的登录验证功能，但可对用户

隐藏，以保证本系统的主动性和可扩展性。

二、用户角色和应用门户

序号功能具体描述

1用户权限1.用户注册后拥有已经对接到统一平台的旧系

统的先前就绑定好的权限。

2.用户初始时拥有中心所有对外开放的系统的

访问权限，展示包括系统名称、所属部门和基

本的简介等信息并可以点选跳转。其他内部系

统，需要由该系统管理员人工为用户赋予访问

权限。

3.如果用户是开发者，还可以申请接口、数据

表。

2用户权限颗粒度统一平台给用户赋予的权限颗粒度仅精确到是

否可以访问该系统，用户在第三方系统中更具

体的角色以及第三方系统内的权限，不由统一

平台管理。

3角色和角色组统一平台级别角色，有开发者、管理者、应用使

用者等。有管理员分组、各系统管理员分组、开

发者分组和普通用户分组，因此一个用户可以

具有多种角色，一种角色也可以对应多个用户，

用户可以根据角色分组。

4权限管理1.用户-系统管理的模块，管理员可以查看其管

辖范围内的所有用户的系统权限，并可以对访

问权限进行分配和回收。实现用户与角色、用

户组与角色、用户组与角色的授权，支持根据

用户属性自动授权与收回。

2.除了角色授权以外，管理员可为本单位账号

进行分组，对组下账号的个人门户统一添加可

用应用。

3.对于异常用户，管理员有权限对其账号进行

冻结，用户可以自己申请解除冻结，由系统管

理员进行解冻。

4.具有黑名单功能。

5.对于异常登录用户，可周期性暂缓登录，可

配置。

5应用门户用户从基础平台登录成功后，显示用户有权限

访问的业务系统列表，每个系统以图标和系统

名称的形式显示，点击图标即可进入该系统中。

在应用门户里具有应用的消息数提示，访问后

可清空。同时应具备应用消息内容的列表接口，

必要时可进行内容显示。

6应用超市管理员可管理本单位的基础应用、自建应用、

第三方应用，支持应用启用/禁用功能。系统支

持应用分类管理，以便分类查看。

三、用户中心和基础数据管理

序号功能具体描述

1用户中心1.信息修改：系统页面右上角的用户图标可点

击，点击后进入用户中心。显示内容包括用户

自己的个人信息等，用户信息的更新、修改密

码、找回密码操作也在用户中心进行，找回密

码根据个人信息中填写的手机短信验证码、邮

箱邮件验证码的方式进行找回。

2.消息查看：在收到消息通知如管理员收到访

问系统权限申请的时候，系统右上方的用户图

标应该有红色小点或数字，以表示用户有未读

消息或未处理事项，点进去可以进入消息管理

页面进行处理，阅读完所有未读消息后红点消

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

事项列表。（消息和待处理事项的维度为统一

认证平台，和第三方系统消息无关联）

3.切换账号：如果绑定了其他账号，系统支持

账号一键切换登录其他账号个人门户。具体实

现见上文所述。

4.权限管理：可以查看自己拥有的系统列表和

权限。

2基础数据管理1.自动更新：如学生的年级变化、年级情况等

信息要随着时间的增长而自动更新。

2.互绑定更新：其他系统更新的数据，通过数

据交换平台实现同步或异步的更新。

3.提示更新：如升班等情况，弹出提醒询问是

否更新，点击一键更新。提供批量更新的功能。

4.学员用户数据，根据最后使用时间等要素进

行判断是否将该用户数据归档至历史数据表，

不作为热数据继续管理。

5.通用数据基础化。保证数据的基础化和可扩

展性，我们只保存和提供最原始数据，其他细

分结构则由各业务系统自定。

6.所有涉及到的基础数据都要进行数据清洗和

迁移的工作，包括但不限于学生、教职工、教

室、组织架构、收入等信息。

四、非功能性要求

1.易接入性和非侵入性：使其他业务系统可以通过很少的时间

代价和较少的开发代码改动，而完成对统一平台的对接。对于使用

不同编程语言开发的系统，都要具有对接兼容性。提供标准的接入

接口等，应该提供详尽的技术文档和视频等进行指导。考虑包括客

户端、app应用端系统的对接。

2.高并发下强稳定性：统一平台作为未来中心所有业务系统的

统一入口，应该具有强稳定性。保证系统功能的正常运行，在几十

万高并发的请求场景下，也可以保证系统的稳定、流畅和可用。如

遇系统崩溃，应该及时响应迅速解决。要求交付前进行性能测试，

并提供测试报告。

3.安全性：在平台的设计中，既要充分考虑信息资源的共享，

更要注意信息资源的保护和隔离，应分别针对不同的应用和不同的

网络通信环境，采取不同的措施，包括用户、数据、运行的安全性

等。要求对数据库提供灵活的备份和恢复机制，确保系统发生故障

时能及时恢复，业务功能不受影响。

4.数据展示脱敏和查询页面缓存：数据展示的时候应该考虑脱

敏，尤其是公开的页面中、日志展示中，如身份证和手机号的展示

就要考虑根据查看权限的不同进行脱敏处理。对于系统中所有查询

相关的页面，都应该做成分页查询，并且有缓存，避免短时间内多

次直连数据库，查询页面也应该设置默认的查询条件，不能任何条

件都不输入而进行全表查询，以免造成系统崩溃。

5.统一平台的监控：提供完善的监控功能，可对平台内的用

户、应用、服务进程和服务器硬件资源进行实时监控，且可通过各

类图表进行直观的结果展现。可对用户身份帐号的管理、授权以及

用户的认证行为中可能存在的问题进行审计一，所有操作均日志记

录，日志必须可视化且易看，并提供根据时间、关键字、log等级

查询的功能。能够对每个角色管理员的操作行为、用户自助管理行

为和用户登录访问行为进行记录。代码中关键操作步骤必须打

log,info、warn、error几个等级的日志都应有所涉及。对于异常

行为应有告警机制，及时通知各系统的管理员，并提供基本的一键

解决措施等。（具体需求见下文的监控中心和日志管理模块）

6.平台平稳和备用方案：作为所有业务系统的基础平台，应该

具有备用方案和策略，当系统因各种原因而崩溃时，应该启动双活

备份等方案，使登录和注册等功能正常使用，不影响其他业务系统

的正常使用。

8.易扩展性：留好对接其他统一认证平台的接口，如果后面需

要对接上级单位的统一认证平台，希望做到较少开发量和对接成

本，以及只对本基础平台进行修改，而对所有已接入的其他业务系

统透明无感，不需要它们再次对接，也不应该影响其他系统的正常

登录注册和运行。

9.提供开发文档：包括接入流程、认证配置、创建应用流程、

申请和上传接口流程、消息模板配置、开发者规范等。需要实现多

种开发语言的第三方系统对接，包括但不限于Java、Python、

C++、C、Go、Php等。

2.2开发者门户

2.2.1建设目标

开发者门户包括开发者门户和接口管理两个模块，如上所

述，统一平台具有三种角色，管理员、开发者和应用访问者，开发

者作为各接入业务系统的开发管理员，应具有单独的模块对其功能

进行管理，包括接口的开发、申请和管理、部门/单位内系统和应用

的上线和管理等，实现对接口的统一管理。

2.2.2建设内容以及功能要求

一、开发者门户

序号功能具体描述

1开发者注册系统支持专业公司或团队个人在平台上完成开

发者账号注册，成为第三方开发者。

2系统注册开发者可通过平台提交系统注册申请，并根据

本用户单位部门机构信息选择所属部门，该系

统应用上线后可在该单位应用超市中查看。

3应用添加开发者可在注册完成的系统内添加应用，并且

为了数据安全考虑，应设置应用的服务器出口

ip，接口需校验调用ip才可获取数据。

4数据权限系统默认赋予应用所属角色组数据权限，系统

管理员可管理控制数据范围，保障数据在规定

范围内传输。

5消息模板系统默认提供消息接口权限，但写入消息时，

必须先申请消息模板。消息是为了通知其他接

口对接方或相关系统有订阅内容发生改变，通

过审核后即可使用。

6应用管理开发者可申请应用上线。已上线的应用需管理

员撤销审核后才可下线。上线应用可在应用超

市的相关应用类型中查看。相应机构的管理员

可下发应用权限，使应用可在授权账号的个人

门户中查看。管理员可设置应用暂停使用，使

在应用门户中不可点选。（应用包括但不限于

中心其他部门或处室的系统，还应包括小功能

模块组件，可供展示和调用）

7发送信息接口在开发者门户中提供一个单独页面，作为发送

信息接口的申请和管理。第三方系统可进行接

口调用申请，包括发送短信、app、邮箱等几个

渠道。目的是本系统作为一个网关，向应用方

提供统一的消息发送接口，使应用方开发者们

不用考虑发送消息底层渠道变更的情况。

二、接口管理

序号功能具体描述

1接口上传1.上传前需要绑定平台中已有的数据表数据

源，可选之前添加的数据库连接信息，或新建数

据表。发布接口时可以绑定过去已开发好的接

口，也可以新创建接口，通过配置或写sql的

方式，从已有数据库表中获取字段，配置好接口

后，点击发布，即上传成功新接口。

2.上传接口时可以选择接口的生效时间段，并

且可配置接口的日/分钟可调用次数，每个接口

日/分钟调用次数最多不能超过1万〃千次。

2接口维护实现接口的添加、发布、取消发布、测试、版本

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

RESTfuKhttps传输协议，能设置接口的可调

用次数。

3接口详情接口的信息应包括接口名称、请求方式、url、

生产者信息、输入输出字段及其类型、数据来源

表、接口概述等。发布接口时必须具备这些信

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

动触发消息中心的通知机制，对该接口的所有

订阅者进行通知。

4接口查询1.开发者可检索平台上所有开放的接口，并可

对接口基本信息进行预览。开发者通过开发者

账号登录后可申请调用接口。

2.用户/开发者可以对自己拥有的接口进行分

类整理，如新建文件夹移动保存等。接口也可以

树形结构的方式进行分层展示。

5接口申请开发者可以检索到数据平台的所有数据表，展

示出来的只是表名和简介，开发者可根据自己

的需求向表的所有者申请访问权限，经表所有

者和系统管理员审批通过后可以看到表的全部

信息。在拥有数据表的访问权限后，对自己所需

的接口进行申请。申请方式有两种：

1.开发者和对方系统直接提出需求，由对方系

统的开发者直接提供所需接口。申请流程是先

由接口的提供者在已发布的接口上为新消费者

添加访问权限，再流转到系统总管理员进行复

核，最后拥有访问此接口的权限。此时不是必须

拥有访问对方数据表的权限，只要能通过协商

好的接口获取到自己所需的数据即可。

2.开发者先对数据库表进行访问权限申请，此

时所需的数据不一定在同一张表，甚至不一定

在同一个业务系统（库）中，开发者可根据几张

表的字段进行手动配置，如当A表的x字段和

B表的y字段相等时，返回A、B表中的哪几个

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

置可以通过写sql或者其他方式实现。

应用场景少但保留透传功能，即不保存在交换

中心双方直接通过接口传递数据，此申请必须

通过管理员审核，并且无特殊情况不应该通过

审核。

3.第三方应用开发的接口，通过接口申请，由管

理员审核后，存入接口中心，由接口中心统一管

理与代理。

6接口管理1.管理者可以查看到系统中所有开发者和接口

的对应关系列表，并进行增删改的管理。

2.管理者可以看到接口的监控信息，如接口的

申请次数、每日调用次数、响应时间、是否出现

拥塞等情况。

7接口权限提供接口预览功能，开发者申请接口，管理员审

核通过后方可调用。

8接口时效生产者在上传接口的时候，要指定接口的上架

时间和下架时间，超过下架时间后接口即变为

不可调用的状态。消费者申请接口也有有效时

间，在生效时间窗口内方可调用接口，过了时效

期要重新进行接口的权限申请。

9接口测试生产者、消费者都可以在系统页面中对接口进

行测试，以设定的请求地址、请求方式、请求头

请求体发起请求时，测试连通性等其他信息。

10接口调用次数可设置接口在一天内或一分钟内的被调用次

数，防止被频繁调用或恶意攻击。

三、非功能性要求

1.接口管理中心的可扩展性：面对高速发展的信息化建设，不

断有新的应用系统接口在服务订阅中心中创建和第三方接口加入到

服务订阅中心中，要求接口服务总线具有高扩展性和增长性的接口

创建和发布能力，让各种业务数据可以方便的在服务订阅中心中通

过接口方式发布，迅速为用户提供服务。

2.接口传输数据安全性：数据格式易于传输，能够实现各个应

用系统之间的同步/异步信息交换，格式技术兼容各种网络系统和通

讯协议。交换的数据文档需要基于应用系统之间约定的规则进行验

证，要能建立数据格式、数据内容、网络传输等不同层面的安全防

护机制。平台对外提供的API需使用信息安全算法进行保护。

3.所有的接口申请、数据申请、数据库表申请等都需要在申请

前签订协议，通过页面弹框等方式进行签署，本系统进行持久化存

储。协议的具体内容由我方提供。

2.3消息服务中心

2.3.1建设目标

消息服务中心分为消息中心和消息机制两种，其中消息中心

是可以向任何用户发送任何一种消息（文本、图片、语音、视频

等），并能有效到达任何接收终端（手机短信、邮件、站内信、钉

钉等）的消息推送服务平台。可节约通信成本，同时对消息发送的

及时性、统一性、严谨性进行统一管理和审计。消息中心将消息规

整化处理，提供消息的采集、内容规整、分布式调度、消息规则配

置、消息内容审计，还能够进行微服务化、分布式的消息处理以及

文件、音频、视频、新闻、公文、多媒体等多种消息格式处理。消

息机制是一种技术实现方法，通过消息队列、消息循环（分发）和

消息处理实现数据的传输，主要应用在数据交换和消息处理的场景

中。

2.3.2建设内容以及功能要求

一、消息中心

序号功能具体描述

1消息模板可自定义消息的发送模板，并提供消息管理页

面，对所有已读、未读消息和消息模板进行统

一管理。

2消息推送根据用户订阅，推送如接口更新、权限申请、站

内通信、监控预警、订阅信息、重要数据变动、

触发预定规则阈值等消息。提供消息推送供各

应用系统调用，实现消息发送和管理。

3多渠道推送实现消息的收发，接入手机短信、站内信、钉

钉、微信等通道，实现消息一键发布，全终端接

收。允许管理员配置消息发送间隔，以及单个

用户每天被发送信息的上限次数。

4消息传输安全支持接口数据加密传输，保证数据能在客户端

与服务订阅中心服务器之间安全通信，接口的

不同调用者可采用的不同的加密技术。

5第三方系统消息聚集所有接入基础数据平台的第三方系统，将自己

系统的消息通知以接口、消息机制等形式推送

给本平台，本平台根据消息接收者进行分类汇

总，使每个用户可以在个人门户的消息中心看

到所有第三方系统发给该用户的消息，并可以

通过链接跳转到消息对应的系统进行处理。从

而完成消息的汇总和统一处理。

二、消息机制

消息机制由消息队列、消息循环和消息处理三大块组成，消息

队列应用在当不需要立即获得结果，但是并发量又需要进行控制的

场景下，主要解决了应用耦合、异步处理、流量削锋等问题。可以

用于：应用耦合，多应用间通过消息队列对同一消息进行处理，避

免调用接口失败导致整个过程失败；异步处理，多应用对消息队列

中同一消息进行处理，应用间并发处理消息，相比串行处理，减少

处理时间；限流削峰，广泛应用于秒杀或抢购活动中，避免流量过

大导致应用系统挂掉的情况；消息驱动的系统，系统分为消息队

列、消息生产者、消息消费者，生产者负责产生消息，消费者（可

能有多个）负责对消息进行处理。以上几种场景在本系统中都可能

有应用，尤其是应用间传递消息和数据等，根据实际开发情况引入

该技术，数据交换相关的具体需求见下文数据管理中心模块。

2.4监控中心

2.4.1建设目标

基础数据平台应具有独立且完备的监控中心模块，提供全链

路和全方面的监控功能，实现对平台内的用户、应用、服务进程和

服务器硬件资源的实时监控，且可通过各类图表进行直观的结果展

现，并提供专门的日志查询页面，供具有权限的用户检索和查看所

有日志，并提供按照日期、关键字和日志等级查询几项功能，方便

后续运维和查看问题，保障系统的安全。

对于一些常用的监控数据进行可视化展示，使系统的开发人员

可以及时关注到异常数据和关键性数据。比如数据的传输速度、某

系统数据的访问频度、数据传输时的出错报告及重试次数、信道的

占用比例、数据交换平台的健康指数以及系统每日的运行日志。

可以用Grafana、Prometheus等开源监控可视化工具进行展

示，也可用其他类似方式实现，并通过Alertmanager等工具进行告

警，告警可以使用消息中心通过站内信、邮件、QQ、钉钉等（具体

方式应该在订阅数据时选择）其他方式通知相应订阅者、管理员。

2.4.2建设内容以及功能要求

一、监控范围

序号功能具体描述

1系统应用监控对于对接在统一平台的系统应用，监控对接情

况是否有异常，能否通过统一平台正常跳转访

问等。

2应用操作监控对应用操作层面的行为进行监控，比如申请系

统、应用、访问权限、下线系统等，并能够对每

个角色管理员的操作行为、用户自助管理行为

和用户登录访问行为进行记录。

3服务器监控可实时监控认证服务器、缓存服务器的运行及

负载情况，监控范围包括磁盘、CPU运行情况、

网络输入与输出、内存占用率等。

4数据库监控监控统一身份认证数据库连接情况、SQL执行响

应时间、连接数等信息，通过监控及时发现业

务处理过程中数据库相关问题。

5数据质量监控可监测从各个业务系统汇集的原始数据，通过

自动/手动方式发现库中存在的数据质量问题。

系统提供非空检查、外键检查、长度检查、一致

性检查、自定义规则检查等监测方式。

6数据一致性监控监控数据记录的规范和数据是否符合逻辑。规

范指的是，一项数据存在它特定的格式；逻辑

指的是，多项数据间存在着固定的逻辑关系。

7接口监控每次接口调用时记录相应的信息，以便进行统

计查询，用于查询具体的调用记录信息。

8数据传输监控对于在数据管理平台上进行数据传输进行监

控，数据传输出现问题如卡顿或反复重传失败。

2.5日志管理

2.5.1建设目标

平台应提供完备安全的审计日志机制，包括人员调整日志，资

源调整日志等，并提供完整的统计分析功能，对系统操作进行完整

记录，作为监控中心所监控行为的记录和展示，并提供单独的日志

管理页面，以便获取整个应用系统的运行情况。

系统日志记录用户操作和系统自动执行的各种操作，即2.4节

监控中心所述的监控范围，在日志管理页面中对日志进行增删改查

等管理操作，而不需要去系统文件夹中查询日志，实现日志的可视

化，并实现对日志进行查看、检索和导出等。

2.5.2建设内容以及功能要求

、日志打印要求

序号功能具体描述

1日志打印颗粒度1.查询操作的日志不打印查询页面所有信息详

情，只打印"XX用户XX时间进行了XX查询”0

2.所有写入操作、接口调用、写DB、修改状态

都必须打印日志，标明操作人、操作内容和操作

时间。

3.上节2.4.2中监控范围的应用操作监控、数

据传输监控、接口监控、数据质量监控等的关键

步骤也应进行日志打印。其他无法用日志打印

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

2输入输出日志所有调用本系统的接口或本系统调用的接口，

系统间通过基础数据平台进行接触的操作都以

切面的方式拦截，进行自动的日志打印。打印格

式遵循我方要求的日志格式规范。

3日志查询速度为了不影响系统的正常运行，消费到日志后，应

存储在如Elasticsearch等的数据库中，再通

过日志管理页面进行展示，实现高效查询。

4查询条件日志查询的条件提供包括日期时间段、关键字、

日志等级三种。不输入查询条件时展示最新日

志信息，实时性要求不高。

5内容格式每条日志的详细信息包括：日志类型（用户/系

统操作）、操作用户/系统、被操作对象、操作

时间、具体内容、执行结果（成功和失败）等。

另，还有程序运行过程中打印的系统日志。

6查看权限具有日志查看权限的用户可查看到日志信息。

7持久化时间日志应保存至少六个月以上，保证问题的可追

溯性。

8日志导出管理员可以对日志进行导出，可根据技术实现