前言

本文档将从架构方面对整个系统进行综合概述，用于记录并表述对系统的架构方面做出的重要决策，以便于开发人员高效的开发和快速修改和管理。

1. 业务背景

随着学校的规模的不断扩大，学生数量的增加，需要处理的信息也日趋增大，由此带来几个明显的系统问题：

• 资源浪费：目前将大量教师的教师资源投入在学习信息管理上不仅造成了大量的资源浪费，还在消磨教师的精力，类似如此机械且不复杂的事务应尽早脱离人工维护，通过系统进行统一管理，不但可以解放紧缺的教师资源，也可让信息处理更方便，迅速。

• 管理成本：不同教师每个人都有不同的工作习惯以及作息时间，学生信息存在不及时且可能存在因人工原因产生的错误，也可能存在多个不同格式的版本，在质量和效率上都无法保证，不易于统一管理，使学校无法正确分析学生信息以及其他日常管理工作。

业务效率：学生在查询成绩，选课以及维护个人信息时需要联系对应的教师，会导致教师资源的二次浪费，且一名教师无法同时服务多名学生，也无法保证选课的公平公正。

基于以上背景，我们需要开发外包学生管理系统可使得教师资源得到解放，同时可同时服务全体师生，且易于学校进行管理。

2. 约束和限制

1. 应积极使用开源技术（社区活跃），保障系统可维护性

2. 成本不能超过 10 万

3. 数据库采用 MySql

4. 质量标准符合 ISO9001 标准 以及校方信息化建设标准

5. 需同时支持 3000 在线登录用户

6. 项目交付周期 2 个月

3. 总体架构

学生管理系统架构方案

3.1 架构分析

3.1.1 高可用

本系统核心使用时间在学期初、中、末三个阶段，保障数据不丢失的前提下短时间的服务不可用是可接受的。因此需保障数据库主从结构，从机负责备份用户数据，各个子系统可根据实际性能需求进行机器配置调整即可。

3.1.2 高性能

与互联网系统业务不同，学生管理系统日常访问流量较低，主要使用功能点集中在学生管理，权限管理模块的信息维护，查询等，不涉及大流量业务，在学期初，学期末的选课以及考试和成绩查询阶段访问量会显著增多，因此需要保障子系统性能即可满足需求。

3.1.3 可扩展

学生管理系统后续存在对接其他已有系统或新系统的可能性，因此在开发设计上需要保障可扩展性。

3.2 总体架构

1）通过 Nginx 实现反向代理与负载均衡，负载均衡算法采用轮询算法

2）数据存储使用 MySql，由主机提供读写服务，备机进行数据备份，在主机宕机恢复期间可临时提供查询服务。

3）按照业务流量划分各个子系统，其中流量小的子系统开部署在同一机器内，流量大子系统可按需扩展机器。

4. 详细设计

4.1 核心功能

4.1.1 用户权限严重流程

（TODO）

4.1.2 学生选课流程

（TODO）

4.2 关键设计

1）可扩展

通过制定交互规范，接口设计规范，数据库设计规范来保障系统可扩展性。

2）可维护

开发框架采用社区活跃的开源软件，项目交付后也可进行快速升级软件版本，迅速解决漏洞，提升系统健壮性。

3）高性能

通过区分常用业务与核心业务来进行服务器分配，使用有限的机器来最大程度保障业务正常使用。

4）高可用

服务合理化拆分，当部分应用存在故障时也不影响其他子系统使用，数据采用主从模式，从机用于备份数据，在主机宕机时可保障数据不丢失也可正常提供服务。

4.3 设计规范

4.3.1 交互设计规范

• UI 设计需要统一风格

• 交互设计需要易于使用，方便用户快速找到指定功能

4.3.2 数据库设计规范

• 所有的表和字段名要使用统一的命名规范。命名要求如下：

• 能区分该表的业务类型。

• 能区分该表功能类型。

• 能区分该表的实体信息。

• 不同表中具有相同业务含义的字段要定义成统一的数据类型，避免不必要的类型转换。

• 表字符集使用 UTF8MB4 字符集，校验字符集使用 utf8mb4_general_ci

• 所有表都要添加注释，除主键外的字段都需要添加注释

• 所有表都必须显式指定主键

• 适度使用视图，禁止使用存储过程、触发器和事件

•  单表数据量控制在 5000 万以内

• 数据库中不允许存储明文密码

• 尽量符合数据库的几个范式

• 尽量合理定义字段长度

（详情参见数据库设计规范文档）

4.3.3 接口规范

1. api 接口必须加版本号，初始版本 【v1】。

2. 不使用 rest 的 PUT 和 DELETE，因为很多浏览器不支持，很多框架也不支持。

3. POST 在需要传输大量数据的时候使用，其余使用 GET。

4. 接口返回格式采用 JSON，不要使用 XML，格式统一,，参照以下内容。

{      "code" : 0,      "msg" : "msg",      "data" : {
      }}

• code: 0 为成功，非 0 为失败。可以自定义 code，代表不同的错误码

• msg: 当 code 为非 0 时，获取错误信息。当 code 为 0 时，msg 一般为”success”。如果有需要也可以另外作规定

• data: 当 code 为 0 时，获取结果，全部以 json 方式表示。当 code 为非 0 时，data 没有数据

（详情参见 API 设计规范文档）

4.3.4 异常处理规范

• 不要直接将异常抛给客户端处理，一般需要一个统一的异常处理类，并且以统一格式将异常信息返回前端

• 未每类异常定义错误代码，并保证错误代码可追溯

5. 质量设计

• 可测试性：需进行业务测试以及压力测试,单体测试代码覆盖率 60%，核心业务代码覆盖率 90%以上。

• 可维护性：系统采用成熟开源框架进行开发，使用社区活跃度高的开源软件。

• 可观测性：系统运行异常告警以及恢复方案。

• 成本：在满足业务的情况下控制最小成本。

• 可扩展性：系统需具备可扩展性，方便后续迭代演进

• 容灾：不涉及

• 降级限流：不涉及

6. 演进规划

• 支持横向扩容

• 新系统接入

• 现有系统融合