【架构设计模块五】：设计微博系统中”微博评论“的高性能高可用计算架构

计算性能预估

估算步骤

参考【看微博】 & 【发微博】中的数据：

1. 【用户量】

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

3. 【关键行为】

4. 发微博

5. 看微博

6. 评论微博

7. 看微博评论

用户行为建模和性能估算

看微博评论

1. 前面假设平均一条微博的观看人数有 100 次，基于此我们假设看 5 条微博后会看一次评论，那评论次数为： 2.5 亿 * 100 / 5 = 50 亿

2. 大部分人看微博评论和看微博的时间也基本重合，因此看微博评论的平均 QPS 计算如下： 50 亿 * 60% / (4*3600) = 200K/s

评论微博

1. 前面假设平均一条微博的观看人数有 100 次，看 5 条微博看一次评论——基于此我们假设看 5 个微博评论后评论一次，那评论次数为： 2.5 亿 * 100 / 5 / 5 = 10 亿

2. 大部分人评论微博和看微博的时间也基本重合，因此看微博的平均 QPS 计算如下： 10 亿 * 60% / (4*3600) = 40K/s

高性能计算架构设计

服务拆分：

1. 评论和微博虽然关联性很强，但功能涉及属于主体微博的附属品，故而单独拆分评论服务便于演进；同时评论和发微博不一样，评论可以通过排队来解决

2. 其次，评论微博及看微博评论，也推荐拆分服务，两者的压力完全不一样，拆分更利于扩展

评论微博

1. 【业务特性分析】：评论微博是一个典型的写操作，因此不能用缓存，但可以用负载均衡，使用消息队列降低压力

2. 【架构分析】：用户量过亿，应该要用多级负载均衡架构，覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡

3. 【架构设计】：

4. 负载均衡算法选择：虽然评论微博跟指定微博有关，但考虑到评论时不会使用缓存，故而将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法

5. 业务服务器数量估算：评论微博涉及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统）。前面说到，评论可以按照排队来解决，故而完全可以按照一个服务每秒处理 1000 来估算，完成 40K/s 的 TPS，故而需要 40 台服务器，加上预留量，50 台服务器差不多

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

评论微博的多级缓存架构

写场景，不考虑缓存

看微博评论

1. 【业务特性分析】：看微博评论是一个典型的读操作，虽然有持续的评论，但短时间内的评论没有看到完全可以接受，可以用负载均衡

2. 【架构分析】：用户量过亿，应该要用多级负载均衡架构，覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡

3. 【架构设计】：

4. 负载均衡算法选择：微博评论放在分布式缓存中，因此将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法

5. 业务服务器数量估算：虽然读取微博评论的处理逻辑稍微有点复杂，需要组合评论结构，但还是写少的场景，故假设单台业务服务器处理能力是 800/s，则机器数量为 250 台，加上预留量，300 台服务器差不多

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

看微博的多级缓存架构

1. 看微博这里首先不考虑 CDN 缓存，主要是由于评论会不断增加，会导致 CDN 中的内容经常性失效；而仅缓存单个评论，会导致整体请求过多，性能提升不大反而有点复杂

2. 其次不考虑 Web 容器里的缓存，也是由于评论会不断增加，Web 容器中的缓存很难做清除策略

故而保留 APP 及 浏览器的缓存、进程内缓存及分布式缓存——而本地缓存更多的是在网络较差时，能有评论看

整体架构设计

1. 任务分配：双机房，三机房

2. 任务分解：评论微博和看微博评论拆分服务

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

主要做了服务拆解及机器资源累加

微博评论的多级缓存整体架构

实际就是看微博评论的缓存架构，因为评论时无需使用缓存

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

微博热点事件用户行为建模和性能估算

热点事件指某个大 V 或者明星爆料或者官宣，虽然只有一两条微博，但引起大量用户在短时间内访问并评论，给系统造成很大压力：

1. 【评论微博】：很难预估，和事件的影响力和影响范围有关

2. 【看微博评论】：很难预估，和事件的影响力和影响范围有关

3. 【业务特性分析】

4. 评论微博：一般原微博的评论会特别多，衍生或转发的微博影响力会低于原微博

5. 看微博评论：热点事件发生后，绝大部分请求都落在了导致热点事件发生的那一条微博对应的评论上

6. 【架构分析】：

7. 评论微博：还是按照之前的评论逻辑，直接按排队处理即可，这里影响不是很大——服务按需消费即可

8. 看微博评论：这里也是类似的逻辑——评估过期可按照异步通知的方式去变更，否则服务内的缓存可一直使用，这样能尽量减少对缓存的压力

和发微博、转发微博、看微博的场景不同，在评论这个场景，引入消息队列来为我们的服务来减负——评论的场景和微博略有不同，能容忍不实时的情况