模块一：微信业务架构图 & 学生管理系统架构设计

1. 微信业务架构图

2. 学生管理系统架构设计

学生管理系统（以下简称“系统”）需求说明：

• 功能需求：学生管理、课程管理、考试管理、权限管理

• 非功能需求：

• 可通过外网访问

• 能够支撑管理 1000 个学生

• 架构设计方案不能太简单，也不能太复杂

• 至少 3 个人裁剪系统开发

根据面向复杂度架构设计理论，拿到学生管理系统需求后，需进行复杂度判断，复杂度判断过程如下：

• 高性能：系统要求能够支撑管理 1000 个学生，一般的服务器基本都能满足这个要求，系统对高性能要求不高

• 高可用：系统的运行状态对于整个学下的教学过程硬性不大，但是系统的用户操作数据需要着重保护

• 可扩展：系统的功能性流程比较复杂

• 成本/安全：开发者都属于在校学生，经济水平一般，因此需要控制低成本

复杂度判断结果：

• 可扩展：系统功能流程复杂

• 数据高可用：用户操作数据不能全部丢失，需要着重保护

• 成本/安全：需要尽量压缩成本

2.1 方案一

2.2 方案二

2.3 方案三

2.4 方案四

2.5 对比分析

2.5.1 说明

方案一所述的架构，需要 3 台云服务器+1 个公网域名，其中 2 台PostgreSQL服务器置于云服务器内网，Nginx和学生管理系统单机部署。

方案二所述的架构，在方案一的基础上做了变化，将学生管理系统分成 3 个模块来开发，并分别以Docker容器的方式部署，Nginx也通过Docker方式部署。

方案三所述的架构，依托学校现有的公网域名和校内网虚拟化平台，所需 4 台虚拟机，1 台安装Nginx，1 台部署学生管理系统，2 台用于PostgreSQL主从配置。

方案四所属的架构，在方案三的基础上做了调整，将学生管理系统分成 3 个模块来开发，分别部署在不同虚拟机上。

2.5.2 架构选择

考虑毕设要求（根据架构设计方案打分，不推荐太简单、也不推荐太复杂的方案）以及团队的基本情况（3 人开发，都会Java，有一个PHP高手；大家经济条件一般），最终选择方案三，理由如下：

• 方案一、二，需要购买云服务器以及公网域名，这需要一定的经济基础，但团队的经济条件一般，因此排除方案一和方案二

• 方案四，开发团队成员少，开发以及部署上下、维护压力大

• 方案三，符合现有团队的规模和技术积累，开发成本低；部署在校园虚拟化平台，能够大大节省成本；目标学生数量固定，后续不会有太大的变动，对高性能需求不高；部署和维护简单。