1.业务背景

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

为提高学生管理的管理水平，优化资源，尽可能降低管理成本，新建学生管理系统，帮助学生管理人员有效管理学生信息，解决学生信息管理数据信息量大修改不方便，对一系列数据进行分析时花费时间长等问题。

2.约束和限制

1.在三个月内交付初版

2.成本不能超过 100 万

3.开发成本和运维成本要较低

3.总体架构

3.1 架构分析

3.1.1 高性能

一个学校大概只有几万人，对于一个系统来说，几万人的性能要求并不高；即使是大家任务的抢课功能，同时有几百上千个人来访问，对系统来说压力也不大

3.1.2 高可用

学生系统出故障短时间无法使用，不会影响整个学校的教学；但是如果学生信息大量丢失，重新补全信息是件比较麻烦的事情，所有在高可用的时候要考虑学生信息丢失的情况。系统没有高可用要求，但是对数据有高可用需求。

3.1.3 可扩展

这个系统比较复杂，需求也比较多，还是要考虑一定的可扩展性。

3.1.4 成本和安全

系统只设计学生的基本信息，不设计敏感信息，也不存在和金钱相关的业务，所以无需过多关注安全性。只有面向单个学校，可以不考虑成本问题。

综合分析，系统业务需求比较复杂，设计要具有扩展性；学生信息不能全部丢失，要保证数据的高可用。

3.2 总体架构

最上层是一个 nginx，负载学生的请求接入，然后将请求反向代理到下面的具体子系统

业务拆分：将整个系统分为三部分，一个学生子系统，一个课程子系统，一个权限子系统。

数据存储：mysql 主备

4.详细设计

4.1 核心功能

4.1.1 权限管理

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

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

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

4. 辅导员可以查看学生的信息，可以设置学生的奖惩信息。

5. 教师可以上传考试试题，学生可以做题。

采用 RBAC 模型进行权限管理

4.1.2 登录管

4.2 关键设计

1.数据存储可靠性

消息存储在 MySQL 中，每个分组有一主一备两台 MySQL 服务器，MySQL 服务器之间复制消息以保证消息存储高可用。如果主备间出现复制延迟，恰好此时 MySQL 主服务器宕机导致数据无法恢复，则部分消息会永久丢失，这种情况不做针对性设计，DBA 需要对主备间的复制延迟进行监控，当复制延迟超过 30 秒的时候需要及时告警并进行处理。

4.3 设计规范

1）使用 Spring Boot + Mybatis 开发

2）MySQL 使用 Innodb 存储引擎

3）统一 Response 设计

4）ErrorCode 要统一

5）前端不可以直接返回堆栈错误信息

5.质量设计

5.1 系统后台管理页面

可以查看操作日志。

管理员权限的移交。

5.2 成本

可以利用学校现有的基础设计进一步控制成本。

6.演进规划

6.1 学生管理系统一期

学生管理、权限管理、考试管理、课程管理

6.2 学生管理二期

学生活动管理、校友会、论坛 bbs