前言

本文是学生管理系统详细架构设计文档，用于指导系统后续开发、测试和维护。主要涵盖了系统架构设计业务需求背景、前提条件、限制因素，以及系统架构分析、详细架构规范和质量设计，并说明架构后期演进规划，以提供架构演进建议方案。

词汇表

Nginx: 高性能反向代理服务器

MySQL: 开源关系型数据库

VUE: 前端开发框架

Spring Security: Spring 安全框架

Spring boot: Spring 开发框架

OAuth2.0: 安全认证协议

access_token: 访问令牌

Keepalived: 类似于 layer3, 4 & 5 交换机制的软件，用于实现服务器高可用

VIP: 虚拟 IP 地址

Linux: 最流行的开源操作系统，具有安全、高性能、多线程服务器级别的操作系统

1. 业务背景

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

处理效率也十分低下。

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

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

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

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

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

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

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

功能设计的管理系统。

2. 约束和限制

该系统是面向全校师生用户，且学生信息管理系统化、规范化、自动化要求迫在眉睫，所以有以下几个方面的约束和限制：

1. 校方系统建设资金有限，所以建设成本不能过高

2. 要求尽快上线，系统开发时间紧迫

3. 要满足服务和存储高可用，数据不可丢失

4. 性能方面只需要满足全校师生即可

5. 数据库 MySQL

6. 质量标准符合 ISO9001-2008

3. 总体架构

3.1 架构分析

从业务复杂度和质量复杂对该校学生管理系统的进行分析，其业务复杂度和质量复杂度都处于适中的水平。主要体现在：

1）总体来讲系统按照功能可清晰的划分为学生管理、课程管理、考试管理和权限管理子模块，各模块间业务关系清晰且耦合度低；

2）各模块没有较复杂且难以理解的业务流程，主要涉及增、删、改、查等方面的数据操作，以及对应的权限控制；

3）其面向客户群体确定且变化不大，决定了其可用性、性能方面要求不会太高，只要能在中短期满足用户访问量即可；

4）在业务和架构方面的安全要求也并未达到金融级别，只需要实现业务用户数据访问权限控制即可；

5）在系统可维护性、可测试性和可观测可综合成本、质量和时间方面进行适度设计，并不用一次到位，可后期迭代演进。

3.1.1 可扩展

根据系统的业务复杂度，各功能模块和业务功能变化频率预测分析，可将该系统进行垂直拆分为三个子系统，分别是学生管理子系统、课程子系统和权限子系统，各子系统独立开发、测试和部署，当然也需要进行必要的业务流程集成测试，每个子系统采用独立的物理服务器运行。

3.1.2 高性能

计算性能方面，由于子系统功能清晰，且用户群体数量固定，且访问量不大，根据峰值计算出的 TPS 和 QPS 来看，各子系统独立进程运行在一台物理服务器上即可满足业务需求，访问入口搭配一台代理服务如 Nginx，作为服务请求路由与分发。

存储性能方面，根据业务特性和业务增长量预测和分析，所有子系统共享存储服务器，采用关系型数据 MySQL 双主架构即可承载性能需求和未来 3-5 年的业务需求。

3.1.3 高可用

校方对于系统中断服务容忍度较高，并不会因为系统中断服务导致学校正常运作，业务不会有直接经济损失或名誉损失，如果系统中断在当天恢复即可，可接受最长 4-8 小时中断时长。

计算高可用方面，所以将各子系统独立部署，避免单一服务故障拖垮其他服务，当子系统服务故障可采用人工方式尽享快速修复。

数据存储高可用方面，采用 MySQL 双主高可用架构，主从之间采用高效的无损半同步模式，技能保障主从数据一致性，又能保障读写性能要求，用 Keepalived 实现 VIP 绑定高可用，当主发生故障 VIP 自动切换到，但主机恢复后需要手动恢复主从架构。

综合来看，该系统建设优先人力成本和时间考虑，然后考虑性能和可用性能，对于技术方面采用团队熟悉的语言开发，并采用团队最熟悉的数据库、反向代理服务器。

3.2 总体架构

1. 采用 Nginx 作为反向代理服务器，对外提供服务，Nginx 根据客户端请求进行后端子系统路由分发，采用 HTTPS 协议对外提供服务，与后端各子系统采用 HTTPS 通信。

2. 三台物理服务器分别部署 Tomcat 独立运行各子系统，提供各模块功能且相互之间互不通信，利用 Nginx 进行各模块业务请求分发，统一数据存储。

3. 数据库采用 MySQL 双主架构，用于存储学生管理系统个子系统业务数据。采用无损半同步模式，保障数据实时同步，并采用 keepalive 作为高可用方案，暴露 VIP 给到子系统服务用 JDBC 协议进行连接，如果主服务器宕机，那么备服务器立即对外提供读写服务，但主服务器恢复后需要手动同步数据和恢复主从架构。各台数据库服务器进行每周全量物理备份和每日凌晨增量备份。

4. 详细设计

4.1 核心功能

4.1.1 认证和授权流程

1. 用户通过学校局域网 Nginx IP 地址请求学生管理子系统，Nginx 通过 URI 将请求分派到学生管理子系统服务器。

2. 学生管理子系统对客户请求资源进行权限认证，如果用户未登录则返回登录页面，当用户提交用户名密码后，系统对客户进行认证，认证通过则创建 access_token，用于后续各个子系统单点 SSO 认证。

3. 数据库存放用户认证信息，包括用户名，密码，创建时间，用户状态，...。

4.1.2 查询课程和选择课程

1. 学生统一登录入口等于到学生管理子系统，并根据权限返回相应页面。

