架构训练营第 1 期 模块五作业

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

【作业要求】

基于模块 5 第 6 课的微博实战案例，分析“微博评论”这个核心场景的业务特性，然后设计其高性能高可用计算架构，包括但不限于如下内容:

1. 计算性能预估(不需要考虑存储性能);

2. 非热点事件时的高性能计算架构，需要考虑是否要拆分独立的服务;

3. 热点事件时的高可用计算架构。

【提示】

1. 分析方法对照“看微博”和“发微博”的案例。

微博评论业务场景性能估算

背景数据

（以下参考数据摘自模块五第 6 课）

用户量

• 2020.9 月月活 5.11 亿，日活 2.24 亿 (参考《微博 2020 用户发展报告》)

发微博

• 假设平均每天每人发 1 条微博(只考虑文字微博)，则微博每天的发送量约为 2.5 亿条。

• 大部分的人发微博集中在早上 8:00~9:00 点，中午 12:00~13:00，晚上 20:00~22:00，假设这几个时间段发微博总量占比为 60%，则这 4 个小时的平均发微博的 TPS 计算如下:2.5 亿 * 60% / (4 * 3600) ≈ 10 K/s。

看微博

• 由于绝大部分微博用户看微博的对象是大 V 和明星，因此我们假设平均一条微博观看人数有 100 次，则观看微博的次数为: 2.5 亿 * 100 = 250 亿。

• 大部分人看微博的时间段和发微博的时间段基本重合，因此看微博的平均 QPS 计算如下: 250 亿 * 60% / (4*3600) = 1000K/s。

关键行为

发评论

• 每条微博的评论数长尾效应明显，绝大多数微博是没有评论的。假设每条微博有 5 条评论，或每个活跃用户每天发表 5 条评论，均可得每天评论的产生数量为 12.5 亿条。

• 发评论和发微博的人时间分布是高度重合的，故可以使用类似的计算公式得出高峰时间段的 TPS 为 50K/s。

看评论

• 绝大多数的刷微博的过程是不会点入评论页，假设平均每条微博有 10%的读者查看评论并读完全部评论，则每条评论被看到的次数为 10 次。则每天看评论的请求次数为 125 亿。

• 实际情况由于评论有分页，查看评论并不等于读取全部评论。这里只做一个平均的假设。

• 使用与发评论一样的时间段计算，则 QPS 为 500K/s

• 需要注意的是每条微博的评论数是跟随微博内容一起显示的，故它的 QPS 与看微博一样为 1000K/s

点赞

• 具体可分为点赞微博与点赞评论，系统设计时也可以算作评论的一部分，但暂时不在本次作业中考虑

微博评论高性能计算架构设计

发评论

业务特性分析

发评论是个典型的写操作，不能使用缓存，但是由于评论对于时效性的要求没有微博本身高，因此可以使用写缓冲。可以使用负载均衡。

架构分析

用户量过亿，应该要用多级负载均衡架构，覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡。

架构设计

1. 负载均衡算法选择。发评论的时候依赖登录状态，登录状态一般都是保存在分布式缓存中的，因此发评论的时候，将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。

2. 业务服务器数量估算。发评论涉及几个关键的处理:内容审核(依赖审核系统)、数据写入存储(依赖存储系统)、数据写入缓存(依赖缓存系统)，因此按照一个服务每秒处理 500 来估算，完成 50K/s 的 TPS，需要 100 台服务器，加上一定的预留量，120 台服务器差不多了。

看评论

业务特性分析

看评论是一个典型的读场景，由于评论发了后不能修改，因此非常适合用缓存架构，同时由于请求量很大，负载均衡架构也需要。

架构分析

1. 用户量过亿，应该要用多级负载均衡架构;

2. 请求量达到 125 亿，应该要用多级缓存架构，尤其是 CDN 缓存。

架构设计

1. 负载均衡算法选择。游客（非登陆用户）都可以直接看评论，因此将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。

2. 业务服务器数量估算。假设 CDN 能够承载 90%的用户流量，那么剩下 10%的读评论的请求进入系统，则请求 QPS 为 500K/s * 10% = 50K/s，由于读取评论的处理逻辑比较简单，主要是读缓存系统，因此假设单台业务服务器处理能力是 1000/s，则机器数量为 50 台，按照 20%的预留量，最终机器数量为 60 台。

3. 与微博类似，并非所有的评论需要上 CDN。但是热门微博的热门评论页一定要上 CDN，并进行定期（如每半小时）更新。如此可以在保证 CDN 的命中率的同时提供相对较实时的用户体验。

整体架构设计

评论业务需要如微博业务类似的进行多机房部署，同时发评论和看评论的服务要拆分并部署到不同的服务器上。二者的业务特点以及性能要求差别很大，且拆分服务有利于在紧急情况下的服务降级和熔断操作。

微博评论的多级负载均衡架构

微博评论的多级缓存架构

微博评论高可用计算架构设计

此节仅讨论热点事件发生时的高可用设计

业务特性分析

热点事件发生后

1. 评论都会发在热点事情微博或其影响力较大的某一部分转发下。但是对于系统来讲并无差异，即短时间内出现了大量评论。

2. 看评论的请求会集中在热点事件的微博的热点评论中。

架构分析

1. 由于用户发完评论立刻被别人看见的需求不高，可使用写缓冲来应对短时内的大量流量。这样可以保证热点事件时数据不丢失。

2. 与看微博类似，当前缓存架构中的多副本缓存应对热点的能力应当足以应付热点事件。

架构示意图