前言

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

1. 业务背景

随着学校的规模的不断扩大，学生数量的增加，需要处理的信息也日趋增大。因此会带来以下三个问题：

• 成本问题：目前学生信息管理，靠老师人工维护，这样就会消耗较多的时间陈本和人力成本，将师资投入在信息维护上，是十分浪费的。

• 效率问题：由于学生信息是人工维护的，对于信息的录入、查询、分析的效率都会比较低下。会有信息更新不及时，人工统计耗时、误差概率大等问题。

• 准确问题：人工维护的信息，可能会导致部分数据缺失，信息不完整的问题。通过系统化，可以完全避免重要信息确实的情况。

基于以上问题，我们需要建设学生信息管理系统，来降低学生信息维护成本，提高老师工作效率，确保学生信息准确完整。

2. 约束和限制

• 需要支持存储 10w 左右的学生信息

• 支持千级的学生同时在线抢课（按专业分割时段抢课）

3. 总体架构

3.1 架构分析

3.1.1 高可用

学生管理系统，最重要的是学生数据不丢失。所以数据库选用的主备结构，防止数据丢失。

3.1.2 高性能

学生管理系统由于用户群体固定，短期内不会有太短增长。目前架构已经可以满足现状。

3.1.3 可扩展

目前采用分子系统的方式，每个子系统业务明确单一，后续增加个功能可以新增子系统，再单独部署，不影响现有业务。

3.2 总体架构

• 使用 nginx 进行任务分发，将不同的请求分发到不同子系统

• 业务分为三个子系统，分别为：学生子系统，课程子系统，权限子系统。可以做到业务隔离，提高可用性。

• 数据库使用 mysql，一主一备，减少数据丢失的情况。

4. 详细设计

4.1 核心功能

• 学生信息保存

• 学生抢课流程

4.2 关键设计

• 数据一致性：抢课写入数据时，需确认课程剩余人数，如果为 0，需返回失败。采用最简单的方式，在更新的时候加上判断条件，以保证课程人数不超过限制。

• 抢课性能：由于设计方案未加上 redis 缓存，全部通过数据库操作完成抢课流程。需限制同时抢课人数，不同专业的抢课时间应分开时间段设置。

4.3 设计规范

• 学生管理系统服务器统一使用 Spring Boot 开发

• mysql 使用 innodb 引擎

5. 质量设计

成本：六台服务器，其中一台 nginx，三台业务服务器，两台数据库。

数据库：采用主备数据库

6. 演进规划

• 增加 redis 缓存，提升系统性能，可以支持更多学生同时在线抢课。

• 增加考试系统，学生可在线上进行考试，客观题可直接系统批改，减轻老师工作量。