1. 业务背景

随着学校规模的不断扩大，学生数量的逐年增加，待处理的信息日趋增大，急需建设一套学生管理系统用于学校学生的信息管理，实现学生信息管理的系统化、规范化和自动化。系统的主要任务是管理学生相关信息，如：学籍、课程、成绩等。

系统与外界交互关系图如下：

具体要解决的问题如下：

1.1 功能方面

1.  学生教师管理

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

2) 账号分配：学生账号由系统生成，给定相应权限，可进行密码更改，无法对系统成绩评定等功能做出干涉。教师账号由管理者（教务）通过系统生成，教师有评定作业或试卷、更新成绩评定的权限，同时兼容学生权限。管理（教务）权限是系统固有账号，对教师有分配管理权限，对数据有增加、修改、删除、查询权限。

3) 账号绑定：学生账号可通过第三方如：手机号码、微信等自行绑定，可实现账号自助找回等。

4) 组织管理层级：按学生实际情况划分归属。 例如：软件学院—数字传媒方向（专业）—软件 1306—苗雨乔。

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

6) 信息查询：此项功能包含课程查询（含课程体系、课时安排、课表、教师、教材等）、成绩查询、文件查询。

2.  课程管理

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

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

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

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

5) 成绩录入：由教师对相应学生在某一课程中的成绩进行录入或者修改。

3.  权限管理

1) 系统使用者有学生、教师、管理员。

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

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

4) 教师可以上传考试试题，学生可以做题。

1.2 质量方面

1.  可扩展

由于学生管理的业务需求比较复杂，所以系统要具有一定的可扩展性，可以方便的增加业务需求。

2.  数据高可用

学生和教师数据中的部分内容是自己注册的，且课程和成绩信息比较重要，所以数据不能全部丢失。

2. 约束和限制

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

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

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

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

3. 总体架构

3.1 架构分析

架构复杂度分析如下：

1.  可扩展

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

2.  高性能

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

3.  高可用

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

4.  成本

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

5.  安全

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

6.  可维护/可测试/可观测

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

3.2 总体架构

3.2.1 系统架构

系统架构图如下：

学生管理系统采用前后端分离技术开发，系统共分为三层：Web 层、应用层和数据层，下面分别进行说明：

1.  Web 层

Web 层部署 Web 服务（Nginx），部署前端页面，实现对浏览器请求的负载均衡。

Web 服务的 Role 和 Relation 设计：

1)   学生、教师和管理员通过浏览器发出的 Http 请求到 Web 服务；

2)   Web 服务将 Http 请求转发到应用服务，并接收应用服务的响应；

3)   Web 服务将响应返回给浏览器，并展示给用户。

2.  应用层

应用层部署学生子系统、课程子系统、权限子系统三个应用，实现对客户端请求的处理。

应用服务的 Role 和 Relation 设计：

1)   应用服务接收 Web 服务转发的 Http 请求；

2)   应用服务使用 JDBC 访问数据库，并处理请求，将处理结果返回给 Web 服务。

3.  数据层

数据层部署 MySQL 主备库，用来存放学生、教师、课程等信息。

MySQL 的 Role 和 Relation 设计：

1)   接收应用服务通过 JDBC 发出的请求，并进行处理，将处理结果返回给应用服务。

2)   采用 MySQL 主备部署。

3)   直接用 MySQL 的主从复制来实现数据复制。

3.2.2 物理架构

物理架构图如下：

系统使用两台物理服务器，每台物理服务器虚拟化为三台虚拟服务器，共分为三组：

• Web 服务器两台，部署 Nginx 和前端页面，使用 KeepAlive 形成热备部署。

• 应用服务器两台，部署学生子系统、课程子系统、权限子系统，形成一个集群。

• 数据库服务器两台，部署 MySQL，形成主备库。

4. 详细设计

4.1 核心功能

4.1.1 学生注册

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

• 提示学生修改初始密码。

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

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

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

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

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

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

4.1.2 课程录入

• 管理员登录系统。

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

• 系统记录课程信息。

4.1.3 课程选择

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

• 按照分类查询课程信息。

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

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

4.1.4 成绩录入

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

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

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

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

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

4.1.5 成绩查询

1.  教师成绩查询

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

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

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

2.  学生成绩查询

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

• 查看自己所选的课程。

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

4.2 关键设计

4.2.1 可扩展设计

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

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

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

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

4.2.2 高可用设计

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

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

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

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

4.2.3 权限设计

• 为教师和学生设置不同的数据访问权限，使其登录后，只能查看有权数据，并对有权数据进行修改。

5. 质量设计

1.  成本

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

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

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

2.  可维护性

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

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

6. 演进规划

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

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

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