1. 业务背景

设计架构支持用户发微博评论和看评论功能

发评论

• 用户写评论并点击发评论按钮

• 评论发到微博文章评论区

看评论

• 看微博时会显示部分评论

• 用户点击更多评论后，评论区显示更多评论

2. 约束和限制

发微博、看微博功能优先于发评论、看评论

考虑成本，使用合适资源支持评论服务

3. 总体计算架构

3.1 分析评估

3.1.1 性能需求

根据统计数据，2020.9 月月活 5.11 亿，日活 2.24 亿(参考《微博 2020 用户发展报告》)。

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

2.5 亿 * 100 = 250 亿。

假设大部分的人发微博集中在早上 8:00~9:00 点，中午 12:00~13:00，晚上 20:00~22:00，这里总共 4 个小时，这几个时段 60%在看微博。看微博会发评论，时间重合，假设三分之一的人（20%）会发评论，按此估算 TPS 为：

250 亿 * 20% / (4*3600) = 333k/s。

发微博涉及几个关键的处理:内容审核(依赖审核系统)、数据写入存储(依赖存储系统)、数据写入缓存(依赖缓存系统)。写评论需要经过类似步骤，按每个服务器、每秒处理 500 来估算，不依赖缓冲情况下，需要大概 700 台服务器。热点事件可能有大量读请求，也会有更多评论

写评论重要性明显不如发微博，使用大量服务器处理评论是不符合经济原则的。按课程设计发微博有 25 台服务器，假设写评论同样使用 25 台服务器，按 10k/s TPS 计算，与写评论所需要的大约 400k/s TPS 相比，相差 40 倍，需要使用缓冲来处理瞬时峰值。而由于使用缓冲，我们可以增大缓冲而减少发评论服务器，但这意味着用户需要等待更长时间，才能看到评论。

看评论的估算和看微博的一样。根据学习课文内容，大部分人看微博的时间段和发微博的时间段基本重合，因此看微博的平均 QPS 计算如下:

250 亿 * 60% / (4*3600) = 1000K/s。

3.1.2 高可用

需要使用限流、熔断、降级等方式满足高可用。发评论没有发微博重要，应该优先保证发微博服务，不应随意增加发评论服务器数目。

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

仍然使用发微博的 4 级负载均衡架构。在此基础上，增加微博评论服务器，支持发评论和看评论功能。

使用看微博的 5 级缓存架构，在此基础上加入看评论服务。

3.2.1 非热点事件高性能设计

拆分微博评论到独立服务，因为评论功能与发微博、读微博不一样，分解为独立服务更易于扩展。

发评论的时效性不高，可以先写入缓冲再处理，即使处理速度低于一般发微博服务，仍可接收。发评论服务器数量可以少于发微博服务器，便于节省成本。

看微博时会同时看评论，“假设 CDN 能够承载 90%的用户流量，那么剩下 10%的读微博的请求进入系统，则请求 QPS 为 1000K/s * 10% = 100K/s，由于读取微博的处理逻辑比较简单，主要是读缓存系统，因此假设单台业务服务器处理能力是 1000/s，则机器数量为 100 台，按照 20%的预留量，最终机器数量为 120 台”。看评论服务器可以使用相同的估算，也是 120 台服务器。

由于看评论需求不同，我们可加上特定优化。

• 在不定时刷新情况下使用缓冲，给被动缓存加上失效时间，失效后重新从数据库读取缓存。多个缓存设置不同失效时间。

• 由于评论不断增加，可以定时刷新，也可以采用主动更新策略，让后台程序更新评论。

• 如果看评论请求实在无法处理，可直接丢弃，用户再次请求时处理就可以。

3.2.2 热点事件高性能设计

尝试预测热点事件，当同一微博阅读访问量迅速增大时，可采取以下手段

对于写评论

• 增大评论队列长度

• 增加评论服务器数量

对于读评论

• 增加多个缓存服务器，并设置不同失效时间

• 无法处理就直接丢弃

3.2.3 热点事件高可用设计

当热点事件预测失败时， 需要以下方法保持评论功能可用

• 限流：控制评论数目。客户端设置时钟，倒计时完成后才可再发评论，并解释在规定时间内只允许发有限评论。也可以在服务网关中直接拒绝评论请求。当接收微博评论数目大于应用服务队列时，直接丢弃评论，并提示用户无法评论失败。

• 熔断：可暂时关闭部分用户评论，如果用户在短时间内发过多评论，就暂时提示用户在一段时间内无法再发评论。

• 降级：观察热点，当对系统负载过大时，可人工暂时关闭评论功能。

4. 详细设计

4.1 核心功能

4.1.1 发评论

经过各级负载均衡，写评论请求到达写评论服务器，服务使用 Reactor 模式，处理完返回成功客户端。

• 只要队列不满，写入写评论请求后，即可返回成功到客户端

• 队列已满的话，丢弃写评论请求，返回失败到客户端

4.1.2 读评论

大部分评论从缓存读出，只有当缓存不命中再从看评论服务和数据库中读取

4.2 关键设计

无

4.3 设计规范

无

5. 质量设计

记录连接时间，根据连接时间评估性能，做负载均衡。

6. 演进规划

无