前言

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

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 采用主备的体系，数据上高可用。采用一主一备，也是因为性能要求较低。

4. 详细设计

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

4.1 核心功能

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

4.1.1 查询用户课程的流程

4.1.2 查询用户考试成绩的流程

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，直接做好服务注册和发现即可。

• 引入具体业务层，组织不同服务的调用，以及给前端的数据封装。

• 核心主要为引入不同的技术组件，来实现自动化及 devops 的模式。