前言

本文是一个外包学生管理系统架构的最终落地的详细架构设计文档，不是备选架构文档。

词汇表

1. 业务背景

传统的手工纸笔统计和用 Excel 等工具统计和修改学生信息和课程信息等效率低下，不能批量处理，更新消息也不能及时传递。为了优化教师资源，一个学生管理系统成为了利器。学生管理系统大大提高了对学生，课程和教师信息的增删改查的效率。

2. 约束和限制

学校用的系统希望尽可能的控制成本，在保证功能的前提下。

监管方希望基本的数据安全要有。

       尽量不丢失，不泄露。即使发生问题，尽量缩小漏洞。

用 MySQL 做主备，Nginx 做负载均衡（学校 IT 熟悉）

3. 总体架构

3.1 架构分析

高性能

顶多有 5000 人同时选课，而且可能控制同时访问的人数，所以不需要高性能。

高可用

要保证可用性，但是一旦宕机也不会对学校造成经济或声誉损失，所以也不需要高可用。

可扩展

可扩展性要保留，随着时代的进步，需求会不断迭代。

低成本

对于学校这样的非盈利组织，控制系统搭建成本和维护成本很重要。保证可用性的基础上，要尽可能低成本。

安全性

基本的信息安全要保证。数据最好不能大量丢失（也分数据；课程信息丢了可以补，毕业生的学籍丢了就麻烦）

3.2 总体架构

学生子系统 合并 课程子系统

Module/Role/模块：专业，成绩，课程，其他

专业 module

• 专业

• 必修课

• 所在年级

• 已修课程

成绩 module

• 学分

• 成绩（作业，考试，考勤）

课程 module

• 显示课程（分学期）

• 每学期的课程由不同老师教授，在不同的教室。

• 选课

• 考试

• 作业

• 考勤

其他 module

• 班级信息

• 评优

• 达到毕业要求

• 接收通知

• 成绩

• 活动【招聘，由校方举办的活动 】

• 转专业的批准

• 选课成功通知

• 学生社团活动

权限子系统

Role/module: 消息，档案，权限

消息 module

• 生成各种消息

档案 module

• 增删改查各种档案

权限 module

• 消息的流动方向（消息权限）

• 谁可以和谁发

• 谁可以看谁发的

• 按身份给不同档案权限（档案权限）

• 选课权限

针对一下人员有不同的权限管理：

• 学生

• 辅导员

• 教师

• 德育

• 校长

教师/教务子系统

Role/module: 教师，辅导员，德育，党支部，教务，校长

教师 module

• 管理课程进度（课程）

• 安排作业（作业）

• 批改作业

• 分析作业成绩，考试成绩（分析）

• 获取科研经费（科研）

• 教师职称（讲师，教授）（职称）

辅导员 module

• 学生评优

• 学生专业完成进度（专业进度）

• 学校活动安排 （学校活动）

德育 module

• 记过

• 表扬

党支部 module

• 党组织活动

教务 module

• 分析老师的绩效（考核）

校长 module

• 统筹全局

4. 详细设计

4.1 核心功能

由于学生群体规模不大，一个单体项目足以支持正常使用，代码的调用只需要调接口就行。

登陆

同时登陆的人不多，对性能要求不高。但是登陆涉及到身份认证，要保证如果请求失败了，不能让用户登陆。

但是有些场景，比如考试，或选课时，有大量人在登陆，所以会有峰值。根据学生人数可以计算大致峰值。

登陆时，用户输入的信息比较敏感，用 POST 请求更安全，对数据格式没有特定要求，可以用 JSON，更简单轻便。

考试

所有参加考试的人同一时间请求。可以考虑用消息队列，把请求排队。

数据格式采用 XML，因为老师要阅卷，需要阅读，而且 XML 支持更丰富的数据格式。

4.2 关键设计

1.        因为课程跟其他子系统交互不多，所以合并学生和课程子系统。

2.        因为社交网络可以支持日常聊天，所以这个系统只需要支持发送正式通知。另外增删改查档案也需要权限。档案，通知和权限的代码量不太大，可以放一起。

3.        由于考试，作业和考勤都跟课程挂钩，所以都归到了课程下。

4.3 设计规范

“核心功能”已描述。

5. 质量设计

可观测性，可维护性：基本的日志输出要有，但是这系统不是电商或是知名互联网平台，容错率可以高一些。

可测试性：在开发过程中需要测试功能。

安全：基本是数据安全要保证。

6. 演进规划

一次交互后，5~10 年内不会更新系统。