架构训练营作业 5- 微博评论的高性能高可用计算架构

一、作业要求

二、设计过程分析

1.用户量预估

• 微博月活跃用户达到 5.82 亿，同比净增约 1600 万, 日活跃用户达到 2.52 亿，同比净增 700 万。

• 行为分类：读微博、写微博

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

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

（2）对于热点事件来说，会引起大量用户在短时间内访问，给系统造成很大的压力。此时看微博的请求会远大于写微博和读微博的请求，对于读微博的请求可以使用 CDN 满足 90%的请求，剩下的 10%可以考虑使用缓存集群满足。对于写评论由于不属于核心业务，可以考虑在大流量时进行限流处理。

3、评论微博的业务分析

• 业务特性分析

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

阅读微博作为请求量大的读操作，同时伴随文字 &图片 &视频，建议采用 CDN+缓存集群的方式。

• 架构分析

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

• 架构设计

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

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

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