前言

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

词汇表

Reactor: 网络编程模式

Netty: 开源的网络编程框架

1. 业务背景

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

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

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

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

2. 约束和限制

1.要求可以通过公网域名访问；

2.能够支撑管理 1000 个学生；

3.成本不能超过 10 万。

3. 总体架构

[必选，描述经过备选架构决策后定下来的架构方案，这一章主要是描述架构的 3R：Rank、Role、Relation]

[技巧：1. 系统边界白盒图描述系统内的角色与外界的交互(Rank + Role + 外部 Relation)；2. 系统架构图来描述内部的 Role + 内部 Relation]

[注意：不建议一张图同时描述系统架构的 3R 以及与外界的交互，因为图太复杂，画系统边界白盒图的时候，系统内部的 Relation 可以不画]

系统边界白盒图如下：

本系统设置角色有 4 类，分别是学生、教师、辅导员和管理员。共分三个子系统，分别是学生管理子系统、课程管理子系统和权限管理子系统。其中学生管理子系统提供管理学生信息，选修课程的笔记、作业上传，课件的下载等功能；课程管理子系统提供课程录入、课程教材选择、排课等功能；权限管理子系统提供四类角色用户权限校验功能，支持学生管理和课程管理系统校验工作。

3.1 架构分析

3.1.1 可扩展

业务需求比较复杂，学校的学生每年都有新生入校和毕业班同学离开，学生数据是不停的变换的；同样的，课程信息也是变化的，比如有课程老师的变化，课程要求，课程内容的更新，学生上传作业和下载课件等等；意味着业务需求会经常变化。所以系统运行过程中会经常有需求变更。所以，可扩展性是架构设计的重要质量属性。

3.1.2 数据高可用

学生管理系统是面向学校内部学生、老师、辅导员和教导处使用的，用户群稳定。该系统是学校日常教学辅助系统，不需要实时在线的要求。换句话说，应用短时间内不可用可以接受，但是学生选课记录、提交的作业、课程的设置信息是学校的重要资产，需要做好备份工作，所以数据高可用是架构设计的另一个重要质量属性，数据不能全部丢失。

3.1.3 性能

本系统用户主要是内部团队使用，按照 1000 学生规模计算，tps 最多不会超过 1000tps，可通过使用负载均衡技术将业务压力分流到不同的业务服务器即可。

3.2 总体架构

本系统通过 Nginx 对外提供服务，Nginx 提供负载均衡和路由功能，支持根据不同 url 请求路由到不同的子系统处理。三个子系统业务彼此独立，共用 MySQL 数据库服务。系统架构图如下：

1）采用应用分散集群的架构，集群中的应用服务器分 3 个，分别是学生子系统、课程子系统，权限子系统，三个子系统通过 Nginx 做调度和负载均衡。

2）存储包括一台主 MySQL 和一台备 MySQL，采用离线备份的方式进行主备数据复制。

3）正常情况下，主数据库对外提供数据写入和数据读取服务，备数据器不对外提供服务；主数据库数据丢失的情况下，利用备数据库数据恢复主数据库数据，重新提供服务。

5）前端采取路由的策略根据 URL 写入写入和读取服务器服务。

4. 详细设计

[必选，描述核心场景或者流程的实现机制]

本章主要描述学生管理系统的核心功能、关键设计和设计规范。

4.1 核心功能

本节主要说明录入课程流程和选课流程为例，讲解学生管理系统的核心流程。

4.1.1 录入课程流程

录入课程流程如下：

1. 管理员登录成功，打开课程管理菜单，点击新增课程，填写课程信息，提交后，触发请求到课程管理子系统；

2. 课程管理子系统触发请求到权限管理子系统，判断操作员是否有权限录入课程；

3. 权限管理子系统收到请求后，到数据库 DB 查询操作员权限，判断权限清单是否包含“课程录入”；如果没有，返回“权限校验失败”，转步骤 4；如果有，返回“权限校验通过”提示。

4. 课程管理子系统收到失败消息后，页面提示“权限不足”；

5. 课程管理子系统收到权限校验通过响应后，校验课程录入信息满足要求。

6. 课程管理子系统触发写入课程信息到数据库 DB

