架构设计模块三作业

作者：附加信息

2023-01-01
江苏
本文字数：2803 字
阅读完需：约 9 分钟

外包学生管理系统架构设计

前言

本文是对学生外包系统的中，学生各类信息关系管理的详细设计文档，用于指导后续的开发、测试和运维。

修订历史

词汇表

1. 业务背景

随着学校的规模不断扩大，学生数量的增加，需要处理的信息也日趋增大。由此带来了几个明显的问题：

效率问题：学生信息管理数据信息量大，修改不方便，增删改还容易导致数据错误问题。
性能问题：对学生信息数据分析花费时间长。
可用性问题：学生信息数据量大时，历史信息容易丢失。

基于以上问题，不仅花费大量的教师资源，处理效率也十分低下。因此，提高学生信息的管理水平，优化资源，尽可能降低管理成本，帮助学生管理人员有效管理学生信息，成为学生管理的新课题。

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

2. 约束和限制

1、必须在 2023 年 5 月 1 日之前完成交付；

2、数据库采用 MySQL，后端使用 Java 语言开发；

3、需要能支撑的学生数量和教职工总数量为 1 万；

4、抢课系统要能支撑同时 3.5 千学生的并发申请；

5、学生信息整体数据不可丢失。

3. 总体架构

通过 Nginx 将学生请求接入，下发到各子系统进行处理，并存储到 MySQL 中。

3.1 架构分析

3.1.1 高可用

学校的其他业务系统并不是完全依赖学生管理系统才可运行，因此如果系统故障对学校的整体业务运行无严重影响。但是，学生信息是由人工输入或者学生注册时创建生成，如果整体数据丢失，那么会造成严重的影响。

因此，当前架构需要高可用性，保证已有的学生信息不能全部丢失。

3.1.2 高性能

针对单个学校提供学生管理系统，学生的总人数约 3w 人，因此性能要求并不太高。

而且，针对抢课系统，只要系统未宕机，功能能提供，延时在秒级范围内时可接受的，因此抢课系统也不需要高性能。

3.1.3 可扩展性

当前业务拆分为三个子系统：学生子系统、课程子系统和权限子系统，提供：学生信息管理、课程、考试、权限等功能，业务需求比较复杂，因此需要考虑可扩展性。

3.1.4 成本

系统面向单个学校，成本不是主要问题。

3.1.5 安全

系统仅涉及学生的公开信息，并不涉及交易、隐私信息等，因此安全不是主要问题。

3.2 总体架构

1、Nginx 实现将用户的请求接入消息，解析分发到各个不同的子系统进行处理。

2、按照业务拆分为三个子系统：学生子系统、课程子系统和权限子系统。

3、数据存储使用 MySQL，主数据库日常数据读写、负责实时同步数据到备数据库，以保证数据的高可用性。

4. 详细设计

4.1 核心功能与关键设计

4.1.1 学生管理系统的系统登录流程

用户登录：

1、该系统设计四个角色：学生、教师、管理者和辅导员，登录功能面向所有用户角色，根据用户角色权限不易，功能权限不相同。

2、Nginx 收到用户接入信息后，先分发到权限子系统，进行鉴权。其中，学生、教师、辅导员可以注册、登录、修改自己的信息，但是注册和修改信息需要管理员审核通过。

4.1.2 学生查询成绩流程

学生查询成绩：

1、学生发送查询成绩消息到 Nginx，Nginx 接收到用户请求后，先分发到权限子系统进行鉴权。

2、权限子系统鉴权成功后，发送消息到学生子系统查询成绩，并将承接结果发送到 Nginx，返回给学生用户。

3、学生用户仅可查看自己的成绩，不可查看别人的成绩，且不可修改自己成绩

4.1.3 选课、排课流程

选课功能：

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

在指定时间段内，选课窗口打开，学生进行选课，窗口关闭后则不再可进行线上选课，课程子系统会进行排课。

排课功能：

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

4.1.4 考试发起流程

录入题库：

1、教师预先在课程子系统中录入题库

发起考试：

1、在指定时间点（根据上课的周数进行考试安排），教师创建一次考试。

2、考试题目是在事先录入好的题库中按照教师设定的知识点、范围、难易程度以及题型自动生成的试卷。

3、每创建一次考试之后，教师需要将出好的考试题进行分割点标注，然后印刷试卷，考试。

4.1.5 评分流程

评分判定：

1、教师使用系统对上传的试卷分割区域作出相应的评分。

2、平时成绩：此项功能包含学生平时所有相关成绩信息，例如：考勤主要是由教师终端自动生成的或者教师手动输入，时间期限为当天；课堂笔记主要是由学生在当堂课程结束后将自己的笔记上传然后由教师批阅给予成绩在下次上课前完成自动签名；课后作业主要是在每堂课之后，教师可以发起一次作业任务，学生应老师设定的时间内提交作业，老师会对作业进行批阅，在下次课前给予成绩评分，将以上方式计算得到的总成绩计入平时成绩。最后按照系统判定的平时成绩结合月考、期中、期末试卷成绩按相应比例得出学生最终成绩。

4.2 关键设计

4.2.1 学生信息存储的高可用性

基于前文分析，当前架构需要高可用性，保证已有的学生信息不能全部丢失。因此采用了一主一备两台 MySQL 的服务器，MySQL 服务器之间通过数据复制保证存储高可用。主设备出现复制延迟，对当前业务无影响。但是，如果主备间出现负值延迟，同时 MySQL 主服务器宕机导致数据无法恢复，导致部分信息永久丢失，该情况不做针对性涉及。人工基于最后录入的信息进行检查即可。

4.2.2 学生信息系统的可扩展性

基于前文分析，当前架构需要提供可扩展性，优先将业务拆分成 3 个子系统用来支撑需要提供的各项功能模块。基于当前业务要求，针对单个学校提供学生管理系统，因此使用 MySQL 的主备进行数据保存，Nginx 进行业务分发，可基本维持基本功能。基本功能提供后，后续再基于学生数量增多，考虑优化。

4.2.3 学生信息的数据存储

学生信息按照实际情况划分归属，如：软件学院—数字传媒方向（专业）—软件 1306—苗雨乔。

每个学生信息对应一个 MySQL 表记录，使用学生姓名+学生 ID 为 key 进行对应。

4.3 设计规范

1、业务子系统采用 Spring Boot 作为开发框架；

2、子系统间消息交互采用 HTTPS 协议，数据采用 JSON 格式

3、MySQL 使用 Innodb 存储引擎

5. 质量设计

5.1 可测试性

1、各业务子系统间使用 JSON 数据交互，因此可采用单独的接口测试。

2、可手动触发 MySQL 的主备切换，验证架构的高可用性。

3、利用 MySQL 提供的可测试性能力，对数据的正确性进行测试。

4、白盒测试，通过 DT 用例保证代码覆盖率能达到 90%

5.2 可维护性

1、全链路跟踪

5.3 可观测性

1、用户信息的增删改需要记录日志

2、提供 API 接口查询访问日志

5.4 成本