架构实战 1 微信业务架构图 - 学生管理系统技术选型

1、微信业务架构图

说明：

• 主要包括了账号管理、用户管理、社交、公众号、小程序、视频、搜索、评论、广告这几个大的业务模块

• 大的业务模块嵌套了小的业务模块，小的业务模块虽然画的小，但不代表不重要

2、学生管理系统技术选型

复杂度考虑

高性能

• 该系统支撑的学生人数为 1000 人，后期人数应该也不会发生太大变化，QPS 和 TPS 都不会太高，所以对性能的要求不是太高

高可用

• 对任何管理系统来说，数据经常丢失会造成很大困扰，用户体验会非常不好，所以高可用性是必须的，包括消息的写入、存储和读取。

• 鉴于当前经济条件一般，考虑在一台机器上实现数据库的主备方案

可扩展

• 业务需求可能会发生不断变化、不断拓展，所以必须保证可扩展性

成本和安全

• 作为学生毕业设计，投入成本不可能太高，考虑业务服务器和数据库都各用一台机器实现

• 只给学生使用，安全性方面不做重点考虑

总结

• 总结，该系统需要保证数据的高可用，并且保证业务的可扩展性

根据以上分析，设计如下三种方案

方案 1

说明：

1. Nginx 是一个开源且高性能、可靠的 Http Web 服务、代理服务。单机环境下参考服务器配置，并发连接数在 7000+ 到 8000 左右，集群模式 20000+，所以完全满足要求。

2. 有一名成员非常熟悉 Php，考虑使用 Php 进行前端数据渲染，可以进行快速的开发和修改，从而保证 Java 侧更专注于业务逻辑的实现

3. 后台的业务逻辑可能比较复杂，用 Java 实现

方案 2

说明：

1. 总体和方案 1 无差别

2. 因为只有一名成员熟悉 Php，考虑后期业务的可扩展性和维护性，应该保证语言栈的统一，统一使用 Java 进行开发

方案 3

说明：

1. 考虑到 Mysql 的使用有一定的门槛和难度，所以选用 MongoDB 进行开发，相对简单、高效一些

最终选型

选方案 2，理由如下：

1. 虽然有一名成员熟悉 Php，但是为了保证开发周期和后期的可维护性，要使用统一的语言栈，所以排除了方案一

2. 作为技术人员，考虑到对技术的追求，也考虑到后期的可扩展性，所以排除较简单的方案三

3. 这样也符合团队当前的技术水平，后期维护起来也比较容易，同时保证了合适原则和简单原则

4. 后期人数不会发生太大变化，无需考虑太多后期演化