前言

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

词汇表

Nginx：反向代理服务

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

1. 业务背景

随着学校规模的不断扩大，学生数量增加，需要处理的信息日趋增大，目前学生管理方式是通过纸质档案或电子档案(Excel)完成，由此带来一些问题：

• 效率问题：学生相关信息的录入与维护(含选课排课)需要耗费大量的教师资源，且每年新生进入需花费许多重复工作量，纸质档案对于搜索学生信息需要耗费大量时间。

• 安全问题：

• 纸质档案: 随着时间推移存在字迹褪色、照片破损甚至纸质原件丢失的问题

• 电子档案: 易复制，不易察觉，存在信息泄露问题；存在多人编辑相同数据造成数据混乱，数据权限控制困难问题

• 存储问题：

• 纸质档案：档案存储需要较大的馆藏空间；异地档案备份需要一定的人工搬运，工作量大且效率低

• 电子档案：档案备份需要人工操作，存在忘记操作的风险

基于以上背景，我们需要从 0 到 1 建立学生管理系统，利用信息化技术支持学生管理工作。

2. 约束和限制

1. 人数要求：在校学生人数大约 30000 人，在职教职工人数大约 7000 人

2. 存储要求：数据库采用 Mysql

3. 容灾要求：具备数据容灾能力，意外情况允许 1‰的数据丢失，备机切换响应不超过 1 个工作日

4. 运行要求：系统支持 7*24 小时稳定运行,支持同时在线人数不超过 500 人

5. 成本要求：不超过 100 万

6. 质量要求：符合国标 GB-T8566--2001G

3. 总体架构

3.1 架构分析

3.1.1 高可用

对于学生管理系统来说，如果系统意外宕机，导致无法在线排课选课，虽然会影响教务工作完成效率，但是不会导致相关教务工作无法进行；另全量数据丢失会导致大量的数据录入工作，造成非必要的工作消耗，则会降低教职工对系统的使用积极性，但全量数据丢失也不会造成教务工作停滞。

综合来看，学生管理系统需要一定的高可用性，至少在数据存储方面要保证数据不能全部丢失。

3.1.2 高性能

对于学生管理系统来说，总体使用人数大约不超过 50000 人，常用功能峰值访问量不高，高性能在此不适用。

3.1.3 可扩展

对于学生管理系统来说，业务涉及角色较多，角色之间的关系相对复杂，因此需要对业务进行拆分以降低业务复杂度。

3.2 总体架构

1. 采用 Mysql 主备数据复制方式进行数据备份

2. 拆分成"学生子系统"、"课程子系统"及"权限子系统"三个子系统，降低业务之间的复杂关系

3. 采用 Ningx 反向代理服务

4. Mysql 主服务器宕机时，Mysql 备用服务器对外提供服务

5. 子系统的拆分为未来提供评论子系统、后勤服务子系统扩展支持

4. 详细设计

4.1 核心功能

4.1.1 学生选课流程

4.1.2 教师排课流程

4.1.3 试卷管理流程

4.2 关键设计

1. 业务可扩展

拆分成三个子系统，各子系统专注于不同领域的业务实现，便于后续扩展其他功能

1. 数据可用性

Mysql 主备: Mysql 主服务器宕机，手工切换应用服务器至 Mysql 备用服务器；如果 Mysql 主备服务器出现复制延迟，恰好此时 MySQL 主服务器宕机导致数据无法恢复，则部分数据会永久丢失，这种情况不做针对性设计，DBA 需要对主备间的复制延迟进行监控，当复制延迟超过 30 秒的时候需要及时告警并进行处理。

3. 开发与成本控制

三个子系统对应开发过程中的三个项目模块，三个子系统作为一个整体项目部署在同一个应用容器，降低部署成本、降低运维复杂度.

4.3 设计规范

1. 业务服务使用 Spring Boot + Open JDK 1.8 开发

2. Mysql 使用 Innodb 存储引擎

3. 前端使用 Nginx + Nodejs + Npm 开发部署

4. 服务部署容器使用 Apache Tomcat

5. 服务接口遵循 Restful 风格

6. 使用 Swagger 展示接口 API

7. 统一使用 log4j2 记录日志

8. 使用 Git 进行代码版本控制

9. 服务数据响应使用 json 格式

{	"code":1001,           #响应码，统一规范返回码，不同响应码代表不同的响应结果  "message":"success",   #由响应码转换成对应的响应信息  "data":[{..}]          #服务返回的数据，JSONArray形式}

5. 质量设计

5.1 可测试性

主动切换 Mysql 备机，系统能正常运行；Mysql 备机切换到 Mysql 主服务器，系统正常运行

5.2 可维护性

应用服务意外宕机不会对日常教务工作造成阻塞性灾难，对系统恢复正常使用容忍性较高，只需支持通过命令行可进行应用重启即可。

5.3 可观测性

应用服务意外宕机不会对日常教务工作造成阻塞性灾难，对系统恢复正常使用容忍性较高，此处不设计应用监控管理。

5.4 成本

系统做服务拆分但部署架构不拆分应用，考虑到系统意外宕机并不会造成严重影响，只需手动重启应用服务，因此服务全部部署在同一应用容器，降低硬件成本，便于维护。

6. 演进规划

6.1 学生管理系统一期

完成学生子系统、课程子系统、权限子系统业务功能开发

6.2 学生管理系统二期

建设服务监控预警、应用启停管理系统