1. 微信业务架构图

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

2.1 系统复杂度分析

• 高可用

虽然要求系统真正可运行，但系统存储的数据应该不是真实数据，通常是通过手工录入或批量导入的。如果少量数据丢失或服务一段时间不可用是可以接受的。

• 高性能

要求能够支撑 1000 个学生，对系统的性能要求不高。

• 扩展性

系统一次性开发完成后，不会再有新的需求迭代，但也应当适度考虑系统的可扩展性。

• 安全性

系统不涉及金融证券等等领域，只是学生的基本信息，而且用于毕设，通常为伪造的数据。但是需要考虑系统是能够通过公网访问的，适度考虑网络安全要求。

• 成本

开发团队成员的经济条件都很一般，开发成本十分有限。

2.2 备选架构设计

• 备选架构 1

单体应用架构：数据库+应用服务器+Nginx

• 备选架构 2

拆分多个子系统：数据库+学生子系统、课程子系统、管理子系统+Nginx

• 备选架构 3

多个应用系统系统：数据库+多个完整系统（学生子系统、课程子系统、管理子系统）+Nginx

• 备选架构 4

多个应用系统：数据库+多个完整系统+DNS

2.3 架构取舍

综合考虑最终选择架构 2，原因如下：

• 架构 1 分析

• 合适原则

• 非常不利于团队协作开发

• 系统部署和运维成本低

• 简单原则

• 开发和运维部署简单

• 演化原则

• 架构的扩展性很差

• 架构 2 分析

• 合适原则

• 利于团队的协作开发，团队成员都会使用 Java，虽然有一个 PHP 高手，但为了节约成本，开发语言建议仍然使用 Java 进行开发

• 简单原则

• 每个成员负责一个独立的子系统开发，部署和运维也是独立的，便于维护

• 演化原则

• 系统为一次性开发系统，但是系统架构已经具备了微服务架构的雏形，架构具备一定的复杂性，利于后期的扩展

• 架构 3 分析

• 合适原则

• 符合团队的技术水平和积累

• 开发成本低

• 系统运维成本低

• 简单原则

• 系统不进行拆分，部署维护简单

• 但系统整体架构过于简单，答辩要求系统架构具备一定复杂性和技术难度

• 演化原则

• 一次性交付，无需考虑演化

• 架构 4 分析

• 合适原则

• 同上

• 但是学校并不会直接提供 DNS，需要额外花钱购买，考虑学生的条件普通，成本有限

• 简单原则

• 同上

• 演化原则

• 同上