前言

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

1. 业务背景

[必选，从以下常见的角度来回答，你准备构建或者重构系统的目的和所处的位置是什么，可以是 1 个角度，也可以是多个角度，一般挑选重点的 3 个目的就差不多了：1.解决什么问题；2.带来什么价值；3.实现什么目标；4.完成什么任务；5.处于什么地位。

]

随着我国高等学校的快速发展，特别是近年来的大规模扩招，很多高校的学生规模达到数万人，其中本科院校平均在校生达到 1.5 万人。学校规模的增大给高等院校的学生信息管理带来不少的冲击，学生学籍、课程、成绩、奖惩和异动等方面的数据量大，难以单纯地依靠人工管理，传统的人工管理方式存在以下问题：

• 管理效率低，管理人员的工作负担高

• 消耗太多人力物力，管理成本高

• 管理不规范，不利于学生信息的规范化和科学化管理

基于上述背景，开发一套适合高等院校实际情况的学生信息管理系统，实现学生信息管理的信息化和规范化，提高学生管理效率和管理水平，降低管理成本。

2. 约束和限制

• 成本不超过 15 万元

• 2022.7.1 完成开发和测试

• 2022.7.31 前完成部署

• 2022.8.20 开学投入使用

• 公网可访问（域名）

• 数据库采用 MySQL

3. 总体架构

3.1 架构分析

根据学生信息管理系统的需求，学生信息管理系统包括管理员、教师和学生三种用户角色。学生信息管理系统包括学生子系统、课程子系统和权限子系统：

• 学生子系统提供学生基本信息、奖惩、学籍异动和成绩等信息的管理。

• 课程子系统提供课程信息的管理功能。

• 权限子系统提供身份认证、账号管理、角色管理和权限管理功能。

学生管理系统的复杂度情况分析：

• 高性能：系统支撑 5 万名学生，期末期间查询成绩相对集中，并发量 1000 左右，其他时间系统的访问量较为均匀且不高，因此，这个访问规模对系统性能要求不高。

• 高可用：学校的教学管理环节对系统的依赖程度较低，系统故障不会产生较大影响。系统不能因为故障导致学生数据大量丢失，一旦丢失将很难弥补，因此，该系统对数据高可用有较高要求。

• 可扩展：学生管理系统涉及基本信息、课程、成绩、奖惩、异动和毕业等环节，业务有一定复杂度，因此，要求系统具有良好的可扩展性。

• 安全性：面向单个学校，虽然公网可访问，但只涉及公开数据，而不涉及资金、隐私等敏感数据，因此，不需要过多考虑。

• 成本分析：项目预算 15 万元，必须做好成本控制。

综上所述，学生管理系统的业务功能不复杂，对性能要求不高，对数据可用性和可扩展性有较高要求，项目预算较低，需做好成本控制。

3.2 总体架构

基于上述分析，设计了学生管理系统的总体架构，如下图所示。

1）采用 Nginx 作为负载均衡器，负责将服务请求转发给相应服务子系统。

2）服务器按业务功能拆分部署，每台服务器布署一个子系统。

3）数据库采用 MySQL 主备架构，主库提供 CRUD 功能，备库用于主库的实时备份。

4. 详细设计

[必选，描述核心场景或者流程的实现机制]

4.1 核心功能

[必选，描述核心场景或者流程的实现机制，对应 4R 架构中的 Rule，每个核心场景一个小节]

[样例：

4.1.1 消息发送流程

4.1.2 消息消费流程

]

[技巧：使用系统序列图来描述 Rule，跟项目开发中写设计文档一样的写法]

4.2 关键设计

[必选，描述系统的一些关键设计点是如何实现和取舍的]

[样例（如果你有兴趣，可以对比一下 kafka 的文档：Kafka design）：

[技巧：常见的关键设计点包括高性能、高可用、可扩展、安全等]

4.3 设计规范

[必选，描述 Role 和 Relation 相关的开发框架、连接协议、数据包格式等]

5. 质量设计

[必选，描述和质量相关的设计，包括：可测试性、可维护性、可观测性、成本等设计]

可测试性：单元测试用例。

可维护性：设计文档，使用说明书。

可观测性：系统监控及预警，系统日志和操作日志的查询和管理。

成本：控制在 15 万以内。

6. 演进规划

[必选，可以是演进规划，也可以是项目计划，需要描述每个里程碑或者版本具体要实现的能力]

[样例：

6.1 消息队列一期

6.2 消息队列二期

]

[技巧：开发阶段快速迭代，小步快跑，但要基本完善后才能正式推出给其他人用]