前言

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

修订历史

词汇表

Nginx:反向代理服务

Mysql:关系型数据库管理系统

Gin: Go 语言 web 框架

1. 业务背景

随着学校的规模的不断扩大，学生数量的增加，需要处理的信息也日趋增大。不仅花费大量的教师资源，处理效率也十分低下。此系统由以下几个角度进行了优化。

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

成本问题：从学生管理现状出发，根据学生管理的新要求进行开发设计，优化资源，尽可能降低管理成本，同时满足学生需求。

2. 约束和限制

1. 成本要求：开发成本不能超过 50w，后续运维和部署成本一年不超过 10w。

2. 存储要求：数据库使用 MySql。

3. 容灾要求：意外情况允许 1‰的数据丢失，备机切换响应不超过 0.5 个工作日。

4. 运维要求：一年内宕机时间不超过 2 小时，同时在线人数不超过 500。

5. 质量要求：符合国标 GB-T8566--2001G。

3. 总体架构

系统边界白盒

3.1 架构分析

3.1.1 高性能

(1) 仅有 1000 人使用，且非高频率使用的业务，对性能要求不高。

3.1.2 高可用

(1) 管理系统并非学校业务的核心，系统暂时性中断影响不大。

(2) 对存储高可用有较高的需求，学生信息丢失后补全非常麻烦。

3.1.3 可扩展

(1) 2 年内，在学校扩招规模不大，每年毕业学校与新入学学生数量相差不大的情况下，对扩展性需求不大。

3.1.4 成本、安全

(1) 作为学生管理系统，学校投入成本有限，且可以依赖于学校本身网络系统的限制，采用内网登陆限制、账号限制只能管理员新增等策略，既降低成本，又保证安全性。

3.2 总体架构

1. 采用 Nginx 进行反向代理。

2. 数据库采用 mysql 主备架构; 正常情况下，仅有主数据库服务器对外提供服务；异常情况下，启用备用服务器，并恢复数据。

3. 拆分学生子系统、课程子系统以及权限子系统，降低后端复杂度。

4. 详细设计

4.1 核心功能

4.1.1 权限管理流程

4.1.2 学生选课和课程管理流程

4.2 关键设计

1) 可扩展

采用微服务思想，不同子系统关注于不同任务，利于后续扩展其他功能。

2) 数据可用性

采用 mysql 主备形式应对大部分数据容灾情况，当遇到极端情况导致数据丢失一部分时，由于成本限制，不做特别应对，采用手动录入进行恢复。

3) 成本控制

三个子系统无相互依赖部分，在部署时既可以部署在分别的服务器上，也可以部署在相同单机，具备较高灵活性，具体部署可视成本而定。

4) 高并发

使用协程池技术，降低系统资源消耗，提高系统响应速度，有效提升单机性能。

5) 安全

由权限子系统负责校验用户权限，仅限制校内人士使用。

4.3 设计规范

1) 业务服务使用 Go+Gin 开发

2) Mysql 使用 Innodb 存储引擎。

3) 前端使用 Nginx + React 开发部署。

4) 服务接口遵循 Restful 风格。

5) 使用 Swagger 进行 Api 管理。

6) 使用 Git 进行代码版本控制。

7) 前后端交互采用 Json。

5. 质量设计

5.1 可测试性

主动切换 Mysql 备机，系统能正常运行；Mysql 备机切换到 Mysql 主服务器，系统正常运行

5.2 可维护性

应用服务意外宕机不会对日常教务工作造成阻塞性灾难，对系统恢复正常使用容忍性较高，只需支持通过命令行可进行应用重启即可。

5.3 可观测性

应用服务意外宕机不会对日常教务工作造成阻塞性灾难，对系统恢复正常使用容忍性较高，此处不设计应用监控管理。

5.4 可测试性

所有前后端交互基于 Https。

6. 演进规划

6.1 学生管理系统一期

完成学生子系统、课程子系统、权限子系统业务功能开发.

6.2 学生管理系统二期

进行微服务改造，引入服务治理、服务监控等措施.