从零学架构（六）

学生管理云平台系统架构设计

需求背景

你们是一家创业公司，公司老板具备丰富的高校人脉资源，老板看到各个高校都在重复建设各自的学生管理系统，建设周期长，功能不完善，老板认为做一个学生管理云平台，既能够减少高校这方面的投入，又可以让高校也“上云”。全中国有 3000 多所高校，这是一个很大的市场。

功能需求

和外包学生管理系统一样

平台需求

1. 云平台要具备高可用、高性能；
2. 云平台要能够隔离各个高校，避免互相影响。

面向复杂度架构设计

复杂度分析

1. 高性能？一个学校一般也就几万学生，3000多所高校，用户量5w * 3000 = 1.5亿，亿级。需要高性能。
2. 高可用？3000多高校，一旦宕机影响太广。为减少相互影响，需要分区、分机房部署来保证高可用。
3. 可扩展？整体业务复杂度比较高，且高校间肯定有各种不一样的定制需求。需要可扩展。
4. 成本？老板有丰富的高校人脉资源，有钱又舍得投入，不是问题。
5. 安全性？学生管理系统里面都是学生的一些公开信息，不涉及什么隐私、金钱等，安全性要求不高。
6. 其它？各高校之间数据不能相互影响，数据隔离必须保证。

设计备选方案

方案1

1. 服务不隔离
2. 数据隔离，每个学校建立一个独立的数据库
3. MySQL主备复制+每日备份保证数据安全

方案2

1. docker做服务隔离
2. 数据隔离，每个学校建立一个独立的数据库
3. MySQL主备复制+每日备份保证数据安全

方案3

1. 服务不隔离
2. 数据隔离，每个学校建立一个独立的数据库
3. 双机房部署

方案4

1. docker做服务隔离
2. 数据隔离，每个学校建立一个独立的数据库
3. 双机房部署

判断维度

业务

1. 业务当前量级
2. 业务发展速度
3. 业务发展形态

团队

1. 团队的规模
2. 团队能力水平
3. 投入的资源

技术

1. 已有的技术体系
2. 当前技术能力
3. 技术成熟度

根据上面三个维度分析判断，最终选择方案1

分析

合适原则

1. 符合团队技术水平积累
2. 开发成本低
3. 运维成本低

简单原则

1. 服务不隔离，只做数据隔离，单机房部署，开发、运维都相对简单

演化原则

1. 不可能一下子接下3000多个高校，先满足几个或者十几个学校的需求，系统短时间内完全够用，后续再重构
2. 创业公司，先用单机房架构方案，快速开发上线。双机房成本太高、架构也更为复杂，不要一步到位。

输出4R架构文档交付开发实现