前言

本文档是外包学生管理系统的详细架构文档，用于指导学生管理系统的业务开发、测试及运维。

词汇表

Netty: 开源的网络编程框架

Spring Boot: 简化了 Spring 开发的轻量级框架

Nginx：高性能的 HTTP 和反向代理 Web 服务器

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

Vue：构建用户界面的渐进式框架

1. 业务背景

1.1 当前现状

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

1.2 设计目的

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

1.3 系统价值

学生信息管理系统可以通过系统规范化地管理、科学性统计和快速查询、修改、增加、删除等，提高信息的准确度以及日常管理的工作效率。

1.4 系统目标

本系统主要是应用于学生各类信息的管理，总体任务是实现学生信息关系的系统化、规范化、自动化，其主要任务是统计学生各类信息进行日常管理，如查询、修改、增加、删除、以及学生选课、成绩的查询等功能设计的管理系统。

1.5 黑盒图

2. 约束和限制

1. 系统必须在 3 个月内号完成开发

2. 服务器必须从知名服务器厂商选购（华为、浪潮、新华三、联想、戴尔等）

3. 所选服务器必须购买同一厂商产品

4. 成本需控制在 50 万元以下

5. 数据库采用 MySql

6. 代理使用 Nginx

7. 可用率达到三个 9，即 99.9%

3. 总体架构

3.1 架构分析

3.1.1 高可用

3.1.1.1 计算高可用

由于该系统属于后台管理系统，使用的频率不会太高，教师、学生访问的次数也不会太频繁，出现偶尔的宕机，能在一定的时间恢复即可，对实时性要求不是很高。

3.1.1.2 存储高可用

由于系统的信息数据来源为人工录入，个别数据丢失可以接受，但如果有大量数据丢失的情况出现，再次录入会非常麻烦，客户体验会非常不好，同时又考虑到后续新增、更新的频率不会很高，所以存储高可用不用做太复杂，用 Mysql 的主备，一主一备，定时做备份，当主机发生故障时，用备机进行数据恢复或者将备机升级为主机。

3.1.2 高性能

由于该系统主要面向一个学校的学生，学生数量不会太多，可能最多几万学生，面对可能产生最大并发量的选课功能，由于同一门课可选的学生数量并不会太大，数量最多上千，最有可能是几百，所以对并发的性能要求也不是很高。

3.1.3 可扩展

根据需求背景来分析，该系统要求涵盖的功能比较多、业务比较复杂，同时不排除后续可能增加、更新或删除某些业务功能，所以对系统的可扩展性要求还是比较高的，在这方面要重视。

3.1.4 安全性

由于该管理系统只是在学校内部使用，供老师、学生以及学校管理员内部人员使用，不对外开放，所以在安全性方面不做过多考虑。

3.2 总体架构

总体架构图

职责说明

Nginx：

1. 反向代理，将 Nginx 配置为 Url Hash 模式，将不同的 url 访问定向到不同的服务器，此处是根据相应的 url 路径分别定向到学生子系统、课程子系统以及权限子系统。

子系统（业务）：

1. 主要根据相应的请求，同时结合相应用户角色的权限，去执行角色相对应的操作。

2. 主要的任务是统计学生各类信息进行日常管理，如查询、修改、增加、删除、以及学生选课、成绩的查询等功能。

存储系统

1. 虽然现阶段业务整体对高可用的要求不高，但还是要保证适当的可用性，所以数据库存储采取一主一备的方式，因为只有一主一备，且数据量不是很大，所以同步方式可采用全同步复制或异步复制，但是考虑到后续业务量可能变多，数据量也会相应增大，往后可能会扩展到一主多备模式，为了保证可扩展性，同时也为了保持性能，所以同步方式采取异步复制。

系统边界白盒图

4. 详细设计

4.1 核心功能

4.1.1 查询课程

• 根据用户名先获取用户 ID，然后根据用户 ID 去权限子系统去查询相应的权限，最后根据权限返回相应权限范围内的课程信息。

4.1.2 选课

• 同样也是先获取用户 ID，根据用户 ID 获取权限，再根据权限获取相应的可选课程的范围。

• 进行选课时，先查询所选课程的可选数量（因为页面可能更新不及时）：

• 如果可选数量大于 0，则进行更新，考虑到可能多人同一时刻可能选择同一门课程，此处应对数据库更新信息进行判断，如果成功则返回相应成功信息，并进行后续流程操作；如更新数据库失败，则返回相应的失败信息。

• 如果可选数量等于 0，则返回不可选择信息。

4.2 关键设计

4.2.1 子系统功能

4.2.1.1 学生子系统：

1. 学生可以将自己课堂笔记、日常作业等相关信息在线传输，上传到该系统。

2. 教师通过学生上传的相关作业、试卷信息进行相应评定，完成对学生平时成绩的评定。

3. 该系统还提供信息查询，主要包含课程查询(含课程体系、课时安排、课表、教师、教材等)、成绩查询、文件查询。

4.2.1.2 课程子系统：

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

2. 学生可以在线对自己的课程体系进行选择，相对应的课程选择功能类比

3. 此功能根据学生选定的课程和教学体系安排，对相应教师、教室、时间进行统一规划安排。

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

5. 考虑到每门课程都有相应的考试，而且成绩也都会相应的挂到课程下面，所以将考试管理合并到课程子系统，方便统计和管理。

4.2.1.3 权限子系统

1. 针对学生、教师、管理员、辅导员不同的角色分配不同的操作权限。

4.3 设计规范

1. 后端使用 Spring Boot + Netty 开发

2. 前端使用 Vue 进行开发

3. 前后端交互采用 Json 格式

4. Nginx 设置为 Url Hash 模式，更好的路由到不同的业务服务器

5. MySQL 使用 Innodb 存储引擎

6. MySQL 使用一主一备，同步方式为异步复制

5. 质量设计

5.1 可测试性

5.1.1 子系统内单元测试

各自模块内，梳理好测试场景，针对不同的场景和不同的代码模块做好单元测试，保证代码覆盖率达到 90%以上，核心逻辑代码的覆盖率达到 100%，场景的覆盖率也达到 100%。

5.1.2 子系统间集成测试

各个模块对自己开发的接口都要有详细的描述，增加子系统间做集成测试时调用的方便性。

5.2 可维护性

各模块梳理好核心场景，针对核心场景进行埋点，同时做好调用链设计，方便出问题时，可以根据日志方便的进行定位与维护。

5.3 可观测性

可以在各个子系统部署一些采集性能数据的 agent，实时采集服务的运行情况和机器的负载情况，采集脚本将采集到的数据存储到数据库（设计一些表单独存放采集数据），同时做一个简易可视化数据治理界面，结合采集到的数据，做一个简单的 Dashboard，展示服务的运行情况以及机器的性能情况。

5.4 成本

由于前期数据量不是很大，可以考虑将三个服务部署到同一台服务器上；为了保证可用性，一主一备的数据库需分别部署在两台服务器上，总共需要三台服务器。

6. 演进规划

6.1 二期演进方向

1. 后续可专门开发一套服务治理平台，有单独的团队负责维护，如要必要，可引进 ElasticSearch 作为调用链信息的存储数据库。

2. 前后台的数据调用格式可从 Json 转换为 Protobuf，不论从性能方面还是内存方面都能得到明显提升。