架构实战营 模块五 作业

概述

1. 设计微博系统中”微博评论“的高性能高可用计算架构。

用户行为建模和性能估算

1. 2020.9 月月活 5.11 亿，日活 2.24 亿（参考《微博 2020 用户发展报告》）

2. 假设平均每天每人发 1 条微博（只考虑文字微博），则微博每天的发送量约为 2.5 亿条

3. 大部分的人（60%）发微博集中在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00

4. 假设平均每条微博被评论 10 次，则评论微博次数为：2.5 亿 * 10 = 25 亿

5. 评论微博时间分布与发微博基本重合，因此微博评论的 TPS 为：25 亿 * 60% / (4*3600) = 100K/s

6. 假设平均每条评论被观看 10 次，因此微博评论的 QPS 为：25 亿 * 10 * 60% / (4*3600) = 1000K/s

高性能计算架构设计

微博评论的核心功能分为发评论与看评论两个部分。

发评论

1. 业务特性分析

2. 发评论重要性不如发微博本身，评论发出后不需要其他用户第一时间就能看到，所以可以采用本地缓存+写缓冲的方式进行缓存处理

3. 架构分析

4. 用户量过亿、TPS 高达 100K，需要使用多级负载均衡架构（DNS->F5->LVS->Nginx->网关)

5. 本地缓存基于客户端本地缓存实现，写缓冲基于服务端 SSD 缓存实现（基于 SSD 实现 Buffer 队列）

6. 架构设计

7. 负载均衡算法选择

8. 与发微博业务类似，写评论所依赖的登录状态一般都是保存在分布式缓存中，因此将请求发送给任意服务器都可以，选择“轮询”或者“随机”算法

9. 业务服务器数量估算

10. 与发微博类似，写评论依赖审核系统、存储系统和缓存系统，由于添加了服务端 SSD 缓存，每个服务器处理能力比发微博高，按照一个服务器（32 核）每秒处理 800 来估算，完成 100K/s 的 TPS，需要 125 台服务器，加上 20%预留量， 预计需要 150 台服务器

看评论

1. 业务特性分析

2. 与看微博类似，看评论也是典型的读场景，且 QPS 高，需要使用缓存架构及负载均衡架构。

3. 架构分析

4. 用户量过亿，需要使用多级负载均衡架构（DNS->F5->LVS->Nginx->网关）

5. QPS 高达 1000K，需要使用多级缓存架构，且需要使用 CDN

6. 架构设计

7. 负载均衡算法选择

8. 与看微博业务类似，将请求发送给任意服务器都可以，选择“轮询”或者“随机”算法

9. 业务服务器数量估算

10. 假设 CDN 能够承载 90%的用户流量，则实际进入系统的请求 QPS 为 1000K/s * 10% = 100K/s。读评论业务逻辑较为简单，单个服务器（32 核）处理能力按照每秒 1000 估算，处理 100K/s 的 QPS，需要 100 台服务器，加上 20%预留量， 预计需要 120 台服务器

整体架构设计

整合微博评论发与看两类核心功能，整体计算架构设计分析如下：

1. 任务分配：基于负载均衡架构，采用多机房部署

2. 任务分解：发评论与看评论的量级差异不大，因此不用将发评论与看评论拆分为不同的服务，使用统一的微博评论服务即可

3. 负载均衡算法：采用随机或轮询算法即可

4. 服务器资源估算：因为读和写公用一个服务，所以单个服务器的整体处理能力要整体低于前文的估算值，这里预估单台服务器（32 核）处理能力为每秒 500，处理 100K 的 TPS+QPS 需要的服务器数量为 200 台，加上 20%的预留量，需要的服务器数量为 240 台

结合上述分析，微博评论整体负载均衡架构如下图所示：

缓存架构如下图所示：