微信业务架构分析 & 学生管理系统架构选型

微信业务架构分析

微信业务架构

几点思考：

1. 「游戏」其实是和「看一看」类似，是内容的入口，只是聚焦在了游戏相关内容。

2. 「扫一扫」只能算作功能，不能算作业务。

3. 「语音/视频通话」和「IM」是不同的业务，使用场景有区别。

4. 「红包」虽然牵扯到了钱，但其社交属性远强于支付属性，所以归类到了社交业务。

5. 公众号、视频号、直播、小程序 &小游戏 是底层的内容，看一看、搜一搜、游戏是内容聚合的入口。

学生管理系统架构选型

复杂度分析

1. 高性能方面。管理 1000 个学生这个量级其实很小，高性能方面没有什么复杂度。

2. 高可用。主要是数据高可用。由于所有数据都有外部冗余，所以可以容忍小量的数据丢失。

3. 可扩展。业务需求比较复杂，而且未来存在变化的可能性。

4. 成本 &安全。成本受限。安全性要求一般，大部分都是公开信息，确保权限就好。

备选方案 1

按照子系统划分业务服务器，并且冗余 1 台保证服务可用性。

优点：

1. 高可用

缺点：

1. 成本高

2. 开发难度高

备选方案 2

不划分业务服务器，并且冗余 2 台保证可用性。

优点：

1. 成本低

2. 开发难度低

备选方案 3

不划分业务服务器，并且冗余 1 台保证可用性。

优点：

1. 成本低

2. 开发难度低

缺点：

1. 容错性略低于方案 2

备选方案 4

不划分业务服务器，没有任何冗余。

优点：

1. 成本极低

2. 开发难度低

缺点：

1. 太简单，不符合毕设要求

2. 没有灾备，可用性低

方案取舍

1. 团队的技术水平有限，而且本就人数有限，不适合切分业务。

2. 方案 1 的成本太高，比 2 和 3 高出一个量级。方案 4 的成本最低。

3. 1 的开发周期更长，2 和 3 和 4 一样。

4. 学校不推荐太简单（方案 4）和太复杂（方案 1）的方案。

根据以下三原则分析，最终选择备选方案 3。

合适原则：

1. 符合团队技术水平和人数。

2. 开发成本低。

3. 运维成本低。

简单原则：

1. 不拆分系统，开发、部署、维护简单

演化原则：

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

2. 学校的学生数量相对稳定，无需考虑后期演化