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

前言

本文是学生管理系统架构设计文档，用于指导学生管理系统的开发、测试和运维。

1 业务背景

随着学校的规模的不断扩大，学生数量的增加，需要处理的信息也日趋增大。不仅花费大量的教师资源，处理效率也十分低下，由此带来以下几个明显的系统问题：

管理效率问题：信息管理数据信息量大修改不方便，数据分析花费时间长，数据查询较慢等；

信息质量问题：信息质量不高，数据统计与管理不规范；

管理质量问题：学生信息管理系统化、规范化、自动化程度较低如查询、修改、增加、删除、以及学生选课、成绩的查询等。

基于以上背景，我们需要引入学生管理系统，提供系统化、规范会、自动化的信息管理功能，提高学生信息管理的质量与效率。

2 约束与限制

校内部署访问

学生信息永久存储

3 总体架构

3.1 架构分析

3.1.1 高可用

3.1.1.1 存储高可用

存储系统关系到数据的安全性，由于业务方要求学生信息不可丢失，数据永久存储，因此对数据存储的高可用是有要求的。使用该系统的是校内老师和学生进行开放，信息为学生选课、考试，录入信息的工作相对比较烦碎，信息是公开且可收集的，且不涉及到资金与人身安全，因此可以容忍一部分数据丢失。

3.1.1.2 计算高可用

该系统主要为在校师生提供服务，使用人数与使用频率都不是很高，因此允许有一定的故障等待时间，对计算高可用无要求。

3.1.2 高性能

3.1.2.1 计算高性能

由于在校师生人数大约在 3 万人左右，如都集中在白天的 6 个小时访问，平均每人发送 50 个请求，QPS/TPS 大约在 450 左右，对于服务器来说 450 的 QPS/TPS 没有太大的压力，因此对计算的高性能也没有要求。

3.1.2.2 存储高性能

根据上面的分析，系统的 QPS/TPS 在 450 左右，对于数据库来说也是完全可以支持的。

3.1.3 可扩展

该系统的功能需求比较多，业务相对比较复杂，因此对扩展性有一定的要求。

3.2 总体架构

3.2.1 系统边界白盒图

3.2.2 系统架构

系统采用前后端分离的设计方法，将前后端实现解耦可以独立开放。

3.2.2.1 前端 Web 设计

前端 Web 通过 HTTP 接口与后端服务进行通信。

3.2.2.2 服务端设计

服务端将系统拆分为学生子系统，课程子系统，权限子系统三个子系统，并通过反向代理对外提供 HTTP 接口服务，客户端请求通过路由规则分发到不同的子系统。

3.2.3.3 数据存储设计

数据存储采用 MySQL 主备同步的方式，图片直接以 Blob 类型存储在数据库中，不同类型的图片分别用独立的表存储。

4 详细设计

4.1 核心功能

学生注册

4.2 关键设计

4.2.1 存储高可用

数据存储采用 MySQL 主备同步的方式，当主服务器宕机时，备机对外提供查询服务，等待主服务器恢复，如主服务器不可恢复，则将备服务器设置为新的主服服务器。

4.2.2 系统可扩展

将系统拆分为多个不同的子服务，每个子服务都能独立的开发维护与升级，方便后续的功能扩展。

4.3 设计规范

1) 各业务子系统，采用 GIN 框架进行开发，准守 Golang 的命令规则，代码统一使用 glint 工具进行静态检查。

2) MySQL 数据库使用 InnoDB 存储引擎，采用 uft8mb4 编码；

3) 接口设计遵循 RESTFul API 规范；

4) 使用统一的错误码，前 3 位为业务代码，后 4 位错误代码。

5 质量设计

5.1 可测试性

1) 各业务子系统需要有单元测试，覆盖率要达到 70%以上；

2) 接口提供 swagger 调试界面；

5.2 可维护性

1) 提供命令行工具对数据进行导入导出；

2) 关键业务点要记录日志，日志分为 Error，Info，Debug 三个等级。

5.3 可观测性

增加日志收集，服务器指标采集，数据库指标采集，并提供统计界面与报警功能。

5.4 成本

三个子系统分别部署在不同的服务器上，前端可以与 Nginx 反向代理部署在同一台机器上，数据库需要两台独立的服务器；前期可以将三个系统部署在同一台机器上。

5.5 安全

系统部署在校园网，虽然安全问题不大，仍然可以考虑使用 HTTPS。

6 演进规划

1) 系统运行很长时间后，可以将图片、文档等小文件存储在分布式文件系统中

2) 增加在线排课功能

3) 增加在线考试功能