前言

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

1. 业务背景

1.1 背景介绍

随着 XX 学校的规模不断扩大，学生数量的增加，需要处理的信息也日趋增大。现在学生信息管理的相关工作，有明显以下几个问题：

• 需要花费大量的教师资源来处理学生信息，不够自动化，效率极其低下。

• 当前在校学生有 1 万多人，学生信息较多，分析处理时间长。

• 学生各类信息定义不规范，各个学科年级的学生信息各自为政，没有统一数据视图。

1.2 实现目标

针对上面的存在学生信息管理的问题，建设一个本校学生信息管理系统，实现以下的目标：

• 统一全校学生信息处理流程，系统化、规范化、自动化。

• 系统业务功能涵盖学生基础信息管理、课程管理、考试管理等。

• 统一管理访问系统权限。

• 建立全校学生统一数据视图，方便统计分析。

1.3 系统定位

• 本系统归属学校信息化架构体系，与学校其他系统如 LDAP、财务系统对接

• 学生和教师通过校园网访问本系统

2. 约束和限制

针对当前 XX 学校的情况，本系统设计上有以下约束和限制：

1. 赶在 8 月份新生报到完成，还有三个月时间。

2. 系统软件，中间件尽量采用开源方案，减少成本。

3. 开发人员 3-5 人以内。

4. 要有一定的访问控制保证访问安全。

3. 总体架构

3.1 架构分析

3.1.1 业务复杂度

学生管理系统按照设定目标，需要管理学生信息、课程信息、考试信息。这些信息的业务流程不一样，具有一定的业务复杂性。采用才分子系统的方式，每个子系统负责一块业务，业务复杂性封装在子系统里，某块业务的修改不影响其他业务。

3.1.2 高可用

学生信息是学校重要财产之一，所以学生信息数据存储一定要保证存储的高可用。

按照跟学校方的沟通，系统的可用性上能忍受一定的故障时间，约一天左右，计算高可用可暂不考虑。

3.1.3 高性能

当前 XX 学校所有教职员和学生加起来万人左右。根据学校未来几年的规划，人数将维持这个规模，不会出现太大的增长，所有业务场景的访问量都不大。在学期开始、期末会是访问高峰，但由于学校人数总体体量较小，高性能可暂不考虑。

3.2 总体架构

3.2.1 系统边界与外系统关系

• 学生和教师通过浏览器在校园网访问本系统

• 登录访问请求到权限子系统，权限子系统请求学校 LDAP 身份认证

• 学生信息和课程信息访问学生子系统和课程子系统

• 学生子系统对接财务系统，获取学生学费相关信息

• 对于长久不再使用的数据（如已毕业学生信息），归档到学校统一数据归档服务器。本系统随后进行数据清理。

3.2.2 系统内部架构

• 前端页面资源部署在 Nginx 服务器

• 学生和教师通过浏览器访问本系统，请求通过 Nginx 作分发

• 本系统划分学生子系统、课程子系统、权限子系统

• 学生子系统管理学生学籍信息

• 课程子系统管理课程信息，学生可通过课程子系统进行选课以及查看考试成绩

• 权限子系统控制访问权限

• 学生子系统和课程子系统的请求都需要先访问权限子系统，获取是否有权限操作

• 数据库采用 MySQL，两台数据库分主库和备库，作主从复制

4. 详细设计

4.1 核心功能

4.1.1 权限子系统

1. 权限子系统使用包含两个场景，登录场景和请求服务场景

2. 登录场景和请求学生子系统场景，作系统序列图如下：

• 采用 RBAC 模型，授予学生和教师两种角色，根据角色授予不同的操作权限

• 登录时，通过权限子系统请求学校 LDAP 服务器认证身份

• 身份认证成功，权限子系统根据身份对应的角色，渲染不同的页面菜单给前端，并返回角色信息

• 请求操作时，请求带上身份信息，学生子系统先请求权限子系统，判断该角色信息和请求操作的权限是否符合。如果符合才进行下一步业务处理。

4.1.2 学生子系统

1. 教师在学生子系统录入学生学籍信息。

2. 学生在学生子系统查询个人信息，包括基本信息、已报课程信息、考试分数、费用情况等。

4.1.3 课程子系统

1. 教师在课程子系统录入课程信息

2. 学生通过课程子系统选课。

4.2 关键设计

4.2.1 存储高可用

学生数据是学校重要的财产之一，一开始就要考虑存储的高可用。最简单的方式就是采用两台数据库作主库和备库，然后作主从复制。根据业务数据量和访问预估，两台 MySQL 数据库能够胜任当前以及未来几年内的业务需求。

主从复制只有几种方式：同步、半同步和异步。由于只用一个从库，且场景是读多写少，写场景大部分是教师录入数据，响应要求不高，所以首先采用同步复制的方案，简化开发配置。

4.2.2 RBAC 配置

学生和教师具有不同的权限，如教师可以录入和修改学生成绩，学生只能查看。为保证业务的安全性，采用 RBAC 模型，根据角色分配权限。权限子系统根据登入的请求身份，获取对应的角色，返回角色信息，角色信息保存在浏览器 Cookie。

登录接入访问权限子系统，根据不同的角色渲染页面，显示不同的菜单。

4.3 设计规范

4.3.1 开发框架和选型

1. 应用服务器开发框架采用 Spring Boot。

2. 前端渲染采用 Thymeleaf。

3. ORM 框架采用 MyBatis。

4. 操作系统采用 Linux。

5. JDK 采用 JDK 1.8。

6. 数据库采用 MySQL，使用 InnoDB 存储引擎,采用同步主从复制方式。

7. Nginx 服务器作接入反向代理。

4.3.2 接入请求规范

1. 浏览器通过学校门户下二级域名进入：www.xxxSchool.edu/studentSys/
   

2. 访问协议为 HTTPS，与学校门户共用同一证书。

3. 学生子系统、课程子系统和权限子系统请求为三级域名。

4. 学生子系统、课程子系统访问请求均为 HTTP GET 请求，数据提交为 POST 请求。

5. 权限访问请求都是 POST 请求。

6. HTTP 请求体报文均为 JSON 报文。

7. 子系统间请求采用 HTTP 的 REST 请求。

8. 与外系统间请求，接口定义与外系统协商。

5. 质量设计

5.1 可测试性

为了保证系统测试完成，部署另外一套测试环境作测试运作。测试环境机器配置可以比生产环境低。

5.2 成本

5.2.1 机器配置

• Nginx 服务器：4C/8GB 内存/500GB 硬盘 1 台

• 应用服务器：4C/16GB 内存/1T 硬盘 3 台

• 数据库服务器：4C/16GB 内存/4T 硬盘 2 台

5.2.2 系统软件

采用开源方案，操作系统采用 Linux 服务器版，数据库采用 MySQL

6. 演进规划

6.1 学生管理系统一期

本文档描述的架构和功能为一期实现内容，项目计划如下：

• 详细方案设计：一周

• 开发和单元测试：四周

• 集成测试和用户测试：五周

• 上线试运行：一周

6.2 学生管理系统二期

二期规划计划实现以下功能：

1. 增加管理控制端，可以配置角色权限。

2. 增加监控功能，可实时监控系统运行状态

3. 实现前后端分离，前端功能采用 React 等前端框架实现