一、前言

本文是学生管理系统详细架构设计文档，用于指导学生管理系统后续的开发、测试和运维工作。

主要内容包括下面三大部分：

• 学生管理系统的业务背景、约束和限制。

• 总体架构设计和详细架构设计

• 架构质量设计和演进规划。

二、业务背景

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

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

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

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

三、约束和限制

• 控制成本，尽量降低成本。

• 只在学校内部的学生、老师中使用，对系统的性能要求不高。

• 考虑到以后功能的变化和增加，系统要具有一定的可扩展性。

• 由于系统中包含学生和成绩信息，所以数据不能全部丢失。

四、总体架构

4.1. 架构分析

【可扩展】

由于学生管理的业务需求比较复杂，所以系统要具有一定的可扩展性，可以方便的增加业务需求。可以按照功能将学生管理系统拆分成学生管理、课程管理和权限管理三个子系统，降低内部复杂度，提升系统可扩展性。

【高性能】

由于学校内部的学生和教书数量最多在万级左右，所以系统对性能要求不高。而且在拆分子系统后，系统本身的性能就有一定程度的提升，所以本方案中暂不对系统性能做特殊设计。

【高可用】

学生和教师数据中的部分内容是自己注册的，且课程和成绩信息比较重要，所以数据不能全部丢失，需要设计数据的高可用方式。另外，为了保证系统的计算高可用，同一个子系统应避免出现单点故障，通过集群或多点部署的方式实现计算高可用。

【成本】

 由于是学校内部使用，所以要尽量降低成本。同时，也需要严格控制开发成本。

【安全】

  应严格控制访问权限，防止出现个人信息和成绩被他人访问的问题。

【可维护/可测试/可观测】

 由于系统主要是在学校内部使用，系统会交付给学校内的系统管理员进行维护，所以系统要设计的相对便于维护，并可与学校现有的运维平台进行对接。系统对可测试性、可观测试的要求不高。

4.2. 总体架构

五、详细设计

5.1. 核心功能

【学生注册】

1.  学生使用学号和初始密码登录系统。

2.  提示学生修改初始密码。

3.   学生对初始密码进行修改后，重新登录系统。

4.   学生进入手机号或微信绑定页面。

5.   学生录入手机号或微信号，并进行验证。

6.   系统发送验证信息到绑定的手机号或微信号。

7.   学生在界面录入验证信息，完成验证操作。

教师注册与学生注册的流程类似。

【课程录入】

1.   管理员登录系统。

2.   录入课程名称、分类、授课讲师等详细信息，并保存。

3.   系统记录课程信息。

【课程选择】

1.   学生使用学号和密码登录系统。

2.   按照分类查询课程信息。

3.   学生选择要学习的课程，并点击确定。

4.   系统保存课程与学生的对应关系。

【成绩录入】

1.   教师使用教师 ID 和密码登录系统。

2.   教师查询自己所授课程下所有学生的信息。

3.   系统返回所有选择该课程的学生列表。

4.   教师为每个学生录入成绩，并保存。

5.   系统将成绩记录在学生与课程对应关系中。

【成绩查询】

1.   教师成绩查询

1)   教师使用教师 ID 和密码登录系统。

2)   教师查询自己所授课程下所有学生的信息。

3)   系统返回所有选择该课程的学生列表以及对应的成绩。

2.   学生成绩查询

1)   学生使用学号和密码登录系统。

2)   查看自己所选的课程。

3)   系统返回学生所选课程及对应的成绩。

5.2. 关键设计

【可扩展设计】

系统拆分为学生子系统、课程子系统、权限子系统三个子系统，可以满足可扩展的要求。

1. 可理解性，系统拆分后，每个子系统的功能更加单一，更便于开发人月的理解。对某个功能进行修改的时候，只需要升级对应的子系统即可。

2. 可复用性，子系统中的功能更加内聚，更易于提取公共组件，形成组件级的复用。

3. 可伸缩性，拆分后可以实现对某个子系统资源的扩展，而不需要对整体的资源进行扩展。

【高可用设计】

1. Web 服务器两台，部署 Nginx 和前端页面，使用 KeepAlived 形成热备部署，防止 Nginx 出现单点故障。

2. 应用服务器两台，部署学生子系统、课程子系统、权限子系统，形成一个集群，通过 Nginx 将 Http 请求分发到不同的 Server 中，防止应用出现单点故障。

3. 数据库服务器两台，部署 MySQL，通过数据复制形成主备库，防止数据丢失。正常只有主库对外提供读写服务，当主库发生异常时，可以手工切换到备库对外提供服务。

4. 两台物理服务器，每台上都部署有完整的学生管理系统，如果其中一台出现故障，那么另一台经过一定的切换操作（例如：MySQL 的主备切换）可以接管系统。

六、质量设计

【成本】

为降低硬件成本，可以采购 2 台支持虚拟化的服务器，每台虚拟化成 3 台配置不同的虚机，一台虚机部署 Nginx、第二台虚机部署三个子系统的应用、第三台部署 MySQL。这样，两台物理服务器上都具有完整的学生管理系统。

同时，如果学校中已有 Nginx 服务器或其他可以提供负载均衡能力的设备，那么 Nginx 服务器也可与其他系统共用，以便进一步降低硬件成本。

为了降低开发成本，采用目前比较成熟的 SpringBoot+Vue 框架进行开发，提升开发效率，同时全部采用开源基础软件，减少基础软件采购成本。

【可维护性】

采用成熟且使用较多的开发框架和基础软件，便于维护。

分成三个子系统，每个子系统功能内聚，已于理解。

七、演进规划

• 由于学生、教师和课程的数量不会发生太大变化，所以暂时不考虑系统的演进规划。

• 如果后续出现性能瓶颈，可以先采用添加服务器的方式，将部署应用和数据库服务的虚拟机部署在不同的物理服务器上，以便提升性能。后续还可以将三个应用分别部署在不同的虚拟机，以便进一步提升系统处理能力。

• 如果上述调整仍不能满足性能需要，可考虑增加服务的数量。