外包学生详细架构设计文档

前言

[可选，用于总体上描述本篇文档的内容和目的]

[样例：本文是游戏业务线消息队列中间件详细架构设计文档，用于指导消息队列后续的开发、测试和运维]

词汇表

[可选，用于明确定义和说明一些英文缩写、术语等，请用表格来呈现，infoq 写作平台不支持表格，所以只能一个一个的列]

[样例：

Reactor: 网络编程模式

Netty: 开源的网络编程框架

]

1. 业务背景

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

为提高学生管理的管理水平，优化资源，尽可能降低管理成本成为学生管理的新课题，学生管理系统是从学生管理现状出发，根据学生管理的新要求进行开发设计的，它需要解决学生信息管理数据信息量大修改

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

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

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

功能设计的管理系统。

系统主要应用于学校学生信息管理，总体任务是实现学生信息管理的系统化、规范化和自动化，其主要任务是管理学生相关信息，如学籍、课程、成绩、奖惩。

2. 约束和限制

① 符合团队技术水平和积累;

② 开发成本低;

③ 系统运维成本低。

3. 总体架构

[必选，描述经过备选架构决策后定下来的架构方案，这一章主要是描述架构的 3R：Rank、Role、Relation]

[技巧：1. 系统边界白盒图描述系统内的角色与外界的交互(Rank + Role + 外部 Relation)；2. 系统架构图来描述内部的 Role + 内部 Relation]

[注意：不建议一张图同时描述系统架构的 3R 以及与外界的交互，因为图太复杂，画系统边界白盒图的时候，系统内部的 Relation 可以不画]

3.1 架构分析

3.1.1 高可用

学生管理系统的使用者为学校管理人员及学生，因此对于可用性要求不高，可以容忍一定程度上的系统故障。

3.1.2 可扩展

根据业务分析，学校的信息化发展很迅速，并且信息系统在不断增加和更新，作为基础管理系统，对于学生管理系统的扩展性要求较高，以便满足业务的持续发展。

3.1.3 高性能

学生管理系统作为学校内部的管理系统，为管理人员和师生提供查询和管理服务，因此需要支撑一定访问量的查询服务，从根本上来说，不需要过高的性能支撑。

3.2 总体架构

1）采用数据分散集群的架构，集群中的服务器进行分组，每个分组存储一部分消息数据。

2）每个分组包含一台主 MySQL 和一台备 MySQL，分组内主备数据复制，分组间数据不同步。

3）正常情况下，分组内的主服务器对外提供消息写入和消息读取服务，备服务器不对外提供服务；主服务器宕机的情况下，备服务器对外提供消息读取的服务。

5）客户端采取轮询的策略写入和读取消息。

 学生管理系统从功能上可以分为如下模块：

学生管理系统与其他系统间的关系如下：（黑盒）

内部模块与其他系统间的关系如下：（白盒）

4. 详细设计

[必选，描述核心场景或者流程的实现机制]

4.1 核心功能

[必选，描述核心场景或者流程的实现机制，对应 4R 架构中的 Rule，每个核心场景一个小节]

[样例：

4.1.1 消息发送流程

4.1.2 消息消费流程

]

[技巧：使用系统序列图来描述 Rule，跟项目开发中写设计文档一样的写法]

4.2 关键设计

[必选，描述系统的一些关键设计点是如何实现和取舍的]

[样例（如果你有兴趣，可以对比一下 kafka 的文档：Kafka design）：

1）消息发送可靠性

业务服务器中嵌入消息队列系统提供的 SDK，SDK 支持轮询发送消息，当某个分组的主服务器无法发送消息时，SDK 挑选下一个分组主服务器重发消息，依次尝试所有主服务器直到发送成功；如果全部主服务器都无法发送，SDK 可以缓存消息，也可以直接丢弃消息，具体策略可以在启动 SDK 的时候通过配置指定。

如果 SDK 缓存了一些消息未发送，此时恰好业务服务器又重启，则所有缓存的消息将永久丢失，这种情况 SDK 不做处理，业务方需要针对某些非常关键的消息自己实现永久存储的功能。

2）消息存储可靠性

消息存储在 MySQL 中，每个分组有一主一备两台 MySQL 服务器，MySQL 服务器之间复制消息以保证消息存储高可用。如果主备间出现复制延迟，恰好此时 MySQL 主服务器宕机导致数据无法恢复，则部分消息会永久丢失，这种情况不做针对性设计，DBA 需要对主备间的复制延迟进行监控，当复制延迟超过 30 秒的时候需要及时告警并进行处理。

3）消息如何存储

每个消息队列对应一个 MySQL 表，消息队列名就是表名，表结构设计为……(此处请自行补充）

]

[技巧：常见的关键设计点包括高性能、高可用、可扩展、安全等]

4.3 设计规范

A. 使用 IntelliJ IDEA，如电脑配置达不到要求，可使用 Eclipse

B.使用 SmartBI 可视化工具展示图表

C. Git 使用 git 对源代码版本进行管理

D. Maven 项目构建管理工具使用 Maven3 版本

后台开发框架使用 SpringBoot+Mybatis、Python3

前端使用 Vue.js 搭建基础框架 

使用 Vue-Router 实现路由管理 

使用 Element 组件进行开发

基于 Axios 实现请求的发送以及数据处理

浏览器兼容 Chrome、Edge 浏览器

系统生产环境需求

A. JDK8 使用 java 语言进行开发，运行环境使用 JDK8 版本。

B. Linux 项目最后在 Linux 系统上运行

C. ETL 工具使用 Python3 运行

D.Redis 及 MySQL 数据库使用客户方现有实例

1.1. 系统部署需求

1.1.1. 部署整体架构

本模块系统采取与产品生命周期系统一致的微服务集群架构进行部署，以减轻后期运维的成本及复杂程度。

1.1.2. 应用部署方式

在本模块系统的服务中，应用采取 Docker 的形式进行部署。具体如下：

5. 质量设计

1.1. 系统可扩展性需求

说明系统在可扩展性方面的要求。可扩展性包括：通过配置方式来满足业务扩展需求，通过二次开发来满足业务需求。

1.2. 系统安全性需求

1.防止一些常见的 web 安全漏洞，例如 XSS（跨站脚本攻击）、CSRF(跨站请求伪造)、

URL 跳转漏洞、SQL 注入等。

2.上传文件功能对上传大小以及后缀要有限制，避免用户上传可运行文件，以及批量上传大文件，配置信息可从配置文件中进行修改调整。

3.不要在 cookie 中永久性存储敏感数据，不要使用 HTTP-GET 协议传递敏感数据。

4.设计好异常处理机制，对异常进行统一管理，页面不要出现错误代码，给出友好提示页面，例如出现 500、404、403 等错误情况，跳转到统一的错误友好提醒页面。

1.3. 系统可维护性需求

系统中的各种设备均具有良好的可维护性，各个模块之间要低耦合，不能有过多的依赖关系，便于日后维护，同时系统须具有较低的维护成本。

6. 演进规划

系统分为两期实现：

第一期（本期）：实现系统基本功能，并形成业务闭环

第二期：实现与学校其他系统间的业务整合，及数据梳理。