架构实战之微信业务架构|学生管理系统

微信业务架构图概览

简单业务图

学生管理系统架构方案设计

需求内容

假设今年学校毕业设计要求提升，要求做真正可运行的学生管理系统，学院对毕设的具体要求如下：

① 要求可以通过公网域名访问；

② 要求至少 3 人合作完成；

③ 能够支撑管理 1000 个学生；

④ 答辩的时候会根据架构方案来进行打分，不推荐太简单和太复杂的方案

你找了 2 个好朋友一起来做这个项目，你们的基本情况如下：

① 大家都会 Java，但是有一个是 PHP 高手；

② 大家经济条件一般

作业要求：

① 对照面向复杂度架构设计方法论，构思 2 个以上的备选架构方案

② 使用 PPT 来画出你的备选架构方案，并说明方案的优缺点

③ 给出你选择的最终方案以及选择理由

复杂度分析

• 高性能：面向用户为学生，对于性能方面没有特殊的要求，可以暂不考虑面向 C 端用户时要求至少 300ms 接口场景，但为了尽量降低服务器压力提高响应速度，还是准备引入 redis 作为静态数据缓存

• 高可用：系统应该具备高可用性，以免出现服务问题影响学生的学习工作开展

• 可扩展：学生管理系统业务相对比较单一，可扩展方面主要集中在部分业务场景的调整，对于系统架构层面不构成直接影响

• 其他：团队成员均会 Java，考虑使用 Java 技术栈开发

架构方案 A

• 单体架构

• 服务器划分，将应用服务器和数据库服务器分割，Nginx 服务器可同时部署在应用服务器上（暂不考虑服务器层面的高可用）

• Nginx 负载均衡，同时部署前端网页应用

• 数据库采用单机器主从节点（做数据备份，不考虑使用读写分离）

• 配置一个小型的 redis 服务，用于缓存简单的静态数据

架构方案 B

• 相比于 A 架构的区别是采用微服务架构，基于 SpringCloud 组件

• 从分层的角度划分出前端服务器

架构方案 C

• 针对微服务框架的使用，为了提高运维、监控、链路追踪等效率，可以使用容器化部署服务，基于 K8S、Docker 进行服务部署，同时采用 Skywalking、Prometheus、ELK 各项实现监控

• 该方案偏向于部署层面，对于业务层的架构影响不大，可以直接参考方案 B

方案选择

最终选择方案 A，理由如下：

• 采用单体架构，一是团队人员较少，二是业务不算复杂，若引入微服务会带来运维成本和排错成本

• 微服务架构会带来更多的资源消耗

• 大集群模式会需要更多的运维人员介入，不符合团队目前规模要求