当前位置：网站首页>微博评论架构设计

微博评论架构设计

2022-06-29 10:27:00 【InfoQ】

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台服务器。

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