前言

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

词汇表

• Nginx : 软件负载均衡器

• MySQL：数据库

1. 业务背景

随着社会信息化的进程不断向前推进，学校有将学生信息管理相关的工作从线下迁移到线上的需求。从而提升学生管理的效率。基于此背景提出了学生管理系统的需求。

目前学生信息的管理、课程信息的管理、学生选课、学生分数等都是采用老师手写表格或者 excel 进行维护，新增数据或者修改学生信息都需要老师手动修改，然后再线下点对点的挨个同步给其他部门，修改效率低下，信息同步时间周期长。

基于以上背景，我们需要引入学生管理系统，将学生管理工作信息化，提高学生信息管理的效率。

学生管理系统主要功能：

• 学生管理、教师管理

• 课程管理

• 考试管理

2. 约束和限制

1. 必须在 2021.08.30 之前完成，并交付给学校使用

2. 成本不能超过 50 万元人民币

3. 数据不能全部丢失

4. 学校目前包含学生 5.5 万人，教师 1.5 万人，考虑到将来扩招，要求系统至少能支撑 10 万人

3. 总体架构

3.1 架构分析

3.1.1 高性能

10 万量级对于 MySQL 存储压力不大。

考虑到选课以及课程与学生的笛卡尔积，假设每个学生每学期选择 10 门课，5 万 x10=50 万，4 年 8 个学期共 400 万的关系数据，数据库存储压力不大。

学生管理系统整体用户量小，性能要求不高。只有选课时的热门课程会有高并发问题。

针对热门课程选课场景可以通过消息队列进行削峰。

3.1.2 高可用

要求数据不能丢失，所以必须保证数据可用性，架构中采用 MySQL 主备方案保证数据可用性。

采用 MySQL 异步复制技术搭建主从集群，将从库作为备库使用。

3.1.3 可扩展

考虑到随着国家政策，学校政策，学校教学理念等的不断变化，未来需求会不断变化，所以可扩展性是需要重点考虑的问题。

因此整体架构拆分为多个子系统，采用微服务的方式应对将来的需求变更，包括学生子系统、课程子系统、权限子系统。

未来可以根据具体的需求变化分别扩展各个子系统甚至重构子系统，对其他子系统不会产生影响，各个子系统可以单独扩展。

另外未来还可以根据具体的需求变化拆分更多的子系统，如考试子系统、教师子系统等。

如果未来学校扩招，学生和教师人数增多，可以考虑对各子系统进行横向扩容以应对更大的流量压力。

3.1.4 成本和安全

• 成本预估

• 机器成本

两台数据库服务器需要单独部署，要求存储资源大一些，每个服务一台服务器，Nginx 一台服务器，总共需要 6 台服务器部署整套系统。每台服务器 1 万元，总共需要 6 万元。

• 人力成本

项目经理 1 人，产品经理 1 人，架构师 1 人，前端开发 3 人，后端开发 3 人，测试 1 人，总共 10 人。

整体项目周期预估 2 个月，前期产品设计和架构设计 1 个月，需要项目经理、产品经理和架构师参与，后期开发测试需要 1 个月，需要 3 个前端开发、3 个后端开发、项目经理和测试参与。

所以整体需要 2 人月加 8 人月，总共需要 10 人月。

假设人均工资 1.5 万/月，10 人月共需要 15 万。

• 其他杂项，比如差旅、商务等预估 5 万。

所以总体成本预估 26 万元，低于 50 万。

• 安全

• 防攻击安全问题：所有服务器部署在学校内网，禁止互联网访问，所以只需要防止学校内网攻击。可以使用学校现有的防火墙进行防护。

• 数据安全问题：采用数据库主备方案，防止数据丢失。

3.2 总体架构

总体架构图：

系统主要分为 3 层，负载均衡层、业务层和数据存储层

1. 负责均衡层采用 nginx 服务器，同时也是前端静态页面部署层

2. 业务逻辑层分为 3 个微服务，分别为学生子系统、课程子系统和权限子系统

3. 数据存储层采用 MySQL 主备方案，防止数据丢失

4. 详细设计

4.1 核心功能

[必选，描述核心场景或者流程的实现机制，对应 4R 架构中的 Rule，每个核心场景一个小节]

[样例：

4.1.1 消息发送流程

4.1.2 消息消费流程

]

[技巧：使用系统序列图来描述 Rule，跟项目开发中写设计文档一样的写法]

4.1.1 人员注册

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 设计规范

1. 负载均衡使用 Nginx 搭建，采用 7 层负载均衡轮询算法，针对不同的请求 url 的后缀路由到不同的服务

2. 业务层各子系统采用 SpringBoot 开发，JDK 使用 1.8 版本

3. 各个子系统之间采用 HTTP 协议通讯，接口采用 Restful 风格进行设计

4. 各子系统之间通讯采用 JSON 序列化

5. 数据库使用 MySQL 主从异步同步方案，MySQL 的表使用 Innodb 存储引擎。

6. 数据库中密码需要进行加密处理，不能存储明文

5. 质量设计

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

[样例：

5.1 消息队列管理后台

5.2 成本

]

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

6. 演进规划

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

[样例：

6.1 消息队列一期

6.2 消息队列二期

]

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