学生管理系统详细架构

Posted 2023-04-02 ZHAOHUODIAN888

修订历史

词汇表

• Java：一种主流的开发语言

• SpringBoot：Java 体系快速开发的脚手架

• Tomcat：一款高性能 Web 服务器

• mysql: 一款开源高性能关系型数据库

• BS 架构：浏览器服务器架构

• nginx：一款高性能反向代理软件

• MyBatis：一款 Java 体系的 ORM 框架

• Thymeleaf：一款 Java 体系的模板渲染引擎

1. 业务背景

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

处理效率也十分低下。

为提高学生管理的管理水平，优化资源，尽可能降低管理成本成为学生管理的新课题，学生管理系统是从

学生管理现状出发，根据学生管理的新要求进行开发设计的，它需要解决学生信息管理数据信息量大修改

不方便，对一系列数据进行分析时花费时间长等问题，帮助学生管理人员有效管理学生信息。

因此学生信息管理系统可以通过系统规范化地管理、科学性统计和快速查询、修改、增加、删除等，提高

信息的准确度以及日常管理的工作效率。

本系统主要是应用于学生各类信息的管理，总体任务是实现学生信息关系的系统化、规范化、自动化，其

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

功能设计的管理系统。

2. 约束和限制

系统有以下约束和限制

1. 系统要求在 2022.08.30 完成上线

2. 开发成本不超过 50 万，每年运维支出不超过 5 万

3. 支持 3 万在校学生选课、查看成绩，3 千教职工在线录入成绩，课程

4. 系统可用性要求 99.9%

5. 保障数据的安全性和可靠性

3. 总体架构

本章描述系统的总体架构，分系统边界设计、架构分析、总体架构三个方面来说明。

3.1 系统边界设计

3.1.1 系统黑盒边界设计

【客户端 Role 设计】

1. 系统采用 B/S 架构；

2. 使用 Thymeleaf 模板引擎；

【服务器端 Role 设计】

1. 服务器端采用 Java 作为编程语言；

2. 2 使用 Springboot+SpringMVC 来构建 Web 服务；

3. Tomcat 作为 Web 容器；

4. 对外提供 HTTP 协议的 JSON 格式的数据接口

【客户端和服务器端的 Relation 设计】

1. 服务端提供 HTTP 协议、JSON 格式的接口与客户端进行交互

【数据库的 Role 和 Relation 设计】

1. 采用 MySQL 作为数据库进行数据存储

2. 使用 InnoDB 存储引擎

3. 采用 MySQL 主从同步

【服务器端和外部系统的 Relation 设计】

1. 服务器端和学生学籍管理系统、教职工管理系统有交互，同步学生及教师信息到本系统

2. 学生管理系统作为客户端，遵循学籍管理系统、教职工管理系统的接口规范，使用 HTTP 协议进行通信，获取数据

3.1.2 系统白盒边界设计

学生子系统 Role 设计】

1. 使用 Java、Springboot、Tomcat 去构建学生子系统；

2. 包含学生管理的业务功能。

【课程子系统 Role 设计】

1. 使用 Java、Springboot、Tomcat 去构建课程子系统；

2. 包含课程管理、考试管理两大块业务模块。

【权限子系统 Role 设计】

1. 使用 Java、Springboot、Tomcat 去构建课程子系统；

2. 包含教师管理、权限管理两大业务模块

【子系统 Relation 设计】

1. 学生子系统、课程子系统均依赖权限子系统进行认证、授权

2. 课程子系统中的课程和考试与学生和教师相关，需要依赖学生子系统、权限子系统获取学生和教师信息

3. 学生子系统中的学生和教师有关联，学生子系统会依赖权限子系统中的教师信息

4. 学生子系统、权限子系统、课程子系统三者之间的通信采用 HTTP 协议，JSON 数据格式，若有多实例需求则通过 Nginx 进行负载均衡

3.2 架构分析

3.1.1 高可用

学生数据、课程数据、选课数据都非常重要，如果丢失会带来严重影响，系统发生故障后要能够快速的恢复，所以对于本系统来说必须保障高可用。

3.1.2 高性能

