架构实战 模块三作业
0. 作业要求
前言
本文是【学生管理系统】详细架构设计文档,用于指导消息队列后续的开发、测试和运维。
词汇表
Nginx:高性能的 HTTP 和反向代理 web 服务器
MongoDB:是一个基于分布式文件存储的数据库,介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库
1. 业务背景
随着学习规模的不断扩大,学生数量急剧增加,有关学生的各种信息也成倍增长,人工管理信息的缺点日益吐出,面对庞大的学生信息量,学生信息管理系统成为了学生管理不可缺少的部分,它对于学校的管理者来说都至关重要。
2. 约束和限制
时间要求:两个月内完成
可用性要求:99.9%
业务要求:第一年,能接受 1000 名学生的同时在线访问,未来三年,能接受 2000 名
3. 总体架构
3.1. 架构分析
3.1.1. 可扩展
对于学生管理系统来说,功能相对并不复杂,也比较稳定,并且有明确时间要求在两个月内完成,因此,从架构设计方面不考虑拆分多个微服务。
3.1.2. 高性能
从业务要求分析,未来三年内,系统同时访问量在 2000 人,且学生用户更多都是进行查询操作,因此,系统的高性能要求并不是很高,只要系统架构设计可以满足通过横向扩展方式来提升系统性能就可以。
3.1.3. 高可用
业务要求了 99.9%的可用性,通常的数据库主从架构基本上都可以满足这个指标要求。
3.2. 总体架构
系统部署架构采用可扩展的架构设计:
web 服务器:部署 2 台 Nginx 代理服务器,2C | 4G | 30G,上游经过 DNS 轮询,可实现 web 服务器层面的高可用
应用服务器:部署 2 台应用服务器,4C | 8G | 60G,每台部署相同的应用程序,上游经过 Nginx 负载均衡,可实现高可用和高性能,若后续处理性能达到瓶颈,可横向扩展增加应用服务器
数据库服务器:采用 MongoDB,3 节点集群部署,4C | 16G | 300G,主节点负责读写,2 个从节点负责同步数据,实现数据服务层面的高可用,若后续有性能瓶颈,可以进行 CPU 和内存的升级,或者进行读写分离的配置
4. 详细设计
4.1. 核心功能
4.1.1. 查询基础数据
4.1.2. 查询课程
4.1.3. 查询考试成绩
4.2. 关键设计
4.2.1. 数据存储可靠性
采用 3 个节点 Mongodb 副本集部署方案,在很大程度上保证了数据的可靠性
当主节点宕机时,余下节点会选出主接管数据库服务,应用层面直接访问接管的主
4.3. 设计规范
4.3.1. spring boot 开发框架
4.3.2. http 1.1 通讯协议
4.3.2. 系统间的通讯数据格式 json
5. 质量设计
5.1. 可测试性
尽量避免使用静态方法
使用依赖注入(DI),依赖注入可以很容易的替换真实的业务逻辑,从而把被测对象与依赖环境隔离开来
使用接口,可以利用对接口的实现把模拟功能引入被测试对象中
实例初始化要简单,单元测试过程要对被测试类进行创建和销毁。简化类的实例初始化逻辑,不但有利于编写自动化代码,也可以提高单元测试的运行效率
5.2. 可维护性
按照功能分为若干层,接口层、应用层、服务层、数据访问层,每一层再按照功能分,即按照一定的方式进行进行模块和类的归类
6. 演进规划
随着后续的业务发展,可以在架构设计上进行适当的演进:
增加缓存,提供查询效率
评论