作业要求

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

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

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

前言

本文对学生管理系统的系统架构进行总体描述，为后续研发人员开发系统、测试人员测试系统、实施人员部署系统等工作提供依据和指导。

词汇表

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

MySQL : 常用流行的开源关系型数据库之一

MyBatis : 较为流行数据持久层框架

SpringBoot : 约定大于配置的 spring 新生代软件框架，便于快速开发。

SpringCloud：基于 springboot 的较为成熟的开源微服务解决方案框架

1. 业务背景

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

处理效率也十分低下。

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

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

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

2. 约束和限制

• 学校总人数在 3000 人左右，最大同时在线人数预估 300 人

• 数据库采用 MySQL

• 项目上线必须在 3 个月内完成，最晚不超过 2022 年 3 月 31 日，如果提前上线有奖励

• 项目成本不超过 100W

• 学生端和教师端使用便捷，如果出现使用难度投诉，会扣项目经费

• 学校提供机房进行统一的部署

3. 总体架构

3.1 架构分析

3.1.1 高性能

优先采用任务分解方案，将业务拆分成不同的业务子系统实现，不同业务子系统部署到不同的业务服务器上，通过 Nginx 来进行反向代理。由于总的学生人数只有 3000 人，并且最大同时在线人数为 300 人。

按以上分析得出通过 Nginx 负载均衡能力可以满足高性能要求。

3.1.2 高可用

根据业务背景分析，此方案设计为学校内部系统，所以在短时间出现宕机、服务中断现象也不会造成较大的影响。

数据丢失影响面非常大，数据的备份和恢复是非常重要的，因而考虑系统的高可用是必要条件，所以采用 MySQL 主备架构设计方案。

3.1.3 可扩展

此系统的架构复杂度并不高，系统需求变化相对稳定，所以可扩展性可以暂不考虑，经过分析 3-5 内年，应该不会对系统的架构进行升级迭代，后面做好功能需求的开发迭代就行。

通过以上分析，得出学生管理系统架构分析结论，高可用是必要条件。

3.2 总体架构

1. 此系统分为：学生子系统、课程子系统、权限子系统，通过 Nginx 进行路由和转发；

2. 数据库采用 MySQL 主备模式，主备数据通过 binlog 复制，一般情况下，备机只用来备份数据，在主机不工作时才切换到备机；

3. 通过 Nginx 对静态资源进行缓存；

4. 详细设计

4.1 核心功能

学生管理系统业务功能图如下：

学生选课流程

4.2 关键设计

1. 性能上采用 Nginx 服务器，网上资源查询单机可以达到每秒 5 万的并发量，因此能胜任代理服务器来负责请求的转发和负载均衡。

2. 子系统的通信采用 httpclient 进行调用即可，例如登录学生子系统和课程子系统都需要相应的权限，需要通过接口的方式从权限子系统中获取登录用户对应的角色和权限。

3. 因为后期可能还有一些其他校园业务的功能需求，出现部分改动或新增需求，在不影响其余子系统的正常使用外对系统进行了拆分，比如课程子系统，新增或改动需求，影响到选课模块不能正常使用的情况下，但不会对学生信息管理带来影响。

4. 系统采用内外网访问模式，就会涉及到信息安全方面的考虑，采用 https 协议，需加入软或硬件防火墙机制，规避常用的攻击手段，保证系统的正常的使用。

5. 对数据库单表出现千万级别的数据的考虑，比如：题库、考题明细，由于 MySQL 单表数据量过大后，会造成慢查询出现性能瓶颈，通常的解决方案是分库分表，但系统的复杂度就会上升。如果要达到平稳度过，提出的解决方案：对已经毕业 2-3 年的的学生历史数据可以进行归档处理，题库数据进行定期的更新或删除等等处理。

4.3 设计规范

1. Nginx 通过解析请求 URL，代理至不同的服务子系统。

2. 各个子系统对外提供基于 http 协议的 API 接口，不建议使用 restful 形式中的 DELETE 和 PUT 类型接口。

3. 各子系统使用 Spring Boot + Mybatis 开发。

4. MySQL 使用 Innodb 存储引擎，使用 binlog 进行数据备份

5. 质量设计

1. 可测试性

采用 swagger 注解的方式来获取 API 说明，交互接口有单元测试；

1. 可维护性

系统记录了用户登录日志，关键操作日志，在线用户实时查询等功能

1. 可观测性

系统接入了类似 zipkin 等监控插件，完成对服务器硬件性能的监测和调用链路的监控

1. 成本

部署子系统的应用服务器(子系统可以独立部署或者统一部署在同一台性能较好的服务器上)，数据库服务器 2 台(解决服务器宕机后的数据库切换)

如果要考虑外网访问，建议加入一台硬件防火墙

1. 安全

采用 https 协议和软或硬件防火墙机制，提供内外网访问

6. 演进规划

6.1 一期

完成权限子系统，学生子系统、课程子系统的所有功能上线；

6.2 二期

功能优化：根据校方使用提出的反馈进行修改优化

BUG 修复：完善修复项目开发中出现的问题

监测：建立服务 zipkin 监测

6.3 三期（待定：是否升级为微服务架构）

将系统改造为使用 springcloud 的微服务架构，增加网关和 springsecurity 权限框架等，

将子系统之间的调用由 httpclient 接口方式改为微服务之间的调用；

当前比较流行架构模式，向外介绍也比较高大上，后续可以详细介绍；