系统在日常大部分时间都处于较为空闲状态，但是在选课期间和成绩公布期间会有较大的访问压力，为了保障选课、查看成绩等业务顺利进行，系统需要满足业务高峰时期的性能要求，但是因为用户数量有限，整体性能要求并不算高。

3.1.3 可扩展

选课业务流程相对固定，但是会随着系统的迭代变的越来越丰富，故需要满足较高的可扩展性。

3.1.4 可维护性

系统需要能够进行一些常规维护如账号分配、组织机构管理，所以需要具备基础的维护后台即可。

3.1.5 安全性

学生的信息属于学校及个人的私密数据，如果发生泄漏将带来严重后果，本系统要能够防止常规的攻击手段，数据库的保密性要求较高。

3.1.6 成本

学校非盈利机构，且系统的规模不大，故要求每年的部署实施成本不能过高。

综合来看，系统首要需要满足高可用、安全性、可扩展，其次满足高性能、成本、可维护性的要求。

3.3 总体架构

1）采用 B/S 架构，客户端使用浏览器；

2）前置采用 Nginx 作为入口网关，部署两个实例来达到高可用要求，故域名解析至两台 Nginx 服务器；

3）为了防御一般性攻击 Nginx 前配置公有云 WAF，来保障安全性；

4）服务端拆分为三个子系统独立部署：学生子系统、课程子系统、权限子系统；

5）三个子系统之间使用 HTTP 协议，JSON 数据格式进行通信交互；

6）为了满足计算层高可用，三个子系统均采用双实例部署，之间的通信所需的负责均衡通过 Nginx 来实现，Nginx 需要实现健康检查以达到故障转移目标

7）数据存储层采用 MySQL，Innodb 作为存储引擎，部署一主一备，主备复制，以达到高可用高可靠目标

4. 详细设计

本章将描述系统的核心场景、关键设计和设计规范

4.1 核心功能

4.1.1 选课流程

1. 学生访问系统，被权限子系统拦截进行认证；

2. 认证通过后权限子系统通过学生子系统获取学生信息

3. 权限子系统下发 token 之客户端

4. 学生打卡选课列表，从课程子系统获取课程信息

5. 学生选定课程，向课程子系统发起选课申请

6. 课程子系统校验符合选课要求后返回选课成功

4.1.2 试卷区域分割流程

1. 老师访问系统，权限子系统进行拦截要求认证；

2. 认证通过后会返回 token 给客户端

3. 老师选择创建考试，向课程子系统发起创建请求

4. 课程子系统内部逻辑自动生成考卷

5. 老师根据考卷标记分割点，发送请求至课程子系统

6. 课程子系统进行标记处理后返回

7. 之后进行考试，考试完老师将考卷的扫描件上传，考卷数据发送至课程子系统

8. 课程子系统进行识别处理

9. 老师对考卷进行评分，发送评分数据至课程子系统，课程子系统完成评分记录

4.2 关键设计

1） 数据存储可靠性

采用 MySQL 一主一备的设计来保障数据可靠。MySQL 服务器之间复制消息以保证消息存储高可用。

如果主备间出现复制延迟，恰好此时 MySQL 主服务器宕机导致数据无法恢复，则部分消息会永久丢失，这种情况不做针对性设计，DBA 需要对主备间的复制延迟进行监控，当复制延迟超过 30 秒的时候需要及时告警并进行处理。

2）服务可用性

为了保障服务可用性达到 99.9%，计算层需要采用多实例设计，每个子系统部署两个实例。引入多实例设计后必然需要负载均衡，可以使用 nginx 服务器进行子系统之间调用的负载均衡，同时配置一定的健康检查机制来实现故障转移。

3）服务的可扩展性

将系统拆分为权限子系统、课程子系统、学生子系统，其中权限子系统包含权限管理和教师管理；课程子系统包含课程管理和考试管理；学生子系统包含学生管理。

拆分后每个子系统内部的业务相对内聚，后续可以进行单独迭代升级，从而保证了一定的可扩展性。

4）安全性

• 系统部署在云服务厂商的虚拟网络中，服务器和 MySQL 均在内部虚拟网络，外网无法访问；

• Nginx 前置增加 WAF 作为入口流量防护，防止常规攻击及小规模 DDOS 攻击；

