前言

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

词汇表

SpringBoot：Java 语言的 Web 开发框架

Http： 超文本传输协议，运行在 TPC 之上。 它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应

Https： 以安全为目标的 HTTP 通道，在 HTTP 的基础上通过传输加密和身份认证保证了传输过程的安全性

Nginx： 高性能的 HTTP 和反向代理 web 服务器

MySQL： 关系型数据库管理系统

token：用户身份标识，是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个 Token 便将此 Token 返回给客户端，以后客户端只需带上这个 Token 前来请求数据即可，无需再次带上用户名和密码。

1. 业务背景

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

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

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

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

2. 约束和限制

1. 学生人数 2~3 万人左右，QPS 不会太高，不需要考虑高并发场景

2. 学校机房独立部署，部署成本不能过高

3. 数据库采用 MySQL

4. 学校内部使用，人数相对固定，不需要考虑人数激增，导致服务不可用

5. 满足需求文档中的全部功能

6. 项目一次性运维部署，运维不需要考虑后期管理，由学校负责

3. 总体架构

3.1 架构分析

3.1.1 高可用

学校本身对学生管理系统依赖并不高，如果学生管理系统宕机，并不会对学校的管理造成太大影响。

但是对学校来说学生信息是非常重要的，学生信息丢失，重新录入难度过大，需要考虑存储的高可用，保证大部分数据不丢失即可

3.1.2 高性能

作为学校的学生管理系统，一个学校学生人数相对固定，大概 2~3 万人左右，而且平常也不会有大量学生同时访问的场景，对高性能不需要过多考虑

3.1.3 可扩展性

业务需求比较复杂，需要考虑功能的扩展性

3.1.4 成本

作为外包学生管理系统，成本不是首要考虑

3.1.5 安全

学生管理系统作为学校的内部系统，一般不会暴露在公网上，而且其中只会存储学生的公开信息，安全方面不需要过多考虑

综上所述，外部学生管理员系统需要考虑数据存储的高可用和业务的可扩展性

3.2 总体架构

1. Nginx

Nginx 负责请求接入，将请求代理到实际的业务服务器

1. 业务功能

业务拆分为三个部分 学生子系统、课程子系统、权限子系统

1. MySQL

2. 数据存储采用 MySQL 主备架构，包含一台主 MySQL 和一台备 MySQL，采用主备数据复制。保证数据不丢失

4. 详细设计

4.1 核心功能

学生子系统：包含学生信息维护，信息查询（成绩查询、课程查询等）、选课

课程子系统：包含课程管理（课程录入、排课、选课、教材选择等），考试管理

权限子系统：包含管理员管理功能（学生信息管理、权限分配等）、教师功能、身份认证功能

4.2 关键设计

4.2.1 token 身份认证

• 客户端使用用户名跟密码请求登录

• 服务端收到请求，去验证用户名与密码

• 验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端

• 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里

• 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token 服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据的响应结果，否则提示无权限

4.3 设计规范

1. 外包学生管理系统采用 SpringBoot 框架开发

2. MySQL 使用 Innodb 存储引擎

3. 对外使用 HTTPS 作为连接协议，数据包采用 JSON 格式

4. 采用 token 作为身份认证，token 存放在请求的 header 中

5. 每个接口都需要进行权限过滤

6. 子系统之间 HTTP 作为连接协议，数据包采用 JSON 格式

5. 质量设计

可测试性：1. 每个子系统独立开发，并且可以单独测试； 2. 编写测试用例，保证代码逻辑正确

可维护性：1. 准备好部署脚本，方便运维部署；2. 对于重要的功能开发对应的运维管理界面，方便查看异常以及异常时重试

可观测性：1. 在开发过程中，需要将异常明确打印出来，方便后期查找问题；2. 记录操作审计，方便溯源

成本：每个子系统由固定的人员开发，可以保证代码质量，减少沟通成本。项目开发成本需要在甲方的给定范围内

6. 演进规划

1. 由于是外包项目，在本次开发中需满足需求中的所有功能开发。

2. 项目分为三个子系统 学生子系统、课程子系统、权限子系统，每个子系统可以独立开发，每个子系统的完成作为一个里程碑。

3. 每个子系统完成后，进行联调工作

4. 补充重要功能的运维页面（如果项目时间不足，可以考虑放到二期完成）

5. 如果未来有迭代需求，可以考虑对现有功能进行扩展，将子系统改造为对应的微服务