微信业务架构图

学生管理系统

复杂度分析

1. 公网访问

• 如果学校原来已有服务器，可以复用已有资源

• 如果学校没有服务器，则考虑上云

2. 安全性

• 因为面向公网开放，需要考虑安全性，只开放前端访问入口

• 后端和数据库只提供内网访问

3. 高并发

• 支撑 1000 个学生不算很高并发，只需要简单架构实现

4. 高可用

• 系统主要业务为数据的管理，在成本限制情况下可不考虑服务的高可用，只保证数据可用

5. 扩展性

• 因为是毕设作品，只需要考虑一次交付，无需考虑维护和扩展

6. 成本

• 学生买不起太贵的资源来做毕设，各项资源在满足高可用条件下可使用低配置来完成，且只需要支持 1000 个学生，可以满足

7. 多人合作

• 因为没有说到专门做前端的同学，先认为大家都可以做简单的前端

• 3 人只是一个微型团队，管理成本上不大

• php 高手在这个协作中好像没什么特别的，但 php 开发效率高，对前期功能验证有较大帮助

• 需要完成的模块是学生/教师/权限这 3 个模块，可以分配给每人一个模块

备选架构一

• 此架构从成本上来说省到了极点，只有 3 台服务器

• 优点

• 成本最低

• 数据高可用得到满足

• 缺点

• 安全性不足，整台服务器对外

• 服务高可用较难满足

• 全部位于一台机，联调较麻烦

• 需要考虑单机性能是否可以达到访问量需求

备选架构二

• 此架构使用了两台服务器做负载均衡

• 优点

• 服务和数据的高可用得到保证

• 通过负载均衡将业务服务器放置于内网，提高安全性

• 相比起一台机，两台机对于访问量会有较大性能提升

• 多人开发联调方便

• 缺点

• 成本略高

• 部署略复杂

• 工作量增加，需要另外配置负载均衡，可能是一个服务，也可能需要自己搭建

最终选择

• 选择了架构二，基本需求都可以得到满足

• 虽然是学生，但也不能不考虑成本过于压缩带来的负面效应

• 架构图并没有考虑前后端和技术栈问题，题目给出不明确，可能要求较低，可采用方案也极多

• 考虑模块划分，我认为可以让 php 高手用 smarty 模板来做前端渲染，java 们去做后端数据处理

• 因为成本问题，前后端都部署在两台业务服务器上且独立运行是合适的