微信业务架构图

微信业务架构

学生管理系统架构设计

复杂度判断

高可用：学生管理系统只需要保障数据高可用即可，服务短暂挂掉也不会导致太大的损失

高性能？：支撑 1000 人使用，性能上并没有太大压力

可拓展：业务相对复杂，需要三个人员同时开发，但毕设项目结束后一般不需要再做变更

成本：学生，没有什么钱，应该控制成本，服务器尽量最优数量

安全：公网应用，毕设作品，保证基础设施除 Nginx 外只暴露内网即可

备选架构方案

方案一

学生管理系统架构备选方案一

方案说明：

1. 架构采用 Nginx 作为反向代理及负载均衡服务器，Nginx、业务服务器、数据库都在同一内网可相互访问，对外仅暴露 Nginx 端口，运维需要将公网域名解析至 Nginx 服务器地址，用户即可通过域名访问应用

2. 业务服务器部署三个实例提升性能，可根据性能需求动态调整数量

3. 业务系统内部划分三个模块，方便三人协同开发

4. 数据库采用主备架构保证数据不会全部丢失

方案二

学生管理系统架构备选方案二

方案说明：

1. 架构同样采用 Nginx 作为反向代理及负载均衡服务器，Nginx、业务服务器、数据库都在同一内网可相互访问，对外仅暴露 Nginx 端口，运维需要将公网域名解析至 Nginx 服务器地址，用户即可通过域名访问应用

2. 业务服务器拆分成三个独立子系统进行研发，由于子系统之间相对独立，PHP 水平高的同学可以采用 PHP 来开发自己负责的子系统

3. 数据库采用主备架构保证数据不会全部丢失

最终选择方案

优劣分析

方案一：成本低，运维简单，较难发挥出 PHP 高手的技术优势

方案二：拓展性佳，发挥了 PHP 高手的技术优势，但 PHP 模块只有一人可以维护，维护成本高，其他两位同学难以协助 PHP 模块开发

架构设计原则

根据合适原则分析：毕设项目不需要过多考虑后期可拓展性，统一技术栈更有利于团队协作

根据简单原则分析：方案二增加 PHP 技术栈，实际上增加了项目复杂度与维护成本

根据演化原则分析：方案二也不符合演化原则，成本大

总结

方案一更符合此次学生管理毕设需求