外包学生管理系统架构设计文档

前言

本文是外包学生管理系统详细架构设计文档，从 0 到 1 构建外包学生管理系统，用于指导外包学生管理系统后续的开发、测试和运维。

词汇表

student： 学生

teacher：教师

admin： 管理员

assistant：辅导员

course: 课程

score：成绩

account： 账号

authentication：认证

authorization： 授权

1. 业务背景

随着学校的规模的不断扩大，学生数量的增加，需要处理的信息也日趋增大。不仅花费大量的教师资源， 处理效率也十分低下。

为提高学生管理的管理水平，优化资源，尽可能降低管理成本成为学生管理的新课题，学生管理系统是从学生管理现状出发，根据学生管理的新要求进行开发设计的，它需要解决学生信息管理数据信息量大修改不方便，对一系列数据进行分析时花费时间长等问题，帮助学生管理人员有效管理学生信息。

因此学生信息管理系统可以通过系统规范化地管理、科学性统计和快速查询、修改、增加、删除等，提高信息的准确度以及日常管理的工作效率。

本系统主要是应用于学生各类信息的管理，总体任务是实现学生信息关系的系统化、规范化、自动化，其主要任务是统计学生各类信息进行日常管理，如查询、修改、增加、删除、以及学生选课、成绩的查询等功能设计的管理系统。

2. 约束和限制

1）开发成本低。

2）系统运维成本低，部署维护简单，不能太复杂。

3）一次性交付。

4）系统需满足学校的学生管理需求，系统架构够用多年。

3. 总体架构

3.1 架构分析

3.1.1 高可用

对于学生管理系统来说，如果学生数据丢失了，对学生的影响是很大的，这是非常严重的事情。因此，系统需要保证数据高可用。

3.1.2 高性能

单个学校学生人数不多（1 万人），每年招生人数相对固定，由此可见，系统用户量不高，对性能要求也不高。因此，系统暂不需要考虑高性能需求。

3.1.3 可扩展

学生管理系统包含多种角色的用户，每种角色有不同的权限和业务流程，由此可见，系统的业务比较复杂，因此，系统需要保证可扩展，以满足复杂的业务需求。

3.1.4 其它

学校没有专职的研发人员，对系统的运维要求简单，不能经常出现问题。

系统保存的是学生公开的数据，所以系统对数据的安全性要求不高。

3.2       总体架构

系统划分为学生子系统、课程子系统、权限子系统，Nginx 负责学生请求接入，反向代理到各子系统。

3.2.1 学生子系统 Role 和 Relation 设计

1）学生子系统边界确定为：学生相关的信息的聚合，包含学生基本信息、组织（院系、班级），以及学生提交的作业、成绩等。

2）使用 Java 语言和 SpringBoot 框架开发，基于 Restful Api 规范实现学生子系统的接口。

3）提供 Http 接口供权限子系统和课程子系统调用。

3.2.2 课程子系统 Role 和 Relation 设计

1）课程子系统边界确定为：教务相关信息的聚合，不含学生信息。包含课程、教材、试卷等。

2）使用 Java 语言和 SpringBoot 框架开发，基于 Restful Api 规范实现学生子系统的接口。

3）提供 Http 接口供权限子系统和学生子系统调用。

4）外设为预留的扩展，目前不需要实现。

3.2.3 权限子系统 Role 和 Relation 设计

1）权限子系统边界确定为：用户中心和权限中心的聚合。包含用户、角色、权限、第三方账号等。

2）使用 Java 语言和 SpringBoot 框架开发，基于 Restful Api 规范实现学生子系统的接口。

3）提供 Http 接口供权限子系统和学生子系统调用。

3.2.4 数据库 Role 和 Relation 设计

1）MySQL 一主一备，备库定时同步主库的记录。

2）每日凌晨备份数据库，可采用每月全量+每日增量的备份方式。

4. 详细设计

4.1 核心功能

4.1.1 账号分配流程

4.1.2 考试流程

4.1.3 学生查看成绩流程

4.2 关键设计

4.2.1 数据高可用

数据通过 MySQL 主备实现高可用，但当主备间出现复制延迟，恰好主库宕机且无法复原，则未同步的数据会永久丢失，这种情况不做针对性设计，运维人员需要做好数据库监控，当复制延迟超过 30s 的时候及时告警和手动处理。

4.2.2 系统可扩展

系统划分为三个子系统，封装业务，提高可扩展性。同时也提高了系统的复杂度。开发测试人员注意区分各子系统的区别，避免不同业务耦合在一起。

4.3 设计规范

1） 采用前后端分离，前端使用 React+Redux+ES6+webpack+Sass+Antd 框架，后端使用 SSM 框架。前后端交互报文使用 json 格式。

2） 数据报文设计

请求格式：在 header 中添加 token:xxx 表示用户已经登录。

返回格式：{code:200, msg:字符串, payload:Map 对象}。

3） token 设计

使用 jwt 作为用户登录的 token，token 包含用户 id 和用户名称等关键信息。

4） MySql 使用 Innodb 存储引擎。

5） 错误码设计

错误码使用 5 位数，第一位表示系统或业务错误（如：1 表示硬件错误；2 表示网络错误；3 表示系统软件错误；4～6 表示各子系统错误），第二、三位表示模块，第四、五位表示异常信息。

5. 质量设计

5.1 成本

至少需要四台机器进行部署，Nginx 单独部署在一台机器上，提供外网访问。三个子系统部署在一台机器，数据库各部署在一台机器上。

5.2 安全性

由于系统对安全性要求不高，仅考虑了业务安全（通过权限识别），暂不进行其他的安全性的设计。

5.3 可测试性

1）使用了前后端分离及 Restful api，可进行接口测试。

2）数据库使用 Mysql，可使用 Mysql 命令对数据库进行测试。

5.4 可维护性

1）数据库使用 Mysql，可使用 Mysql 命令对数据库进行维护。

2）通过管理后台可对用户、课程、试卷等进行维护。

5.5 可观测性

1）可通过应用日志和数据库日志观测系统运行情况。

2）可通过运维平台对系统性能进行观测。

6. 演进规划

该架构够用多年，无需考虑架构演进，开发更多需要关注及实现业务需求。