前言

该文档主要是外包学生管理系统的架构文档，用于指导学生管理系统的业务开发、测试及运维

词汇表

spring boot: web 开发框架

MySQL: MySQL 是最流行的关系型数据库管理系统之一，此架构中用于存储业务数据。

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

1. 业务背景

1.1 当前的情况

·       学校的规模不断扩大，学生数量不断增加，需要处理的学生信息越来越多

·       处理学生信息需要的教师资源逐步攀升

·       人工处理数据，效率低下

基于当前的情况，引入线上学生管理系统。用来解决当前出现的问题。

1.2 学生管理系统解决的问题有哪些

·       可以减少运营学生管理系统的教师人数

·       相对于人工，极大的提升了工作效率

·       未来学校规模和学生人数的不断增加，信息化都非常的易于支撑发展

·       使得整体的工作更加的系统化、规范化、自动化

1.3 涉及到的业务模块

·       学生管理

·       课程管理

·       权限管理

·       考试管理

2. 约束和限制

1.    两个月之内完成

2.    测试的时长不低于研发时间的 2 成

3.    服务器费用，一年少于 3 万块，后期根据数据量增加再增加硬件预算

4.    有基础的防火墙，白名单等限制

5.    可用率要达到 99.9%

6.    能保证业务扩展性

7.    防止 sql 注入，基本业务代码安全要实现

8.    学生核心信息要脱敏

3. 总体架构

3.1 架构分析

高性能：对于学生管理系统来说，总学生应该也就几万人，对学生管理系统的要求不高；针对一些特殊场景如抢课，一门课 1000 人抢课，对于一个系统的处理性能要求也不高。

高可用：一般情况下，学生管理系统挂掉几个小时，对学校的正常教学并不会有太大影响，大部分的学校教学活动并不完全依赖于学生管理系统。但是，由于学生、课程信息等是由学生和教师自己注册或者上传维护上去的，不能全部丢失，否则想要补全这些信息很困难。

可扩展：经过业务需求的分析，可以发现业务还是比较复杂的，有各种学生的管理，还有课程，考试，需要不断维护更新，后面还要进行统计分析、奖惩管理等，理解难度稍高，并且会根据学校的教学活动的变化而有新的需求增加，所以系统的可扩展性要求是比较高的，多人协作开发的情况下，需要进行一定的模块划分。

成本、安全：由于只在一个学校中使用，服务器成本应该不高；由于系统中不涉及学生、教师等的私密信息，不涉及资金流转，安全性上的要求也不算高。

3.2 总体架构

此次架构分为三层：网关层、业务服务层、数据层。

网关层：

·       使用 Nginx 作为服务器网关，主要用于请求的负载均衡与服务路由分发，学生信息的相关请求路由到学生子系统，课程信息、考试相关的请求路由到课程子系统，教师、权限相关的请求路由到权限子系统。

业务服务层：

·       业务服务层由三个子系统组成：学生子系统、课程子系统、权限子系统。

数据层：

·       数据层由一主一备两台 Mysql 数据库服务器组成，主数据库负责日常所有业务数据的读写，并实时备份数据到备库，备份方式使用 binlog 异步同步。

·       由于业务性能要求不高，不需要做读写分离。

·       备库负责存储备份数据并在主库出现故障时临时切换到备库，保障可用性。

·       部分开发与运维同学使用数据库工具查询 or 统计数据时，可连接备库进行查询，这样可以保障主库的稳定性。

4. 详细设计

4.1 核心功能

4.1.1 功能模块划分图

·       总体模块划分为三个子系统：学生子系统、课程子系统、权限子系统。

·       学生信息，教师信息都放到学生子系统中，包括登录账号密码、手机邮箱等账号相关信息，也包括个人的组织层级关系。

·       个人的课程与考试信息可以放在学生子系统中，使用学生课程关系表、学生课程成绩表等记录。

·       课程子系统负责课程的配置与管理，包括课程的上课时间、学期等基本信息，也包括选课功能。

·       教材管理可以关联到课程上，作为课程的一部分信息。

·       考试管理包含试卷的上传、分数评定等。

·       权限子系统包含成员信息的查看权限、编辑权限，课程的查看权限、编辑权限等。

4.1.2 查询用户基础数据的流程

4.1.3 查询用户课程的流程

4.2 关键设计

4.2.1 子系统拆分设计

·       有比较清晰的子系统业务边界，画出业务边界图，并整理出对应的业务功能。

·       根据业务功能设计好大概需要实现的路由及方法。

·       业务主要为数据逻辑加控制逻辑的呈现，使用框架基础的 mvc 架构即可，数据逻辑中做好 model 的设计。

·       各个系统给出详细的接口文档。

4.2.2 高性能的设计

·       做好常用查询设计的索引设计，提供数据库的访问性能。

·       经常访问的不变的数据写入到缓存中，提升访问速度。

4.2.3 数据存储可靠性

·       采用主备的数据库架构，可以在很大程度上保证数据的可靠性。

·       做好数据库定时备份工作。

4.3 设计规范

4.3.1 采用 spring boot 开发框架。

4.3.2 采用 http1.1 的通讯协议。

4.3.3 系统间的通讯数据格式采用 json

4.3.5  MySQL 采用 InnoDB 的存储引擎

4.3.5 使用模版技术做前端页面集成

4.3.6 所有数据变更库必须具有幂等设计。

5. 质量设计

5.1 可测试性：每个子系统在具体的研发设计阶段，设计好细节功能的路由描述，以及单个服务的自述，便于进行对应的测试用例书写。

5.2 伸缩性：每个子系统均拆开，部署在不同的服务器上。后续如果有性能要求，对应的节点增加机器即可，数据库可采用一主多从等方式。

5.3 易用性：友好的操作界面，可读的操作手册。

5.4 协作性：各个模块可同时开工，子系统对接的部分做好 mock 数据。

5.5 安全性：核心数据脱敏，业务逻辑做好防注入等安全校验。

5.6 可维护性：MySQL 可通过运维控制台进行管理。

5.7 成本：目前云服务器的成本还是比较低的，而且由于性能要求不高，整体服务器可以选普通的服务器即可。

6. 演进规划

6.2 学生管理系统二期架构演进方案

·       二期演化的核心为前后端分离，把前端独立出来，目的是为了开发更加的高效，前端的修改，上线不需要影响到具体的后端应用。

·       前端使用 Vue 或 React，减少学习成本，统一页面模块，组件化实现。

·       采用小迭代的开发模式，后端改造量不大，只要返回格式，统一封装即可。原始的后端页面保留，可以保证日常的系统使用。新的后台功能逐步增加，逐步替换原用系统