2. 当点击查询课程或选择课程时，Nginx 更具 URI 分派请求到课程管理子系统进行业务处理，课程子系统按照认证流程和方式对客户端请求进行认证和授权。

3. 选课会更改学生对应选课记录，对应的数据将更新保存到数据库。

4.1.3 考试和评分

1. 教师登录系统创建考试，考试信息将写入数据库。只有管理有权限对考试信息进行修改或删除。

2. 教师对学生考试成绩进行评分，系统会从数据库拉取学生平日成绩，并按照比例综合计算最终成绩。平日成绩是根据学生通过学生子系统上传的作业和笔记计算的来。

3. 最终成绩将写入数据库供学生查询或管理员修改。

4.2 关键设计

1. 业务服务可用性

将整个系统拆分为四个子系统，并运行在不同的物理服务器，并通过 Nginx 作为反向代理服务器，根据请求路径分发请求到各子系统，一方面可以保障系统性能，另一方面能保障系统可用性，将不同服务拆分在不同服务器运行，可以避免单点故障。

2. 数据存储可用性

采用 MySQL 双主架构，对业务服务暴露 VIP 进行接入，该架构简单且能主备服务器间数据一致性，以及可靠性，当主发生故障可以无缝切换到备服务器，但需要人工恢复双主模式，不过由于该系统对系统中断容忍度较高，可以接受短时间只有一台服务器提供数据读写，并等等待人工恢复双主。

2. 认证和权限管理

由于各子系统分开独立运行，为降低系统自建的复杂度，采用独立的权限子系统做为统一认证和授权中心，采用业内 OAuth2.0 协议进行各子系统统一认证授权，采用 spring security OAuth2.0 进行开发和各子系统集成。

3. 前后端分离

前端页面和交互逻辑采用 Vue 开发，后端业务逻辑采用 Spring Boot 开发，前后端分离，用 OAuth2.0 access_token 进行后端服务调用认证授权，更具用户角色和权限将相应的功能页面呈现给用户。前后端分离也能方便以后进行扩展复用或迁移上云，以及移动端 Native APP 的实现。

4.3 设计规范

1. 开发框架：Vue + Spring boot + Spring Security OAuth2.0

2. 前后端交互协议：HTTPS

3. 服务与 MySQL 连接协议: JDBC

4. MySQL 采用 Innodb, 主备采用无损半同步模式

5. 服务对外 API 采用 Restful 接口规范：

• HTTP Method

get: 获取资源，/students/{studentId}, /students/{studentId}/courses

put: 创建资源，/exaims, /accounts

post: 修改资源，/exaims/{exaimId}, /students/{studentId}/name

delete: 删除资源， /courses/{courseId}

• HTTP Header

Locale: zh_CN or en_CN

Content-Type: application/json

Authorization: <Bearer Token>

Accept-Encoding: UTF-8

• HTTP Status Code

200: 查询成功

201: 创建或更新资源成功

202: 部分成功

401: 认证或授权失败

400: 客户端输入错误

403: 违反业务逻辑

502: 响应超时

503: 服务不可用

500: 服务端未知异常

• Requst Body

Model Jason Body

• Respose Body

2xx

{

"response": [

{

"id": "616fb98f-46ca-475e-917e-2563e5a8cd19"

},

{

"id": "516fb98f-46ca-475e-917e-2563e5a8cd12"

}

]

}

4xx/5xx

{

"error": {

"code": "Ecs.xxxx",

"message": "xxxxxxxxxxxxxxx"

},

"internalError": [

{

"id": "616fb98f-46ca-475e-917e-2563e5a8cd19",

"error_code": "ECS.XXXX",

"error_message": "xxxxxxxxxxxxxxx"

},

{

"id": "516fb98f-46ca-475e-917e-2563e5a8cd12",

"error_code": "ECS.XXXX",

"error_message": "xxxxxxxxxxxxxxx"

}

]

}

5. 质量设计

5.1 采用 TDD 和 BDD 作为开发规范，根据业务流程驱动开发、单元测试驱动开发，保障代码质量和业务准确性，通过 in memory mock 数据库进行单元测试。

5.2 采用 zabbix 对 MySQL 服务器进行监控。

5.3 采用开源 prometheus 进行 nginx 和 spring boot 服务进行实时监控。

5.4 采用 Jenkins 进行打包和部署。

6. 演进规划

6.1 系统一期

优先满足核心最少功能，采用 Scrum 敏捷开发实践，以及持续集成 Jenkins 管道，快速发布到测试环境，以最快获得客户反馈，并在每个 Sprint 发布一个新版本上线，以最快获得学生、老师和管理员实际使用反馈。以此避免不必要的功能构建，或检验架构和系统功能实践是否合理，并尽早进行改进，以降低不必要的人力、物力和时间浪费。

最少核心功能（MVP）

1）注册和登录

2）账号分配

3）排课和选课

4）作业上传和修改

5）考试安排和批卷

6）成绩评分

四个子系统采用单台物理机部署，数据库共享，主备架构。

前后端分离，便于将来采用移动端 APP 接入服务。

监控系统采用开源监控，开箱即用，不需要进行额外开发定制。

内网 IP 访问，不提供互联网访问方式。

6.2 系统二期

随着用户群体人数增涨，业务功能增加，要求节约成本的同时满足更加智能化和更好的服务体验，需要进行微服务拆分，和服务上云，同时需要考虑服务弹性扩缩容。

另外前端增加 APP 互联网接入，需要进行 APP 功能开发和域名解析服务。

增加试卷扫描上传下载功能，需要接入扫描设备，并且采用云厂商对象存储服务器。

增加系统安全防护措施，防 DDOS，防域名劫持，防 SQL 注入、XSS、CSRF 攻击等等。