1. 微信的业务架构

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

2.1 业务分析

1. 需要通过公网域名访问。

2. 需要提供域名解析和域名代理服务，将域名解析至应用服务器，使用 nginx 做路由转发，将请求转发至对应的服务。nginx 可以部署在业务服务器，无需单独部署

3. 能够支撑 1000 个学生

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

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

1. 答辩需要根据架构方案打分

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

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

合适原则

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

简单原则

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

演化原则

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

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

2.2 架构设计

2.2.1 方案一

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

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

优点

1. 应用采用单机部署，部署维护方便，横向扩展方便，只需额外添加业务服务器即可

2. 部署架构简单，成本低，

3. MySQL 主备相对简单，增加数据备份避免节点故障导致数据丢失

缺点

2. 单节点业务服务器节点故障时会导致服务完全不可用

3. MySQL 主备虽然部署简单，但还需要考虑数据是否一致

2.2.2 方案二

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

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

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

优点

1. 应用采用多节点部署，保住了服务可用性

2. 横向扩展方便，只需增加业务服务器即可

3. MySQL 主备相对简单，增加数据备份避免节点故障导致数据丢失

缺点

1. 业务使用两个节点部署，会造成资源浪费

2. MySQL 主备虽然部署简单，但还需要考虑数据是否一致

2.2.3 方案三

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

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

优点

1. 多个子系统相对独立，便于后期业务扩展

2. MySQL 主备相对简单，增加数据备份避免节点故障导致数据丢失

缺点

1. 每次都需要单独部署多个子系统，增加部署成本，一次调用可能涉及多个子系统，排查问题不方便

2. MySQL 主备虽然部署简单，但还需要考虑数据是否一致

2.2.4 方案四

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

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

优点

1. 前后端解耦，提供开发效率，便于分工

2. 前端使用 nginx 服务，直接访问静态资源文件，提高访问效率

3. MySQL 主备相对简单，增加数据备份避免节点故障导致数据丢失

缺点：

1. 前端缺乏足够的人员，不利于维护

2. 需要单独提供接口，后期调试比较麻烦，需要前后端一起查问题

3. MySQL 主备虽然部署简单，但还需要考虑数据是否一致

2.3 方案选择

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

不采用其他方案的原因：

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