前言

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

词汇表

Nginx : 软件负载均衡器

MySQL：数据库

1. 业务背景

随着社会信息化的进程不断向前推进，学校有将学生信息管理相关的工作从线下迁移到线上的需求。从而提升学生管理的效率。基于此背景提出了学生管理系统的需求。

目前学生信息的管理、课程信息的管理、学生选课、学生分数等都是采用老师手写表格或者 excel 进行维护，新增数据或者修改学生信息都需要老师手动修改，然后再线下点对点的挨个同步给其他部门，修改效率低下，信息同步时间周期长。

基于以上背景，我们需要引入学生管理系统，将学生管理工作信息化，提高学生信息管理的效率。

学生管理系统主要功能：

• 学生管理、教师管理

• 课程管理

• 考试管理

2. 约束和限制

• 必须在 2021.08.30 之前完成，并交付给学校使用

• 成本不能超过 50 万元人民币

• 数据不能全部丢失

• 学校目前包含学生 5.5 万人，教师 1.5 万人，考虑到将来扩招，要求系统至少能支撑 10 万人

3. 总体架构

3.1 架构分析

3.1.1 高性能

10 万量级对于 MySQL 存储压力不大。

考虑到选课以及课程与学生的笛卡尔积，假设每个学生每学期选择 10 门课，5 万 x10=50 万，4 年 8 个学期共 400 万的关系数据，数据库存储压力不大。

学生管理系统整体用户量小，性能要求不高。只有选课时的热门课程会有高并发问题。

针对热门课程选课场景可以通过消息队列进行削峰。

3.1.2 高可用

要求数据不能丢失，所以必须保证数据可用性，架构中采用 MySQL 主备方案保证数据可用性。

采用 MySQL 异步复制技术搭建主从集群，将从库作为备库使用。

3.1.3 可扩展

考虑到随着国家政策，学校政策，学校教学理念等的不断变化，未来需求会不断变化，所以可扩展性是需要重点考虑的问题。

因此整体架构拆分为多个子系统，采用微服务的方式应对将来的需求变更，包括学生子系统、课程子系统、权限子系统。

未来可以根据具体的需求变化分别扩展各个子系统甚至重构子系统，对其他子系统不会产生影响，各个子系统可以单独扩展。

另外未来还可以根据具体的需求变化拆分更多的子系统，如考试子系统、教师子系统等。

如果未来学校扩招，学生和教师人数增多，可以考虑对各子系统进行横向扩容以应对更大的流量压力。

3.1.4 成本和安全

· 成本预估

·· 机器成本

两台数据库服务器需要单独部署，要求存储资源大一些，每个服务一台服务器，Nginx 一台服务器，总共需要 6 台服务器部署整套系统。每台服务器 1 万元，总共需要 6 万元。

·· 人力成本

项目经理 1 人，产品经理 1 人，架构师 1 人，前端开发 3 人，后端开发 3 人，测试 1 人，总共 10 人。

整体项目周期预估 2 个月，前期产品设计和架构设计 1 个月，需要项目经理、产品经理和架构师参与，后期开发测试需要 1 个月，需要 3 个前端开发、3 个后端开发、项目经理和测试参与。

所以整体需要 2 人月加 8 人月，总共需要 10 人月。

假设人均工资 1.5 万/月，10 人月共需要 15 万。

其他杂项，比如差旅、商务等预估 5 万。

所以总体成本预估 26 万元，低于 50 万。

·安全

·· 防攻击安全问题

所有服务器部署在学校内网，禁止互联网访问，所以只需要防止学校内网攻击。可以使用学校现有的防火墙进行防护。

··数据安全问题

采用数据库主备方案，防止数据丢失。

3.2 总体架构总体架构图：

系统主要分为 3 层，负载均衡层、业务层和数据存储层

1. 负责均衡层采用 nginx 服务器，同时也是前端静态页面部署层

2. 业务逻辑层分为 3 个微服务，分别为学生子系统、课程子系统和权限子系统

3. 数据存储层采用 MySQL 主备方案，防止数据丢失

4. 详细设计

4.1 核心功能

4.1.1 人员注册

1. 超级管理员采用系统内置方案，系统初始化时将管理员的账号密码内置到数据库中，管理员账号只能通过更新数据库的方式进行更新，管理员的密码可以在系统中由管理员自行更新。

2. 管理员可以配置多个。

3. 教师、学生和辅导员通过各自的注册入口进行注册，通过短信接收注册验证码。

4. 教师、学生和辅导员注册成功后需要由管理员审核通过方能登录进系统。

4.1.2 权限控制

1. 学生子系统访问课程子系统时，课程子系统根据用户 id（学生、教师、辅导员）去权限子系统查询该用户的权限，并根据权限返回课程列表、能否查看、编辑课程等信息。

4.1.3 密码保存

1. 密码需要已密文的形式保存在数据库中

2. 对密码加密处理时需要加 salt，防止被拖库后反向破解

4.2 关键设计

• 高可用

• MySQL 主备保证数据高可用，保证数据不会全部丢失

• 采用 MySQL 主从异步复制方案，将主库的数据实时的同步到从库中，并将从库作为备库使用

• 主库宕机时，运维手动将备库升级为主库，待原主库恢复后将原主库作为从库使用

• 可扩展

• 某个子系统访问压力大时，可以对该子系统单独水平扩容，增加该子系统的机器

• 需求变更时，可以单独修改某个子系统已适应新的需求

• 增加需求时，可以根据具体需求对相应的子系统进行再次拆分，拆分成多个子系统适应新需求

4.3 设计规范

1. 负载均衡使用 Nginx 搭建，采用 7 层负载均衡轮询算法，针对不同的请求 url 的后缀路由到不同的服务

2. 业务层各子系统采用 SpringBoot 开发，JDK 使用 1.8 版本

3. 各个子系统之间采用 HTTP 协议通讯，接口采用 Restful 风格进行设计

4. 各子系统之间通讯采用 JSON 序列化

5. 数据库使用 MySQL 主从异步同步方案，MySQL 的表使用 Innodb 存储引擎。

6. 数据库中密码需要进行加密处理，不能存储明文

5. 质量设计

5.1.1 可测试性

无

5.1.2 可维护性

无

5.1.3 可观测性

无

5.1.4 成本

参考 3.1.4

6. 演进规划

6.1 交付版本

1. 完成用户注册、登录功能

2. 完成权限管理功能

3. 完成课程管理功能

4. 完成考试管理功能

6.2 后期支持

1. 根据学校的需求进行升级或定制开发

2. 完善部署自动化方案

3. 完善故障自愈能力