前言

本文是学生管理系统架构的设计文档，主要用于对系统整体架构的理解和系统的开发、测试和运维。

1. 业务背景

随着学校的规模的不断扩大，学生数量的增加，需要处理的信息也日趋增大。不仅花费大量的教师资源，处理效率也十分低下，各种问题日益显现出来，总结如下：

• 管理问题：主要是随着学生数据量的增多，学员数据的管理变得越来越麻烦，不容易查找和修改。

• 统计问题：主要是针对学员成绩的统计和分析，办公软件统计比较麻烦，对操作者要求较高，需要会使用表格函数等。

• 教学问题：主要体现在排课方面，系统可以快速，准确的进行排课和查询课程安排，极大的提高效率和准确度。

基于以上背景，我们需要设计一个学生管理系统，解决以上问题，提高管理效率。

2. 约束和限制

1， 完成日期：3 个月

2，成本预估：20 万以内

3，数据库采用 mysql

4，部署在第三方云服务器上

5，采用前后端分离模式

6，实现对学生信息的高效管理

3. 总体架构

[必选，描述经过备选架构决策后定下来的架构方案，这一章主要是描述架构的 3R：Rank、Role、Relation]

[技巧：1. 系统边界白盒图描述系统内的角色与外界的交互(Rank + Role + 外部 Relation)；2. 系统架构图来描述内部的 Role + 内部 Relation]

[注意：不建议一张图同时描述系统架构的 3R 以及与外界的交互，因为图太复杂，画系统边界白盒图的时候，系统内部的 Relation 可以不画]

3.1 架构分析

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

[样例：

3.1.1 高可用

对于微博子系统来说，如果消息丢了，导致没有审核，然后触犯了国家法律法规，则是非常严重的事情；对于等级子系统来说，如果用户达到相应等级后，系统没有给他奖品和专属服务，则 VIP 用户会很不满意，导致用户流失从而损失收入，虽然也比较关键，但没有审核子系统丢消息那么严重。

综合来看，消息队列需要高可用性，包括消息写入、消息存储、消息读取都需要保证高可用性。

]

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

3.2 总体架构

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

[样例：此处省略架构图，文字描述样例：

1）采用数据分散集群的架构，集群中的服务器进行分组，每个分组存储一部分消息数据。

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

3）正常情况下，分组内的主服务器对外提供消息写入和消息读取服务，备服务器不对外提供服务；主服务 4）器宕机的情况下，备服务器对外提供消息读取的服务。

5）客户端采取轮询的策略写入和读取消息。

]

[技巧：

1.用系统架构图来描述架构，如果是前端或者客户端，用前端架构图或客户端架构图来描述架构

2.基于架构图中的内容，使用文字描述 Role、Relation 的基本内容，文档目录可以自由调整

]

4. 详细设计

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

4.1 核心功能

4.1.1 学生管理

4.1.2 课程管理

4.1.3 考试管理

4.1.4 权限管理

4.2 关键设计

1）数据的安全性

数据库采用主从复制的模式，主数据库服务器故障后，可切换到从数据库继续工作，避免数据丢失。也可以通过主从数据库实现读写分离，使数据库能支持更大的并发。

2）服务的可靠性

通过 Nginx 实现集群部署，保证服务的高可用性，一个服务宕机，还有服务可以支持访问。

4.3 设计规范

1）采用前后端分离，springboot+vue，前后端通过 json 交互，支持 restful 风格。

2）MySQL 使用 Innodb 存储引擎

3）服务间的数据交互使用 openfegin，做熔断降级的处理

4）用户的登录 token 用 redis 进行存放

5. 质量设计

5.1 学生管理服务

5.2 课程管理服务

5.3 权限管理服务

6. 演进规划

6.1 学生管理系统一期：完成对学生的信息管理、成绩的录入查询、班级管理、排课管理

6.2 学生管理系统二期：完成相应的报表、作业的布置和提交、批改、学员考勤