「微博评论」高性能高可用计算架构设计

1. 前言

思考“微博评论”的场景下，如何来设计高性能高可用的计算架构设计。

2. 背景介绍

1.1 业务背景

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

1.2 业务场景

解释业务的服务场景和商业价值。

3. 约束和限制

1. 只单独讨论 评论微博的业务场景

2. 只讨论计算架构设计（先不考虑存储架构的设计）

3. 考虑是否出现事件下的高可用计算架构

4. 总体架构

4.1 架构分析

看微博（原分析）

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

这里的分析不太准确，大部分人关注的是大 V 明星或机构组织的微博，看的的微博也是他们的，每天产生的微博在 2.5 亿（假设一人一天一条微博），但是看的微博也是不一定是当天的。

看微博（新版）

在用户使用微博的场景，刷微博，一般是服务器返回几十条的一个列表给客户端，这样应该是一次请求。平均一个用户一天刷 20 次（现在应该没那么多人成天刷了），这样看微博的请求量大概在 2.5 亿 * 20 = 50 亿。

评论微博

评论微博的意愿应该没那么高，假设 1 / 100 的概率回去评论，那么评论微博的请求量 2.5 亿 * 20 * 0.01 = 0.5 亿。

非热点场景下是否需要拆分服务

不需要拆分单独的服务，评论服务，发微博服务，对于微博实体来说就是一种关联的属性。 理论上来说评论微博

的量级要远小于发微博的量级，共用一套服务方便维护和部署。 当然存储这块可以做分库，方便后期的扩展。

热点场景下是否需要拆分服务

热点场景下，会出现大量的评论请求，集中达到某几条微博上面。如果放在同一个服务里面，评论压力过大反而会

影响到正常的发微博的业务。 所以是拆分会好一点。

如何在同一个架构下面考虑热点和非热点的场景呢？

可以单独部署一个备用集群，当热点流量打入的时候，在网关集群那里分流。 把一部分峰值的流量分流到备用集群。如果评论允许存在一定的延时的场景下，可以 加一个限流桶， 异步处理评论的请求，把峰值流量进行消峰。

客户端本地也可以做一些缓存，比如用一个本地队列来保存评论信息，后续再统一请求到服务器。（本地显示可以先用客户端的缓存数据）。

架构设计图：