架构实战营 - 模块 01 作业

1 - 微信业务架构

2 - 学生管理系统要求

设计要求

• 要求可以通过公网域名访问。

• 要求至少 3 人合作完成。

• 能够支撑管理 1000 个学生。

• 根据架构方案来进行打分，不推荐太简单和太复杂的方案。

团队情况

• 一共三位成员，大家都会 Java，但是有一个 PHP 高手。

• 大家经济条件一般。

3 - 学生管理系统方案

需求分析

• 公网域名：需要学校已有 DNS，或者通过云服务、域名注册提供商来注册。

• 对于支撑管理 1000 个学生，做出以下初略的量化计算：

  假设正常情况下，此系统每天处理 1 万次页面请求。（学生登录，并查看几个课程、考试页面）

  假设一天中有 80% 的请求发生在 5% 的时间中。（学生应该不会时时刻刻登录在系统里）

  那么可以得出： (80% x 10000) / (5% x 24 小时 x 3600 秒每小时) = 2 次页面请求每秒。

  考虑极端情况，例如开学选课、期末查成绩等等，服务器如果能并发 2 次 x 5 = 10 次页面请求每秒。

• 鉴于支撑的学生数量不多，简单的 "客户端-服务端-数据库" 架构应该能满足要求。

• 据此可以提出几个方案。

方案一

• 使用单体服务器，并把业务拆分为不同的代码组件。

• 因为是代码组件，所以用统一编程语言比较可行且高效。

• 单体服务器可以同时返回应用页面：

• 简单的 HTML+CSS+JavaScript、或者用 Java Server Pages

• 以及提供后续的 Web API 服务

• 数据库采用 MongoDB 最基础的 3-Node 集群。数据库建议采用官方云服务。

  如果选择 MongoDB 官方云服务 Atlas 的话，基础集群 512MB 以内的存储空间都是免费的。

  MongoDB 单个文档最大 size 限制为 16MB，而 16MB 的空间可以存下莎士比亚全集，所以 512MB 的存储空间可以坚持一段时间再升级。

  MongoDB 灵活的 Schemaless 特性，可以在细节需求不明朗的情况下快速开发和迭代。

  最基础的 3-Node 集群也提供自动分片和冗余备份功能，可以把更多的时间放在业务开发上面。

方案二

• 用微服务集群，根据业务拆分为不同的微服务。

• 因为是微服务，所以不同的编程语言也可以，只要定义好接口。

• 需要注意的是：

  如果使用后端储存的 Session 进行身份验证，则其他微服务可能会重度依赖权限管理服务。

  如果使用前端储存的 Token 进行身份验证，则各个微服务可以独立计算签名完成验证。

  目前觉得前端 Token 的方法较好，因为本系统内用户身份变动的可能性和频率不高。

• 数据库抽象层：可以通过 SDK 或者服务的方式，根据语言选择。

• 使用 MySQL 主从架构，数据库建议采用云服务。

  提高读性能的同时获得一定的备份容灾能力，从而提高可用性。

  一般云服务的数据库服务都有一定的免费额度。

  以 AWS 为例，20GB 的普通 SSD 储存 + 20GB 的备份。

  虽然有备份，但是默认不提供主从架构，这一部分可能需要额外开销。

方案三

• 与方案二类似：把 MySQL 的主从架构换成单机，增加一个缓存层，同时数据库抽象层做相应的调整。

• 因为数据库层的代码中可能需要自己实现只读缓存的抽象，所以回归统一编程语言。

• 另外由于数据库没有主从架构，省下的开销可以用于 Redis 缓存。

• 同样的，数据库和缓存在目前阶段都建议使用云服务。

• 因为有缓存层，如果使用场景中读的比重大，则能有更好的性能。

方案对比

综上对比，方案一应该是在目前需求下的最好方案：

• 架构简单明了。

• MongoDB 的存储模式应该比较适用。

  如果具体的细节要求涉及很多关系模型以及事务的保障则 MongoDB 会暴露出缺点。

• 但目前看来关系模型简单、对于事务的需求不重。

• 统一编程语言、单服务器、开发效率高。

• 开销方面基本上云服务的 Free Tier 即可搞定。