前言

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

词汇表

spring boot: web 开发框架

oss: 云存储服务

cdn: 内容分发网络

mysql: 一种关系型数据库

java: 编程语言

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

git: 分布式代码版本管理工具

swagger：用于生成、描述和调用 RESTful 接口的 Web 服务

mock：虚拟对象或事虚拟数据

ci/cd：持续集成/持续交付

devops: 是一组过程、方法与系统的统称

1. 业务背景

1.1 当前的情况

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

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

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

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

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

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

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

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

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

1.3 涉及到的业务模块

• 学生管理

• 课程管理

• 考试管理

• 权限管理

1.4 下图为边界黑盒图，以便于更加清晰模式业务模块及交互的功能点

业务边界黑盒图

2. 约束和限制

1. 两个月之内完成

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

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

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

5. 可用率要达到 99.9%

6. 能保证业务扩展性

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

8. 学生核心信息要脱敏

3. 总体架构

后续会有两个小节的内容，来做整体的架构的分析与说明。分别为架构分析，与总体的架构方案。在架构方案中会提供系统边界白盒图与系统架构图。

3.1 架构分析

3.1.1 高性能/并发：因为主要是管理后台，操作者一般为教师，并发不高，且对具体的响应时间忍耐度适中。所以此架构只要满足性能适中即可。

3.1.2 高可用：整体的业务诉求，对可用性要求适中。及时性要求要没有那么苛刻，满足基础的使用即可。数据在这个架构中属于最重要的一环，做好数据库主备，一主一备即可。

3.1.3 可扩展性：代码实现拆分为不同的模块，用来实现不同业务模块的功能，可以做到增加模块或修改功能效率高，整体的耦合度降低。

3.1.4 安全性：核心数据进行脱敏，业务代码增证。

3.2 总体架构

3.2.1 给出系统边界白盒图与系统架构图

系统边界白盒图

系统架构图

3.2.2 具体的架构分析

1. 所有的静态资源请求走 cdn，一是为了更快的响应速度，二是可以减少集群的带宽，三是 cdn 现在的价格非常低，与减少的带宽费用可以相抵，且能有更好的性能。

2. nginx 做反向代理，转发 http 请求，也可以配置成根据不同的请求 path 来转发不同的后端服务。

3. nginx 也可以配置基础的缓存。

4. 引入 oss 是为了保存具体的图片等数据，cdn 可直接回源到 oss 上，此时不需要专门准备机器存储这种大的图片数据，也不需要存储到一台机器，其他机器做挂载。

5. 整体的业务代码采用 java 的 spring boot 做开发，不同的模块，划分为不同的子系统。以便于后续的业务扩展，业务修改。

6. 每个子系统均为单节点，主要还是因为整体的并发比较低，且高可用要求没有那么的苛刻，当前业务也比较简单。

7. mysql 采用主备的体系，数据上高可用。采用一主一备，也是因为性能要求较低。

8. 使用 git 作为版本管理工具，并且使用 CI/CD，方便进行自动化与持续集成。

4. 详细设计

下面会通过 3 小节的内容，来阐述具体的详细设计。涉及到核心功能，系统关键设计，以及设计规范。

4.1 核心功能

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

4.1.1.1 图示说明

• 涉及到场景为，教师查看用户的基础信息，为了减少过多的调用次数，整体的业务代码由学生子系统和数据库支撑

• 第一次查询完权限系统后，返回 token，后续的请求进行 token 验证即可，做好过期时间的处理。

4.1.2 查询用户课程的流程

4.1.2.1 图示说明

• 该逻辑为教师查询学生对应的课程，该逻辑需要 2 个子系统协作完成

• 学生子系统提供学生数据，拿到 id，去取对应的课程信息

• 可带入如时间维度等筛选项，获得更加具体的数据

4.1.3 查询班级考试成绩的流程

4.1.3.1 图示说明

• 该流程为查询班级考试成绩的流程

• 可以利用页面的交互，减少接口请求次数

• 首先依靠页面请求获得班级列表，并在展示的时候，带上班级 id

• 带上班级 id，去考试子系统获得数据，就会变得很简单

• 同样也可带上不同纬度的筛选项

4.2 关键设计

4.2.1 子系统拆分设计

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

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

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

• 每个子系统做好服务自述，引入 swagger 生成对应的接口文档并放入 mock 数据。以便于其他子系统的调试与调用。

4.2.2 高性能的设计

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

• 经常访问的数据，可写入到文件中，当作文件缓存，具体的缓存淘汰机制可暂且不考虑，如果后续发现缓存文件过大，可引入 LRU 做混存淘汰。

• 静态资源存入 oss 中，cdn 回源到 oss 中，网站服务访问 cdn，以提高访问性能。如果 cdn 出现问题，概率很小，访问 oss 对应的资源即可。

4.2.3 数据存储可靠性

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

• 在主备节点复制中，主节点发生宕机，并出现数据损坏的情况，可不做考虑，概率极小，而且实际的业务操作，会有纸质的逻辑可以对照。

4.3 设计规范

4.3.1 采用 spring boot 开发框架。

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

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

4.3.4 mysql 采用 InnoDB 的存储引擎

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

5. 质量设计

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

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

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

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

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

6. 演进规划

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

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

• 前端使用 vue，减少学习成本，统一页面模块，组件化实现。

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

6.3 学生管理系统三期架构演进方案

• 业务拆分演进为微服务架构，可以由 json 转换为 protubuf。引入 rpc 框架，提高内部的调用效率。

• 引入服务注册中心，为了以后加入更多的功能的时候，不用手动配置具体子系统的 ip，直接做好服务注册和发现即可。

• 代码中引入核心业务处理层，封装核心业务逻辑。此时可以在控制器层，做对外 api 的封装，以及给前端的页面数据渲染。

• 来实现 CI/CD 及 devops 的模式，做好持续集成服务。