架构实战营－模块五作业

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

【作业要求】基于模块 5 第 6 课的微博实战案例，分析“微博评论”这个核心场景的业务特性，然后设计其高性能高可用计算架构，包括但不限于如下内容：1）计算性能预估（不需要考虑存储性能）2）非热点事件时的高性能计算架构，需要考虑是否要拆分独立的服务 3）热点事件时的高可用计算架构

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

设计分析过程

1、用户量预估

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

• 关键行为：评论微博

2、用户行为建模和性能估算

（1）考虑到微博是一个看得多评论少的业务，假设平均每天每人评论 1 条微博（只考虑文字微博），则微博每天的评论量约为 2.5 亿条。大部分的人评论微博主要集中在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00，假设这几个时间段评论微博总量占比为 60%，则这 4 个小时的平均评论微博的 TPS 计算如下：2.5 亿* 60%/(4* 3600)≈ 10K/s

（2）对于热点事件来说，会引起大量用户在短时间内访问，给系统造成很大的压力。但是用户看微博的行为要多于用户评论微博的行为，至于会有多少无法预估。微博的评论重要性和影响力不如原微博本身，可以考虑对“评论微博”限流，由于评论不是核心业务，因此可以丢弃请求，考虑用“令牌桶算法”。

3、评论微博的业务分析

• 业务特性分析

评论微博是一个典型 的写操作，因此不能使用缓存，可以用负载均衡。

• 架构分析

用户量过亿，应该要用多级负载均衡，覆盖 DNS->F5->Nginx->网关的多级负载均衡。

• 架构设计

（1）负载均衡算法选择：评论微博的时候依赖登录状态，登录状态一般都是保存在分布式缓存中的，因此评论微博的时候，将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。

（2）业务服务器数量估算：评论微博涉及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），因此按照一个服务每秒处理 500 来估算，完成 10K/s 的 TPS，需要 20 台服务器，加上一定的预留量，25 台服务器差不多了。

（3）微博评论系统相对于 看微博和发微博 不是核心业务，因此不能因为它影响核心业务，所以需要将其独立出来，单独成为一个服务。审核系统可以使用发微博时的审核系统。

最终架构图：