前言

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

1. 业务背景

　　随着学校的规模的扩大，学生数量的增加，需要处理的信息也日趋增大。学生信息的管理变得复杂、费时。学校需要一个学生管理系统，提供学生各类信息管理，以及选课、成绩查询等功能。通过这个管理系统规范化地管理学生信息，提高日常管理的工作效率，降低管理成本。

　　系统提供的业务功能大致如下图：

• 学校的管理员通过系统，对师生信息进行管理；根据学生的选课情况，进行排课。

• 学生通过系统可以选课、查看课表、查询考试成绩

• 老师通过系统可以管理考试、批改试卷、录入成绩、统计成绩。

2. 约束和限制

1. 预算有限，使用开源的方案来实现系统。

2. 数据库使用 MySQL

3. 系统开发周期为３个月

4. 使用 BS 模式，即浏览器+服务器结构的 Web 开发模式

3. 总体架构

　　根据业务，将系统分成 3 个子系统，分别是学生子系统，课程子系统，权限子系统。

• 学生子系统提供学生的基础信息、成绩查询

• 课程子系统提供科目管理、选课、排课、考试

• 权限子系统提供师生账号、管理员账号的分配

　　系统白盒图结构如下。

3.1 架构分析

　　本小节从高性能、高可用、可扩展、成本与安全四个角度分析说明支持学生管理系统架构需要的复杂度。

３.１.１　高性能

　　学生管理系统的主要用户是学生、老师、和校务管理员。一个普通中小学学校内的用户数量正常在１-2k 人左右。根据系统的主要业务分析（如下图），用户对系统的使用频率不高，大约１天１次。值得注意的是，大量用户上课、考试、选课、批改的时间段可能高度一致。特别是每学期初选课时，大量学生集体在线选课，或者期末学生查询成绩是，可能会出现系统性能的瓶颈。但是由于学校的用户量相对不高，而且高访问量主要集中发生在学期初和末，约等于每年４天。综上所述，虽然系统需要注意性能问题，但并没有强烈的高性能需求。不需要过多考虑负载均衡问题。

３.１.２　高可用

　　学生管理系统，对访问的可用性，有要求。如果系统无法访问，会影响到上课、考试等学校的日常活动。但是也没有到，没系统就没法上课，考试。如果系统出现问题，稍后能够重新访问，在用户的可接受范围内。

　　在数据存储上，在选课上，对数据准确性上有要求。如果已经满额的课程，仍然能够报名，会导致学生选课无效，需要重新选课的情况。这是对学生来说不能接受的情况。

３.１.３　可扩展

　　学校在使用系统的过程中，可能会把更多的学校管理业务迁移到系统中的可能。将系统按业务拆分成多个子系统的设计，可以支持后期扩展更多业务的可能性。

３.１.４　成本与安全

　　学校的师生信息，属于有一定信息敏感度的信息，需要考虑存储安全，信息安全。如果数据丢失，会很大程度上影响学校日常教学活动。因此需要对数据定期备份。从成本的角度，１主１备的数据备份，已经可以满足存储安全问题。

3.2 总体架构

1. 通过 nginx 映射将来自客户端的请求分发到对应的子系统中。

2. 根据业务需求，拆分成三个独立的子系统。

3. 子系统们共用一个 Mysql 数据库读写。1 主 1 备。备库只做备份。

4. 详细设计

　　客户端采用 VUE 框架，前端语言 js 开发。基于 ajax，通过 HTTP 请求与服务端交互。采用 JSON 传递数据。

　　服务端基于 SpringBoot 开发。服务端间子系统的通讯，通过 HTTP 请求，采用 JSON 传递数据。通过 Nginx 识别客户端的请求地址，按定义的路由规则分发到对应的子系统。

　　数据存储使用 MySQL。

4.1 核心功能

　　学生管理系统的核心功能有：人员管理，账号登录，学生选课，管理员排课、查看课表，考试管理、成绩录入，成绩查询。

４.１.１　人员管理

　　系统管理员，对校内人员信息进行管理。管理员通过权限子系统，给学生、老师创建账号。学生子系统将学生的详细信息，班级关系存储到数据库中。课程子系统将老师的信息和任教科目关联。

４.１.２　账号登录

　　权限子系统，对登录的用户进行查询。从数据库获取对应账号信息，检查是否匹配。

４.１.３　学生选课

　　学生通过权限子系统，登录账号后，在课程子系统内，获得可选课程信息。课程子系统检查学生的选课申请，存储到数据库中。

４.１.４　管理员排课

　　管理员通过课程子系统，获得学生的选课结果。通过学生子系统获得学生的班级信息。根据学生、班级、选课结果进行排课。

４.１.５　查看课表

　　管理员通过课程子系统保存了排课信息后。学生登录系统，从课程子系统查询本人的课表信息。

４.１.６　考试管理

　　老师通过权限子系统，登录账号后，在课程子系统内，创建考试。从学生子系统获取班级学生信息，关联到考试上。

４.１.７　成绩录入

　　老师通过学生子系统，将成绩录入到学生的相关信息内。

４.１.８　成绩查询

　　学生通过学生子系统，查询自己的考试成绩。

4.2 关键设计

考虑到系统中，有几个业务流程可能存在对可用性、高性能的需求。作出如下关键设计。

４.１.１　学生选课的高并发可用性

　　学生选课通常会集中在一个时间段内，大量请求。且一个课程的名额有限，在高并发的情况下，系统需要做到，避免超额选课。选课的并发问题，是用 MyＳＱＬ的数据库锁＋事务即可。在记录新的选课学生时，使用数据库的行锁，锁定课程记录，直到选课学生的信息被数据库存储完成，更新选课记录，完成解锁。

４.１.２　学生课表的查询

　　学生上课前，会有查询课表的需求。这个操作通常会集中在课间时间，或第一堂课开始前。由于课表安排好后，一整个学期都几乎不会发生变化。在管理员完成排课后，系统可以针对每个学生，生成一份完整的课表数据。每次学生查询课表，只需要从数据库中读取对应的记录即可。如果课表发生了变化，在管理员修改课表后，通过课程子系统，更新关联的学生课表即可。

4.3 设计规范

1. 客户端和服务端，服务端和服务端的接口间通讯，数据格式都使用 JSON。

2. 采用 Spring Boot 作为开发框架

3. MySQL 使用 Innodb 存储引擎

4. 日志文件统一按 servername_yyyymmddhhmm.log 的格式存储，举例：authserver_202109011234.log。日志文件最大不能超过 1M，超过后需打包压缩到指定目录。

5. 质量设计

1. BS 结构的系统测试容易

2. nginx 分流，3 个子系统，数据库只有 1 主 1 备，维护不复杂。

3. 系统的运行成本主要是，域名，IP，服务器主机的费用。如果使用商业云方案，成本可以控制在 2-3k 每年。

6. 演进规划

1. 学校的流程制度变化不大，1-2 年内无需考虑更多功能演化。

2. 学校的学生数量不会发生很大变化，系统架构够用很多年。