1. 微信的业务架构

2. “学生管理系统”毕业架构设计

2.1 业务分析

大部分时候业务不会有高并发的问题，所以不需要考虑并发问题，单节点服务器即可满足日常需要。

需要保证业务数据不丢，至少要有备份可以后期恢复

需要考虑服务的容错性，不推荐使用单节点部署，会导致服务可用性较差

结合复杂度设计三原则分析

合适原则

三人都会Java，采用JavaWeb开发，方便代码维护，开发成本低应用不需要拆分，运维部署方便

简单原则

由于只有3个人开发，服务不需要拆分过细

演化原则

使用人数只有1000人，并且学校学生数量变化不大，架构可以使用多年

用于毕业设计，属于一次性交付，不需要考虑后期演化

2.2 架构设计

2.2.1 方案一

使用单节点业务服务器，整个应用为JavaWeb单体应用

MySQL采用单机读写，使用主备保证数据不丢失

优点

缺点

2.2.2 方案二

2 业务服务器 2数据库服务器

使用多节点业务服务器，整个应用为JavaWeb单体应用，增加一个节点作为应用容错

MySQL采用单机读写，使用主备保证数据不丢失

优点

缺点

2.2.3 方案三

业务拆分多个子系统部署，子系统之间通过接口的形式调用

MySQL采用单机读写，使用主备保证数据不丢失

优点

缺点

2.2.4 方案四

前后端分离，有一人是PHP高手可以主要负责前端页面的交互逻辑，剩余两人负责后端接口开发。

MySQL采用单机读写，使用主备保证数据不丢失

优点

缺点：

2.3 方案选择

最终选择方案二为最终方案，理由：方案二采用应用多节点和数据库主备，提高了服务容错能力，同时部署和横向扩展都相对方便，架构不复杂，满足毕业设计

不采用其他方案的原因：

方案一：虽然满足业务的开发需要，但是业务节点异常时，整个服务都不可用，架构过于简单方案三、方案四：对业务进行了拆分，导致外部复杂度提高，需要考虑服务与服务之间调用的异常，而且开发只有三个人，不利于维护