前言

本文作为外包学生管理系统的架构设计指导说明

修订历史

词汇表

1. 业务背景

随着学校规模的不断扩大，学生人数，课程数量都快速增加。教务人员和老师需要处理的信息量日趋庞大，需要耗费大量的人力，而且效率和准确度都不高。因此为了提高学校信息化管理水平，降低管理成本，需要提供一套对学生学籍、课程、作业、考试一体化的在线管理平台。

该平台的数据需要能够规范化/科学化的进行整理和分析，能够快速查询、修改和添加。同时由于学校的 IT 部门人员有限，管理平台需要提供方便易用的运维管理能力。

2. 约束和限制

• 开发成本不超过 100 万

• 时间需要在 3 个月完成开发交付

• 当前在校学生人数 8000

• 数据和机器需要在学校机房本地化部署

3. 总体架构

整个学生管理系统主要的用户分为学生、老师和教务管理人员，他们通过浏览器方式对系统进行访问。

3.1 架构分析

3.1.1 可用性

学生管理系统学籍、成绩等信息是学校和学生的重要数据资产，数据不可以轻易丢失和错乱。但是一般学校内的学籍和成绩等关键数据都会有纸质档案留底，出现少量由于系统中断引起的数据丢失，可以通过纸质档案信息进行恢复。因此在数据层面利用主备节点防止硬件故障导致的数据完全丢失即可达到数据可用性要求。

系统层面的可用性，由于只是单个学校在使用本系统，并非学校的运作的关键流程系统，因此本系统可以容忍的故障时间相对是较长的。并且学校要求数据和机器均部署在学校内部，也主要是通过校园网内部进行访问，所以将系统部署在学校内部机房，使用主备机器进行备用子系统即可满足要求。

3.1.2 性能

全校师生在 1 万人以内，不会出现使用人数突增的情况。系统涉及的业务也并非处于学校教学的关键流程中，日常对系统的读写请求量预估平均在 100 QPS 以内。可以预估到高峰期应该出现在学期开始时进行集中选课场景中，短时间内的请求量可能会到 5K QPS 以上。所以系统对于性能的指标要求也一般。

3.1.3 扩展性

学生管理系统需要具备一定的可扩展性以适应学校新增教学类型的需要。但是由于学校教学的特点，其业务场景变化和新增的频率一般都不高。所以在扩展性上的要求也不高。

3.2 总体架构

基于系统在可用性/性能/扩展性的复杂度分析。学生管理系统本身在高性能，高可用，高扩展上的指标要求都比较一般。

因此整个系统的架构设计框架是这样的：

• 系统分为 学生子系统/课程子系统/权限子系统 三个子系统

• 子系统部署在 2 台服务器上，互为冗余，每个服务器上均部署完整的三个子系统

• 利用 Nginx 做流量转发和负载均衡

• 子系统之间使用 http 协议以 rest api 方式提供接口互相访问

• 权限子系统提供 token 的生成和校验接口来验证请求是否有授权

• 存储层面的数据库采用 MySql 主备设计，各个子系统在数据库内是独立的库，互不干涉

4，详细设计

4.1 核心功能

4.1.1 登录

4.1.2 选课

4.1.3 查询成绩信息

4.2 关键设计