• 后端大部分服务都需要登录可访问，同时部分页面是授权可访问；

4.3 设计规范

整个系统必须满足以下设计规范

1）使用 SpringBoot 来构建应用，SpringMVC 来构建 Web 层；

2）使用 MyBatis 作为 ORM 框架；

3）数据库存储采用 MySQL 5.7，innodb 存储引擎，一主一备异步复制模式；

4）使用 SpringBoot 内嵌的 Tomcat 作为 Web 服务器；

5）前后端及子系统之间采用 HTTP 接口进行通讯

6）使用 Java 1.8

5. 质量设计

5.1 可测试性

系统分为三个子系统，对外采用 HTTP 接口，方便按照模块进行单元测试、接口测试。

5.2 可维护性

系统有一个简易管理模块，能够进行基础的维护工作，如组织架构调整、人员导入。

5.3 可观测性

• 系统部署在云厂商的环境中，云厂商提供虚拟机、服务器的常规 Metric 监控；

• 系统日志输出到控制台及文件，方便查看；

• 本系统暂不需要支持 tracing。

5.4 安全

• 系统部署在云厂商的虚拟网络中，外部网络无法直接访问系统及数据库，保障了数据及应用的安全；

• 流量入口使用 WAF 作为防火墙，能够过滤大部分外部攻击；

• 系统内部采用认证、授权机制，保障了内部人员不越权篡改系统。

5.5 成本

• 系统采用了分布式架构，但是没有采用微服务架构，所以没有微服务庞大的治理组件，降低复杂度的同时也降低了部署成本；

• 目前在计算层面和存储层面，仅使用了最基础的多实例保障机制，一方面满足了一定高可用需求，另外一方面也降低了运维成本。

6. 演进规划

学生管理目前计划分三个迭代周期：

6.1 学生管理系统一期（本期）

完成学生管理系统初始版本的建设，使系统有学生管理、教师管理、课程管理、考试管理、权限管理等基础功能，满足学校选课、考试等基础业务。

6.2 学生管理系统二期

在一期的基础上进行功能迭代，支持多租户特性，以满足分校，附属学校的使用需求；

为了满足更高的可扩展、可用性、高性能要求，将学生管理系统进行为微服务化，课程子系统、权限子系统、学生子系统成为真正的微笑服务，引入微服务治理体系;

6.3 学生管理系统三期

引入容器化技术，来实现降低运行成本的目标；

 

 

 

 

 

 

学生信息管理系统架构设计

近期学习架构设计，首先从最基本的学生信息管理系统进行分析。

---

目的：学生信息管理系统架构设计

思考第一步：识别系统复杂度

??架构设计的真正目的是为了解决软件复杂度带来的问题，故应首先识别本系统复杂度在何处，后文分析完整个系统见分晓。

思考第二步：基本功能

• 登录
• 注册
• 信息查询
• 成绩管理
• 课程管理

思考第三步：性能

??一般学校学生约1~5万人，学生信息管理系统访问频率不高，平均每天单个学生的访问次数不到1次，因此性能这部分要求并不复杂，存储使用常规的MySQL数据库既能胜任，缓存可以不用，Web服务器使用Nginx绰绰有余。

思考第四步：可扩展性

??学生信息管理系统功能比较稳定，可扩展空间并不大，因此可扩展性也不复杂。

思考第五步：高可用

??学生信息管理系统即使宕机2小时，对学生管理工作影响并不大，因此可以不用做负载均衡，更不用考虑异地多活这类复杂的方案。但是，如果学生的数据全部丢失，修复是非常麻烦的，只能靠人工逐条修复，这个很难接受，因此需要考虑存储高可靠，这里就有点复杂了。我们需要考虑多种异常情况：机器故障、机房故障等。针对机器故障，我们需要设计MySQL的同机房主备方案；针对机房故障，我们需要设计MySQL的跨机房同步方案。

思考第六步：成本

??由于系统很简单，基本上几台服务器就能搞定，对于一所大学来说完全不是问题，故无需关注太多。

结论

??至此，可以看出本系统设计方案的主要复杂性体现在存储可靠性上，需要保证异常的时候，不要丢失所有数据即可（丢失几个或几十个学生的信息问题不大）。对应的架构如下：
?