架构训练营模块五作业

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

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

1）计算性能预估（不需要考虑存储性能）

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

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

【提示】分析方法对照“看微博”和“发微博”的案例。

【计算性能预估】

1. 2020 年 9 月日活 2.24 亿，发微博评论的频率应该介于发微博和看微博之间，我们假设平均一条微博会有 10 条评论，则每天发评论的总次数为 2.5 亿 x10 = 25 亿；

2. 一般用户并不会刷到每条微博都会去看评论，因此看评论的请求量应该是大于发评论而小于看微博，假设一条微博的查看评论请求为 50，则每天看评论的总次数为 2.5 亿 x50 = 125 亿；

3. 大部分人发评论和看评论的时间段分布与发微博时间段基本重合，即高峰时段的四个小时占总量的 60%，则：

发评论的 TPS 峰值计算：25 亿 x 60% / (4x3600) = 100K/s

看评论的 QPS 峰值计算：125 亿 x 60% / (4x3600) = 500K/s

【非热点事件高性能计算架构】

【发评论】

1. 发评论相比发微博来说业务上的时效要求低一些，不需要立即让所有人都看到，因此可以采用客户端 APP 缓存+服务端写缓冲的方式。另外由于请求量较大，需要使用负载均衡。

2. 用户量过亿，采用多级负载均衡架构，覆盖 DNS->F5->Nginx->网关的多级负载均衡

3. 负载均衡算法选择，评论微博需要登录，登录信息一般保存在分布式缓存中，因此评论请求发送给任意服务器都可以，这里选择”轮询“或者”随机“算法。

4. 业务服务器数量估算：服务端采用消息队列写缓冲的形式，单笔写请求变成异步，耗时约 30ms，单台 32 核服务器 TPS 约为 1000。按前述业务估计 100K/s 需要 100 台服务器，加上 20%冗余，约需要 120 台服务器。

服务端采用消息队列写缓冲的方式：

【看评论】

1. 看评论也是典型的读场景，适合用缓存架构，由于每天请求量达到 125 亿，需要使用多级缓存架构，尤其是 CDN 缓存。

2. 用户量过亿，采用多级负载均衡架构，看评论不需要登录，因此请求发给任意服务器都可以，可以选择”轮询“或者”随机“算法。

3. 业务服务器数量估算：假设 CDN 承载 90%流量，则服务器需处理的读 QPS 为 500K/sx10%=50K/s,读评论的处理逻辑较简单，主要是读缓存系统，因此可机器数量为 50 台，取 20%冗余，最终机器数量为 60 台。

看评论的多级缓存架构：

【整体架构设计】

由于用户体量较大，为了便于业务运维（例如故障服务降级、服务隔离等），将发评论和看评论拆分不同的服务。

评论业务的负载均衡整体架构：

评论业务的多级缓存整体架构：

【热点事件的高可用计算架构】

发评论

热点事件的微博评论相比微博自身时效性要求可以低一些，因此可以考虑对热点事件微博的评论进行限流，最好是采用漏桶算法。原有高性能架构设计中采用了消息队列写缓冲的方式，同时也达到了限流的目的。

看评论

热点事件评论主要是缓存热点问题，可以考虑多副本缓存，原有缓存架构已经采用应用内缓存，因此已经实现了多副本缓存。