还没写好，明天继续写。。。

前言

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

词汇表

Nginx：反向代理服务，代理具体的业务系统

MySQL：业务系统的存储

1. 业务背景

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

为提高学生管理的管理水平，优化资源，尽可能降低管理成本成为学生管理的新课题，学生管理系统是从学生管理现状出发，根据学生管理的新要求进行开发设计的，它需要解决学生信息管理数据信息量大修改不方便，对一系列数据进行分析时花费时间长等问题，帮助学生管理人员有效管理学生信息。

因此学生信息管理系统可以通过系统规范化地管理、科学性统计和快速查询、修改、增加、删除等，提高信息的准确度以及日常管理的工作效率。

本系统主要是应用于学生各类信息的管理，总体任务是实现学生信息关系的系统化、规范化、自动化，其主要任务是统计学生各类信息进行日常管理，如查询、修改、增加、删除、以及学生选课、成绩的查询等功能设计的管理系统。

2. 约束和限制

1. 必须在 2021.08.28 号上线投入使用

2. 能够支持管理 1000 个学生

3. 成本不能超过 5 万

4. 数据不能丢失

5. 用户体验要好，不能出现操作卡顿情况

6. 系统要稳定，即便出问题，也能在 5 分钟内恢复

3. 总体架构

业务系统采用微服务部署，数据库使用主备架构。

流量通过 Nginx 转发到具体业务系统，业务系统之间调用使用 HTTP 方式访问。

各子系统提供功能如下

学生管理子系统

教师：对学生信息的管理

学生：对自己信息的修改，将课堂笔记上传，完成作业提交

课程管理子系统

教师：对自己的课程进行录入管理

学生：查看课程表信息，选择课程

权限管理子系统

学生：注册、登录、修改个人信息；查看自己成绩；做试题

教师：注册、登录、修改个人信息；修改学生成绩；上传考试试题

辅导员：注册、登录、修改个人信息；查看学生信息；设置学生奖励

管理员：审核信息

3.1 架构分析

3.1.1 高可用

对于用户的数据，如果丢失了，会造成用户不能完整正常的业务动作。

比如：学生的作业丢失了，教师就不能批改，还会造成学生作业未提交的问题。

因此对于用户信息，以及用户提交的信息 需要做到数据高可靠。

3.1.2 高并发

学生只有 1000 名，且同时操作的学生不会超过 500（按照一半的流量）。

因此不需要考虑高并发场景。

3.1.3 高性能

用户主要操作场景是查看：学生看课程信息，教师看学生作业。

对于用户的主要操作，不能出现卡顿，使用要友好。

因此对于请求要考虑高性能。

3.1.4 高可扩展

用户在使用的时候，会提供个性需求，需要能快速响应。

因此在编写代码的时候，预留好扩展的接口，面向接口编程。

3.1.5 成本

Nginx 单独服务器，百兆带宽，4 核 CPU，8G 内存，磁盘无要求。

三个子系统单独部署服务器：百兆带宽，4 核 CPU，8G 内存，磁盘无要求

数据库主备共两台服务器：百兆带宽，4 核 CPU，8G 内存，磁盘 1T

因此最终需要六台服务器，24 核 CPU，48G 内存，2T 磁盘

3.1.6 规模

目前只有三个子系统，且都单机部署。

因此不需要考虑规模带来的复杂度问题

3.1.7 安全

学生信息很重要，做好权限控制。

比如：学生 A 不能看学生 B 的成绩；学生未登陆，不能看到任何信息。

因此做好登陆权限控制，以及考虑数据越权的风险。

3.2 总体架构

4. 详细设计

4.1 核心功能

4.2 关键设计

4.3 设计规范

5. 质量设计

6. 演进规划