微信业务架构图

学生管理系统

复杂度

1. 数据安全，数据不要全部丢失

方案一

优势

1. 开发方面，业务拆分成多个服务，3 个人可以各自用自己擅长的语言、框架，互不影响

2. 满足数据不要全部丢失的要求

3. 因为每个人负责的是独立子系统，毕业论文相对好写，方便答辩

劣势

1. 子系统间通信相对复杂，需要通过 rest API 或 rpc 服务

2. 运维成本更高

3. 硬件成本更高（1 个域名+3 台云服务器）

方案二

优势

1. 所有功能都放到一个服务中，

• 技术栈一致，可以互相 backup

• 代码级的模块间交互，更方便

2. 硬件成本较低（1 个域名+2 台云服务器）

3. 满足数据不要全部丢失的要求

劣势

1. 大家都用统一的技术栈（java），那位 php 同学没有发挥自己的优势

最终方案

我最终选择方案二，因为更符合架构三原则。

合适原则

1. 团队技术平可以满足

2. 开发成本低

3. 运维成本低

简单原则

1. 未系统拆分，部署简单

2. 模块间交互简单，没有使用微服务，也不需要微服务基础设施

演进原则

1. 一次性交付，无需考虑太多后期演化