7. 课程管理子系统收到“写入成功”响应。

8. 课程管理子系统收到成功响应消息后，页面提示“操作成功”。

注：管理员教材选择、排课等流程类似。

4.1.2 选课流程

选课流程如下：

4.2 关键设计

[必选，描述系统的一些关键设计点是如何实现和取舍的]

[样例（如果你有兴趣，可以对比一下 kafka 的文档：Kafka design）：

1）消息发送可靠性

业务服务器中嵌入消息队列系统提供的 SDK，SDK 支持轮询发送消息，当某个分组的主服务器无法发送消息时，SDK 挑选下一个分组主服务器重发消息，依次尝试所有主服务器直到发送成功；如果全部主服务器都无法发送，SDK 可以缓存消息，也可以直接丢弃消息，具体策略可以在启动 SDK 的时候通过配置指定。

如果 SDK 缓存了一些消息未发送，此时恰好业务服务器又重启，则所有缓存的消息将永久丢失，这种情况 SDK 不做处理，业务方需要针对某些非常关键的消息自己实现永久存储的功能。

2）消息存储可靠性

消息存储在 MySQL 中，每个分组有一主一备两台 MySQL 服务器，MySQL 服务器之间复制消息以保证消息存储高可用。如果主备间出现复制延迟，恰好此时 MySQL 主服务器宕机导致数据无法恢复，则部分消息会永久丢失，这种情况不做针对性设计，DBA 需要对主备间的复制延迟进行监控，当复制延迟超过 30 秒的时候需要及时告警并进行处理。

3）消息如何存储

每个消息队列对应一个 MySQL 表，消息队列名就是表名，表结构设计为……(此处请自行补充）

]

[技巧：常见的关键设计点包括高性能、高可用、可扩展、安全等]

4.3 设计规范

[必选，描述 Role 和 Relation 相关的开发框架、连接协议、数据包格式等]

[样例：

1）消息队列服务器使用 Spring Boot + Netty 开发

2）MySQL 使用 Innodb 存储引擎

3）TCP 包的结构设计……（此处省略，请自行补充）

]

[技巧：如果某个规范涉及内容比较多，请独立章节描述，例如数据包格式定义]

4.3.1 应用服务设计

1）采用 B/S 架构，通过 Nginx 统一提供对外服务

2）浏览器和服务器采用 TCP 连接，采用 JSON 传递数据

3）服务器基于 Spring Boot +Netty 开发，采用 Reactor 网络模型

4）应用服务访问基于 Nginx 进行负载均衡

5）分成学生子系统，课程子系统和权限子系统三个应用服务

4.3.2 存储设计

1）采用 MySQL 主备同步+每日备份

2）MySQL 使用 Innodb 存储引擎

3）分成学生数据库、课程数据库和权限数据库三个实例，对应三个应用服务

5. 质量设计

[必选，描述和质量相关的设计，包括：可测试性、可维护性、可观测性、成本等设计]

[样例：

5.1 消息队列管理后台

5.2 成本

]

[技巧：如果某个维度不涉及，也请在文档中说明，避免评审的时候被认为考虑不周全]

5.1 可测试性

不涉及

5.2 可维护性

通过 spring boot 管理台维护系统运行情况，可查看并发用户数，响应延迟。

5.3 成本

包括硬件成本和人力成本，硬件通过购置三套应用服务器搭建三套子系统，另外两套数据库服务器搭建 Mysql 主备，用于数据备份恢复。在人力成本上，考虑团队采用熟悉的技术，使用 java 和 spring boot 来开发系统，方便业务快速开发和问题定位，学习成本较低。

5.4 可靠性

应用服务宕机情况下，通过服务重启，数据库恢复来恢复业务，中断时间不超过 4 小时

5.5 可观测性

系统操作有日志记录，通过日志管理可查询。日志保留时间 3 年。

5.6 安全

采用 HTTPS 协议保证传输数据安全

6. 演进规划

[必选，可以是演进规划，也可以是项目计划，需要描述每个里程碑或者版本具体要实现的能力]

[样例：

6.1 消息队列一期

6.2 消息队列二期

]

[技巧：开发阶段快速迭代，小步快跑，但要基本完善后才能正式推出给其他人用]