1. 业务背景

当前现状

随着学校的规模的不断扩大，学生数量的增加，需要处理的信息也日趋增大。不仅花费大量的教师资源，处理效率也十分低下。

为提高学生管理的管理水平，优化资源，尽可能降低管理成本成为学生管理的新课题，学生管理系统是从学生管理现状出发，根据学生管理的新要求进行开发设计的，它需要解决学生信息管理数据信息量大修改不方便，对一系列数据进行分析时花费时间长等问题，帮助学生管理人员有效管理学生信息。

项目目标

设计一个学生信息管理系统，系统主要应用于学校学生信息管理，总体任务是实现学生信息管理的系统化、规范化和自动化，其主要任务是管理学生相关信息，如学籍、课程、成绩、奖惩。

本系统主要实现：

1. 学生管理模块

2. 系统登录：功能面向所有用户角色，根据用户角色权限不一，功能权限也不一样。

3. 账号分配：负责给予账户绑定不同角色-学生、教师、管理员；

4. 账号绑定：手机号码、微信等自行绑定，可实现账号自助找回等

5. 组织管理层级：学生隶属学院、专业、年级、班级等

6. 文件上传、下载：学生可以将自己课堂笔记、日常作业等相关信息在线传输，教师通过学生上传的相关作业、试卷信息进行相应评定，完成对学生平时成绩的评定。此功能一旦评定结束，所有用户只有查询、浏览的权限，除管理员外其他用户没有对成绩修改的权限。

7. 信息查询:此项功能包含课程查询(含课程体系、课时安排、课表、教师、教材等)、成绩查询、文件查询。

8. 课程管理模块

9. 课程录入：管理员对相应课程体系进行录入、供教师、学生在线选择

10. 选课功能

11. 排课功能：此功能根据学生选定的课程和教学体系安排，对相应教师、教室、时间进行统一规划安排。排课功能备选开发方向为在线排课和人工录入，在线排课是系统根据课程要设置课程的名称、课时、上课的班级、代课老师等信息，除此之外，还可以选填排课时的优选项，例如:上课时间有限上午等系统自动生成课程信息，管理员有权限对课程安排作出添加、删除、修改等判定

12. 教材选择：此功能由教务统一管理，根据每门课程选定相应教材。

13. 权限管理模块

14. 系统使用者有学生、教师、管理员、辅导员。

15. 学生、教师、辅导员可以注册、登录、修改自己的信息，但注册信息需要管理员审核通过。

16. 学生只能查看自己的成绩，教师可以修改学生的成绩。

17. 辅导员可以查看学生的信息，可以设置学生的奖惩信息。

18. 教师可以上传考试试题，学生可以做题。

2. 约束和限制

1.学校一届学生大概几千人，算上教职工不超过 1w 人，连研究生博士生大概 5w 人

2.因为是内部系统，允许有一定的宕机，不允许数据丢失。

2.数据具有实效性，在校生数据会有较多 CRUD 行为，离校生更多是查询

3.符合架构设计三原则，需要考虑简单、适合，尽量使用开源组件，机器资源不宜成本过高

4.项目可扩展性、可移植强，方便后续适用其他高校

3. 总体架构

3.1 架构分析

[可选，这部分主要是架构复杂度的分析，基本上从备选架构文档中提炼关键内容过来即可]

[技巧：常见的复杂度都要覆盖到，即使分析后不涉及也要描述，避免评审的时候被人认为遗漏了关键点]

1. 性能上面：由于是学校内部，在校师生不超 5w，同时在线人数 qps 不会超 5000，mysql 单机性能能满足。

2. 高可用：数据需要保证可靠性不丢失，因此需要主备；内部使用可用性没有太高要求，因此每个系统部署 2-3 个实例保证平滑升级避免单点即可，无需进行多机房部署；

3. 可扩展：学生量上不会有较大增长，后期仅需考虑其他子系统接入；DB 可能会逐年增加，后期可考虑基于范围的分库策略，将历史数据与实时生产数据分库

4. 成本、安全：

5. 成本：因为是在高校内部，因此尽量复用高校已有机器部署服务；开发上尽量使用开源组件和方案进行系统的可维护、可监控、可观测；语言上尽量使用 java 或 go + nodejs 等常规业务开发等从业较多门槛低的技术栈，方便后续开发维护。

6. 安全性上：架构上可以做下网络隔离，仅校内网可用；业务上做好权限管控包括 sso 单点认证等。

3.2 总体架构

[必选，描述总体架构设计]

系统边界白盒图

系统架构图

1）每个系统部署单独微服务并部署多个实例实现负载均衡。

2）每个分组包含一台主 MySQL 和一台备 MySQL，分组内主备数据复制，分组间数据不同步。

4. 详细设计

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

4.1 核心功能

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

[样例：

4.1.1 消息发送流程

4.1.2 消息消费流程

]

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

4.2 关键设计

4.3 设计规范

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

[样例：

1）消息队列服务器使用 Spring Boot + Netty 开发

2）MySQL 使用 Innodb 存储引擎

3）TCP 包的结构设计……（此处省略，请自行补充）

]

[技巧：如果某个规范涉及内容比较多，请独立章节描述，例如数据包格式定义]

5. 质量设计

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

[样例：

5.1 消息队列管理后台

5.2 成本

]

[技巧：如果某个维度不涉及，也请在文档中说明，避免评审的时候被认为考虑不周全]

6. 演进规划

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

[样例：

6.1 消息队列一期

6.2 消息队列二期

]

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