写出外包学生管理系统的架构文档

【作业要求】

1.基于模块 1 第 5 课 P15 页的外包学生管理系统备选架构 1（见下 1 页），写出完整的架构设计文档；

2.注意不是备选架构文档，而是最终落地的详细架构设计文档；

3.无需考虑数据库表设计，因为表设计是方案设计阶段做的，不是架构设计阶段做的；

【提示】

1.架构设计文档是完整的文档（Word 或者语雀文档之类的都可以），而不是 PPT；

2.架构文档涵盖的内容请参考模块 3 第 4 课，细化架构设计参考模块 3 第 6 课；

3.外包学生管理系统的业务请参考模块 1 第 5 课的课件；

4.架构文档模板可以参考：架构实战营详细架构设计文档模板

前言

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

词汇表

Nginx: 一个高性能的 HTTP 和反向代理 web 服务器

CDN: Content delivery network, 内容分发网络

Spring Boot: Spring Boot 是由 Pivotal 团队提供的全新框架，其设计目的是用来简化新 Spring 应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置。通过这种方式，Spring Boot 致力于在蓬勃发展的快速应用开发领域(rapid application development)成为领导者。

1. 业务背景

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

处理效率也十分低下。

为提高学生管理的管理水平，优化资源，尽可能降低管理成本成为学生管理的新课题，学生管理系统是从

学生管理现状出发，根据学生管理的新要求进行开发设计的，它需要解决学生信息管理数据信息量大修改

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

因此学生信息管理系统可以通过系统规范化地管理、科学性统计和快速查询、修改、增加、删除等，提高

信息的准确度以及日常管理的工作效率。

本系统主要是应用于学生各类信息的管理，总体任务是实现学生信息关系的系统化、规范化、自动化，其

主要任务是统计学生各类信息进行日常管理，如查询、修改、增加、删除、以及学生选课、成绩的查询等

功能设计的管理系统。

2. 约束和限制

1. 有学校制定的完工日期要求

2. 有学校采购的总成本要求

3. 数据加密需要按照最新出炉的个保法要求对个人敏感信息存储及传输进行加密，但未必需要考虑匿名化需求

4. 数据存储高可用，避免出现丢数据的现象

3. 总体架构

系统边界白盒图

系统架构图

3.1 架构分析

业务复杂度：系统整体业务复杂度较高，因为涉及到多个不同角色（学生，教师，教管）和不同功能（考试，作业，选课）的耦合，拆分成子系统可以减少功能复杂度。

高可用：可用性需求低，上传作业，选课等主要业务功能均可以延期发生，结合成本考虑不增加计算几点和负载均衡的高可用架构设计。数据可用性要求高，需要考虑存储高可用。

高性能：选课系统可能存在高并发场景，需要建立连接池和排队机制保护服务。

高可扩展性：无可预期迭代，简单架构具备高可扩展性。

3.2 总体架构

1. CDN + DNS + Nginx 作为常规静态资源缓存和负载均衡。

2. 基于 Springboot 框架单独部署三个子系统：学生子系统，课程子系统，权限子系统。

3. MySQL 采用主备方案，备机有条件可以部署在异地云机房（由于数据量并不大，并且不做读写分离，不用考虑主从同步延迟问题）。

4. 如果在公有云部署，可以引入文件式存储来存储静态文件，如学生上传的 html 版本的作业和试卷，或扫描的纸质文件。

4. 详细设计

4.1 核心功能

4.1.1 权限管理

通过 JPA + Spring security 在 Springt boot 中增加权限 filter，通过学生管理服务创建账号，通过权限管理服务队权限进行增删改查（后台数据表结构 userId+roleId, roleId+moduleId）

4.1.2 用户管理

账号绑定功能：

手机号验证需要签订短信服务商，配置短信模板，增加验证码组件，避免费用浪费。

微信绑定需要接入公众号，通过授权及调用微信接口获取 openid 绑定到 userId。

自主找回：绑定手机号后可提供验证手机后的密码重设功能（库密码通过 MD5 加密，不可逆）。

4.1.3 文件上传功能

直接通过数据库增删改查实现或者通过公有云文件存储实现更高可用性的功能，对存储的文件需要增加读写权限判断。

4.1.4 课程管理

排课，课程录入，教材选择为简单的增删改查功能。

需要注意的是选课功能，由于热门课程可能存在瞬时高并发的场景，会在 4.2 章详细阐述如何应对高并发的场景。另外选课存在库存管理类似功能，即课程被选择数量存在上线，以及存在更改选课的逻辑，也将在 4.2 章详细阐述。

4.1.5 考试管理

题库维护：通过对接教育局题库或者学校维护的题库实现。

试卷扫描上传：打印机对接 SFTP，后台通过任务调度功能对 SFTP 文件进行导入，注意 endfile 机制确保不会导入在途文件，或者再后台添加手工导入按钮，导入需要做校验。

评分：多级审核，签字。

4.2 关键设计

4.2.1 选课高并发排队：参考传统秒杀机制，引入消息队列组件（如 kafka） 消峰填谷，排队采用异步机制等待服务器反馈。如考虑到组件的复杂度，可以考虑增加令牌桶算法作为限流机制。

4.2.2 选课高并发库存：完整方案-引入 redis 组件作为库存缓存组件，缓解数据库读写压力，Lua 脚本控制库存事务。 如果添加 4.2.1 排队机制，可以不引入组件减少运维复杂度，通过增加数据库行级锁实现库存事务。

4.3 设计规范

1. MySQL 使用 Innodb 存储引擎，使用官方的 binlog 主从同步方案。

2. SpringBoot 实现应用服务，Springt cloud+JPA 实现权限管理。

3. 如果需要考虑高并发选课场景，可以引入 kafka 和 redis 作为消峰填谷的设计方案。

4. 文件存储可以考虑直接使用公有云文件存储，如 AWS 的 S3。

5. 质量设计

5.1 可测试性：子服务都单独暴露接口，可以实现单元测试。

5.2 可维护性：架构相对简洁，如引入高并发组件考虑整体迁入公有云通过使用 PaaS 组件减少运维压力。

5.3 可观测性：所有数据均落库，无额外组件，具备可观测性，如引入高并发组件，则需要借助于公有云的管理和监控组件。

5.4 成本：

必须：Nginx+三台应用服务器+数据库主备服务器

选配：CDN，F5 或者 LVS, S3 或者 NAS，FTP

高并发组件：Redis 集群，kafka 消息队列

6. 演进规划

应对流量突发：引入高并发组件实现消峰填谷，增加容器化实现 HPA 弹性伸缩

应对数据存储压力：数据库针对子服务进行分库

应对文件存储压力：引入分布式文件存储