前言

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

词汇表

Nginx：Nginx (engine x) 是一个高性能的 HTTP 和反向代理 web 服务器，同时也提供了 IMAP/POP3/SMTP 服务。

ECS：云服务器 ECS（Elastic Compute Service）是阿里云提供的性能卓越、稳定可靠、弹性扩展的 IaaS（Infrastructure as a Service）级别云计算服务。

MySQL：MySQL 是一个关系型数据库管理系统。

1. 业务背景

随着学校的规模的不断扩大，学生数量的增加，需要处理的信息也日趋增大，由此带来了几个明显的系统问题：

• 成本问题：目前学生的信息维护都是由教师来手工维护，会导致花费大量的教师资源，从而产生巨大的管理成本。

• 效率问题：目前学生信息管理数据信息量大修改不方便，对一系列数据进行分析时花费时间长。

• 准确度问题：目前学生信息数据全靠人工维护，并且缺乏系统性的管理，容易造成信息不准确。

基于以上背景，我们需要为学校开发一套统计学生各类信息进行日常管理，如查询、修改、增加、删除、以及学生选课、成绩的查询等功能设计的管理系统。

2. 约束和限制

• 使用 PHP 开发

• 数据库使用 MySQL5.7

• 成本不能超过 50w

• 需要支持存储 15 万用户数据

• 必须在 5 个月内完成

3. 总体架构

3.1 架构分析

3.1.1 高性能

对于学生管理系统来说，总体学生人数不多，平时并发量不大；针对一些特殊场景如抢课，同时抢课的任务也不多，故高性能方面无要求。

3.1.2 高可用

学校的教学与其他的管理并不是完全依赖于学生信息管理系统，所以临时宕机几个小时对学校的正常教学影响不大。但是学生信息一般是由人工录入或者学生自己注册的，如果数据丢失比较严重补数据会非常麻烦。所以在高可用方面要求是数据不能全部丢失。

3.1.3 可扩展

由于业务比较复杂，系统不是那么容易理解，所以对于可扩展是有一定要求的。

3.1.4 成本、安全

由于只有一个学校使用，所以服务器的成本不高，主要成本来自研发团队的管理费用。由于系统中不涉及学生，教师等的私密信息，也不涉及资金流转，所以在安全性上的要求也不算高。

3.2 总体架构

• 使用 Nginx 作为网关服务器，将请求路由至业务服务器

• 业务服务器分为：学生子系统，课程子系统，权限子系统，这些系统会将数据存储至数据库

• 数据库使用 MySQL，并且采用主备形式，主服务器对外提供读写服务，备服务器不对外提供服务

• 数据库主服务器宕机的情况下，备服务器对外提供读写服务

4. 详细设计

4.1 核心功能

4.1.1 学生登录流程

4.1.2 学生选课流程

4.2 关键设计

• 数据存储可靠性

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

• 功能开发扩展性

将整个系统拆分为：学生子系统，课程子系统，权限子系统。每个系统由独立团队进行维护，各个团队约定好接口后开始并行开发。业务发生变化时扩展性更好。

4.3 设计规范

• MySQL 使用 Innodb 存储引擎

• 不同子系统中的交互接口使用 REST 规范

• 交互的数据序列化协议使用 JSON

• 使用 laravel 开发

5. 质量设计

• 可测试性设计

http 接口使用 yapi 建立测试用例。

• 可维护性设计

增加一个管理员后台可以维护所有学生信息。

• 可观测性设计

在各个子系统中打印错误日志等关键日志，方便定位回查。

• 安全/成本设计

所有请求使用 JWT 鉴权，防止伪造请求篡改数据。我们对于系统的性能要求不高，所以使用普通的云服务器即可。

6. 演进规划

6.1 学生管理系统一期

完成以上功能

6.2 学生管理系统二期

将以上三个子系统微服务化

6.3 学生管理系统三期

增加异地灾备

6.4 学生管理系统四期

将服务发展为 SAAS 服务，提供给不同学校使用