1. 业务背景

随着学校的规模的不断扩大，学生数量的增加，需要处理的信息也日趋增大。不仅花费大量的教师资源， 处理效率也十分低下。 为提高学生管理的管理水平，优化资源，尽可能降低管理成本，需要建设一套学生管理系统，进行规范化地管理、科学性统计和快速查询、修改、增加、删除等，提高信息的准确度以及日常管理的工作效率。

2. 约束和限制

• 必须在 12 月 31 日上线

• 数据不能丢失

• 尽量降低部署成本和运维成本

• 并发数不超过 1000

3. 总体架构

3.1 架构分析

• 高性能/并发：在校师生数量有限，几万用户，且仅在选课、查成绩存在并发场景，并发数不超过 1000，压力不大。

  高可用：学生管理系统宕机小段时间对学校的运营、管理影响不大，但是必须保证数据不可丢失，一主一备即可；针对抢课、考试这类特殊场景需要保证服务不崩溃。

  可扩展性：后期可能涉及一些学生成绩、课程相关的分析功能模块。

3.2 总体架构

将系统拆分为三个子系统：学生子系统，课程子系统，权限子系统。为了方便后续维护管理，增加后台管理子系统。

系统架构图

系统边界白盒图

将系统拆分为三个业务子系统和一个后台管理子系统。每个业务子系统分别部署两个集群节点，后台管理子系统单节点部署。

Mysql 采用主备部署，一台主机，一台备机。正常情况下，主机提供读写服务，备机实时备份；主机宕机后，手工切换到备机。

Nginx 作为负载均衡器，负责分发请求到各子系统。使用 Nginx 缓存静态资源并实现基本的 waf 功能。

Nginx 和后台管理子系统部署到服务器 M1，业务子系统的两个集群节点分别在两台服务器 M2 和 M3，Mysql 主备节点也分别部署到服务器 M2 和 M3。共需 3 台服务器。

4. 详细设计

4.1 核心功能

• 用户基础数据查询时序图

• 

• 用户课程查询时序图

• 

4.2 关键设计

• 子系统拆分设计

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

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

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

• 高性能的设计

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

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

• 数据存储可靠性

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

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

4.3 设计规范

• 采用 spring boot 开发框架。

  采用 http1.1 的通讯协议。

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

  mysql 采用 InnoDB 的存储引擎

5. 质量设计

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

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

• 协作性：每个子系统独立工程，可同时开工，子系统对接的部分做好接口文档本分和 mock 数据

6. 演进规划

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

• 三期演化的核心做微服务架构转化，引入 rpc 框架，提高内部的调用效率。