微信业务架构 & 学生管理系统架构

一、微信业务架构

从大类上分为社交业务、互联网业务、支付金融业务、用户 &基础业务。

社交是核星，是微信的基础盘；互联网和支付是卫星，丰富了微信的社交场景和带来增值服务；而用户、系统基础则作为支撑域

二、学生管理系统

备选方案一

方案一是从以下几方面考虑：

1. 系统只要支持 1000 左右的用户数量，同时参与人数只有 3 人，单体应用能满足需求，考虑用单体架构

2. 费用有限，考虑用开源的方案，数据库用 MySQL，负载均衡用 Nginx

3. 这是一个真正可运行的系统，所以数据的可靠性需要保障，数据采用 MySQL 主备复制，保障可靠

4. 考虑到可用性，此方案建议应用层面部署双实例，保证一定的可用性，如果费用不足则只能部署单实例

优点：

1. 系统简单，维护成本低

2. 数据可靠性高，服务可用性也有保障

缺点：

1. 因为只有单体应用，PHP 同学可能无法完全发挥作用

备选方案二

方案二是从以下几个方面考虑：

1. 因为团队内有成员是 PHP 高手，可以考虑进行服务拆分，采用微服务架构，部分服务使用 PHP 实现

2. 因为服务化后治理成本较高，所以本方案只拆出了两个服务，学生、课程、权限子系统放在一个服务中采用 Java 实现，考试放在另外一个服务中使用 PHP 实现

3. 数据库同备选方案一，采用在主备架构，保障可靠性

4. 应用层面根据经费来定，经费足够则每个服务双实例，否则则单实例

优点：

1. 充分利用了团队内的 PHP 高手

2. 服务拆分后更加解耦，有一定的隔离性，故障域更小

缺点：

1. 采用了微服务架构，系统复杂度上升

2. 维护成本、费用相比方案一会高

备选方案三

方案三是从以下几个方面考虑：

1. 此方案还是充分利用团队内有 PHP 高手的情况，但是并不是纵向拆分，而是横向拆分。PHP 利用其优势负责 web 层，Java 负责业务逻辑和数据库交互

2. 数据库同备选方案一，采用在主备架构，保障可靠性

3.应用层面根据经费来定，经费足够则每个服务双实例，否则则单实例

优点：

1.充分利用了团队内的 PHP 高手

2.相比方案二要稍微简单点，没有业务逻辑上服务调用，PHP 部分也更能发挥其优势

缺点：

1.分层部署后，复杂度上升

2.维护成本、费用相比方案一会高

最终方案选择

综合来看，方案一比较适合毕设的要求。

因为系统简单，容量、规模要求不高，使用单体架构足够了；其次开发人员较少，经费有限，方案一也是维护成本最低的；开发人员中虽然有 PHP 高手，但是保持系统的一致性也很有必要，所以使用 Java 技术栈会比较统一，也不会为以后的升级埋坑；架构是演进的，后续规模、体量上来后可以考虑演进微服务架构，容器化部署等。

所以综合来看，方案一更合适当前场景。