学生管理系统详细架构设计
1. 前言
本文是学生管理系统详细架构设计文档，用于指导学生管理系统后续的开发、测试和运维工作。
主要内容包括下面三大部分：
学生管理系统的业务背景、约束和限制。
总体架构设计和详细架构设计
架构质量设计和演进规划。
2. 词汇表
Spring Boot：是一些公共库的集合，它能够被任意项目的构建系统所使用基于 Spring4.0 设计，不仅继承了 Spring 框架原有的优秀特性，而且还通过简化配置简化了 Spring 应用的整个搭建和开发过程。
Vue：是一套用于构建用户界面的渐进式框架，可以为复杂的单页应用提供驱动。
ElementUI：一套为开发者、设计师和产品经理准备的基于 Vue 2.0 的桌面端组件库。
Mybatis：是一个基于 Java 的持久层框架，包括 SQL Maps 和 Data Access Objects（DAOs）。
KeepAlived：检测服务器状态，并自动将有故障的服务器从系统中剔除。
3. 业务背景
随着学校规模的不断扩大，学生数量的逐年增加，待处理的信息日趋增大，急需建设一套学生管理系统用于学校学生的信息管理，实现学生信息管理的系统化、规范化和自动化。系统的主要任务是管理学生相关信息，如：学籍、课程、成绩等。
系统与外界交互关系图如下：
具体要解决的问题如下：
3.1 功能方面
1. 学生教师管理
1)系统登录，面向所有用户角色，根据用户角色权限不一，功能权限也不一样。
2)账号分配：学生账号由系统生成，给定相应权限，可进行密码更改，无法对系统成绩评定等功能做出干涉。教师账号由管理者（教务）通过系统生成，教师有评定作业或试卷、更新成绩评定的权限，同时兼容学生权限。管理（教务）权限是系统固有账号，对教师有分配管理权限，对数据有增加、修改、删除、查询权限。
3)账号绑定：学生账号可通过第三方如：手机号码、微信等自行绑定，可实现账号自助找回等。
4)组织管理层级：按学生实际情况划分归属。 例如：软件学院—数字传媒方向（专业）—软件 1306—苗雨乔。
5)文件上传/下载：此功能针对所有用户开放，学生可以将自己课堂笔记、日常作业等相关信息在线传输，教师通过学生上传的相关作业、试卷信息进行相应评定，完成对学生平时成绩的评定。此功能一旦评定结束，所有用户只有查询、浏览的权限，除管理员外其他用户没有对成绩修改的权限。
6)信息查询：此项功能包含课程查询（含课程体系、课时安排、课表、教师、教材等）、成绩查询、文件查询。
2. 课程管理
1)课程录入：由管理员对相应课程体系进行录入，供学生、教师进行在线选择。
2)选课功能：学生可以在线对自己的课程体系进行选择，相对应的课程选择功能类比。
3)排课功能：此功能根据学生选定的课程和教学体系安排，对相应教师、教室、时间进行统一规划安排。排课功能备选开发方向为在线排课和人工录入，在线排课是系统根据课程要设置课程的名称、课时、上课的班级、代课老师等信息，除此之外，还可以选填排课时的优选项，例如：上课时间有限上午等系统自动生成课程信息，管理员有权限对课程安排作出添加、删除、修改等判定。
4)教材选择：此功能由教务统一管理，根据每门课程选定相应教材。
5)成绩录入：由教师对相应学生在某一课程中的成绩进行录入或者修改。
3. 权限管理
1)系统使用者有学生、教师、管理员。
2)学生、教师、辅导员可以注册、登录、修改自己的信息，但注册信息需要管理员审核通过。
3)学生只能查看自己的成绩，教师可以修改学生的成绩。
4)教师可以上传考试试题，学生可以做题。
3.2 质量方面
1. 可扩展
由于学生管理的业务需求比较复杂，所以系统要具有一定的可扩展性，可以方便的增加业务需求。
2. 数据高可用
学生和教师数据中的部分内容是自己注册的，且课程和成绩信息比较重要，所以数据不能全部丢失。
4. 约束和限制
控制成本，尽量降低成本。
只在学校内部的学生、老师中使用，对系统的性能要求不高。
考虑到以后功能的变化和增加，系统要具有一定的可扩展性。
由于系统中包含学生和成绩信息，所以数据不能全部丢失。
5. 总体架构
5.1 架构分析
架构复杂度分析如下：
1. 可扩展
由于学生管理的业务需求比较复杂，所以系统要具有一定的可扩展性，可以方便的增加业务需求。可以按照功能将学生管理系统拆分成学生管理、课程管理和权限管理三个子系统，降低内部复杂度，提升系统可扩展性。
2. 高性能
由于学校内部的学生和教书数量最多在万级左右，所以系统对性能要求不高。而且在拆分子系统后，系统本身的性能就有一定程度的提升，所以本方案中暂不对系统性能做特殊设计。
3. 高可用
学生和教师数据中的部分内容是自己注册的，且课程和成绩信息比较重要，所以数据不能全部丢失，需要设计数据的高可用方式。
另外，为了保证系统的计算高可用，同一个子系统应避免出现单点故障，通过集群或多点部署的方式实现计算高可用。
4. 成本
由于是学校内部使用，所以要尽量降低成本。同时，也需要严格控制开发成本。
5. 安全
应严格控制访问权限，防止出现个人信息和成绩被他人访问的问题。
6. 可维护/可测试/可观测
由于系统主要是在学校内部使用，系统会交付给学校内的系统管理员进行维护，所以系统要设计的相对便于维护，并可与学校现有的运维平台进行对接。系统对可测试性、可观测试的要求不高。
5.2 总体架构
5.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 的主从复制来实现数据复制。
5.2.2 物理架构
物理架构图如下：
系统使用两台物理服务器，每台物理服务器虚拟化为三台虚拟服务器，共分为三组：
1. Web 服务器两台，部署 Nginx 和前端页面，使用 KeepAlive 形成热备部署。
2. 应用服务器两台，部署学生子系统、课程子系统、权限子系统，形成一个集群。
3. 数据库服务器两台，部署 MySQL，形成主备库。
6. 详细设计
6.1 核心功能
6.1.1 学生注册
1. 学生使用学号和初始密码登录系统。
2. 提示学生修改初始密码。
3. 学生对初始密码进行修改后，重新登录系统。
4. 学生进入手机号或微信绑定页面。
5. 学生录入手机号或微信号，并进行验证。
6. 系统发送验证信息到绑定的手机号或微信号。
7. 学生在界面录入验证信息，完成验证操作。
教师注册与学生注册的流程类似。
6.1.2 课程录入
1. 管理员登录系统。
2. 录入课程名称、分类、授课讲师等详细信息，并保存。
3. 系统记录课程信息。
6.1.3 课程选择
1. 学生使用学号和密码登录系统。
2. 按照分类查询课程信息。
3. 学生选择要学习的课程，并点击确定。
4. 系统保存课程与学生的对应关系。
6.1.4 成绩录入
1. 教师使用教师 ID 和密码登录系统。
2. 教师查询自己所授课程下所有学生的信息。
3. 系统返回所有选择该课程的学生列表。
4. 教师为每个学生录入成绩，并保存。
5. 系统将成绩记录在学生与课程对应关系中。
6.1.5 成绩查询
1. 教师成绩查询
1) 教师使用教师 ID 和密码登录系统。
2) 教师查询自己所授课程下所有学生的信息。
3) 系统返回所有选择该课程的学生列表以及对应的成绩。
2. 学生成绩查询
1) 学生使用学号和密码登录系统。
2) 查看自己所选的课程。
3) 系统返回学生所选课程及对应的成绩。
6.2 关键设计
6.2.1 可扩展设计
系统拆分为学生子系统、课程子系统、权限子系统三个子系统，可以满足可扩展的要求。
1. 可理解性，系统拆分后，每个子系统的功能更加单一，更便于开发人月的理解。对某个功能进行修改的时候，只需要升级对应的子系统即可。
2. 可复用性，子系统中的功能更加内聚，更易于提取公共组件，形成组件级的复用。
3. 可伸缩性，拆分后可以实现对某个子系统资源的扩展，而不需要对整体的资源进行扩展。
6.2.2 高可用设计
1. Web 服务器两台，部署 Nginx 和前端页面，使用 KeepAlived 形成热备部署，防止 Nginx 出现单点故障。
2. 应用服务器两台，部署学生子系统、课程子系统、权限子系统，形成一个集群，通过 Nginx 将 Http 请求分发到不同的 Server 中，防止应用出现单点故障。
3. 数据库服务器两台，部署 MySQL，通过数据复制形成主备库，防止数据丢失。正常只有主库对外提供读写服务，当主库发生异常时，可以手工切换到备库对外提供服务。
4. 两台物理服务器，每台上都部署有完整的学生管理系统，如果其中一台出现故障，那么另一台经过一定的切换操作（例如：MySQL 的主备切换）可以接管系统。
6.2.3 权限设计
为教师和学生设置不同的数据访问权限，使其登录后，只能查看有权数据，并对有权数据进行修改。
6.3 设计规范
1. 学生管理系统采用 SpringBoot+Vue+ElementUI 开发，采用前后端分离的部署方式。
2. 浏览器与服务端采用 Http 方式实现交互。
3. 服务端基于 SpringBoot 框架开发，部署在 Tomcat 服务器上。使用 Mybatis 作为持久层框架，实现对 MySQL 数据库的访问。
4. MySQL 服务器采用主备部署，同时采用 MySQL 的半同步复制技术实现数据同步。正常只有主库对外提供读写服务，当主库发生异常时，可以手工切换到备库对外提供服务。
7. 质量设计
1. 成本
为降低硬件成本，可以采购 2 台支持虚拟化的服务器，每台虚拟化成 3 台配置不同的虚机，一台虚机部署 Nginx、第二台虚机部署三个子系统的应用、第三台部署 MySQL。这样，两台物理服务器上都具有完整的学生管理系统。
同时，如果学校中已有 Nginx 服务器或其他可以提供负载均衡能力的设备，那么 Nginx 服务器也可与其他系统共用，以便进一步降低硬件成本。
为了降低开发成本，采用目前比较成熟的 SpringBoot+Vue 框架进行开发，提升开发效率，同时全部采用开源基础软件，减少基础软件采购成本。
2. 可维护性
采用成熟且使用较多的开发框架和基础软件，便于维护。
分成三个子系统，每个子系统功能内聚，已于理解。
8. 演进规划
由于学生、教师和课程的数量不会发生太大变化，所以暂时不考虑系统的演进规划。
如果后续出现性能瓶颈，可以先采用添加服务器的方式，将部署应用和数据库服务的虚拟机部署在不同的物理服务器上，以便提升性能。后续还可以将三个应用分别部署在不同的虚拟机，以便进一步提升系统处理能力。
如果上述调整仍不能满足性能需要，可考虑增加服务的数量。
还未添加个人签名 2020.09.11 加入
还未添加个人简介
评论