第九期 - 模块一

1. 微信架构

2. 学生管理系统

3. 分析：

4. 公网域名访问，因此需要有 LB 服务器进行域名与实际服务器 IP 的映射

5. 3 人合作，因此需要对系统架构进行拆分，又根据三原则中的合适，整个架构最好 3-5 个模块，每个人实现不同功能。

6. 能够管理 1000 人，因此根据三原则的合适、简单原则，只需考虑学生数据不丢失，不需要考虑高性能、高可用。

7. 大家都会 java，虽然有个 php 高手，考虑到后期维护以及协同设计、开发因此用 java 实现后台

8. 经济条件一般，因此尽量符合简单原则，不需要搞分布式或多集群部署

方案一

前端 web 服务器负责缓存静态资源与 api 管理，后端服务按业务逻辑拆分多个服务，并且构建主备 mysql 用作存储。

方案1

方案二

前端 web 服务器同方案一，后端水平扩展多实例部署，业务逻辑完全部署在一个机器实例，数据库采用主备存储。

方案2

最终选择方案二。理由：

从合适原则分析：方案一与方案二均架构简单、方案一按逻辑功能拆分后端服务，方便 3 名同学开发任务分配；方案二按采用单服务多实例部署，也是因为其 1000 的数据量完全可以满足。拆分 web、后端、mysql 也是从 MVC 的架构考虑，无需用到微服务引入支撑微服务的一套基础服务增加成本

从简单原则分析：两种方案都比较简单，但是方案二因为其可以简化到单机器实例（如下图），同时 mysql 也可以前期用单 mysql 因此更占优势

从演化原则上分析：方案一、二均具有较强扩展性，但方案二在 1000 的用户量下架构可以更简化（如下图）

因此从简单、成本上选择方案二