架构实战营模块五作业

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

【作业要求】

基于模块 5 第 6 课的微博实战案例，分析“微博评论”这个核心场景的业务特性，然后设计其

高性能高可用计算架构，包括但不限于如下内容：

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

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

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

【提示】

1. 分析方法对照“看微博”和“发微博”的案例

一、业务场景计算性能估算

【评论微博】

建设平均每看 10 条微博评论 1 次，那么评论微博的次数为：

250 亿/10=25 亿

评论微博的时间段肯定与看微博的时间段重合，因此评论微博的平均 QPS 计算如下：

25 亿 * 60% / (4*3600) = 100 K/s

二、非热点事件时的高性能计算架构设计

【业务特性分析】

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

【架构分析】

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

【架构设计】

1、负载均衡算法选择

评论微博的时候，可以将请求发送给任意服务器，这里选择“轮询”或者“随机”算法。千万不能根据微博 ID 进行 hash 算法，会导致热点微博的评论请求都集中到同一台服务器。

2、业务服务器数量估算

按照一个服务每秒处理 500 来估算，完成 100K/s 的 TPS，需要 200 台服务器，加上一定的预留量，250 台服务器差不多了。

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

任务分解

考虑到评论微博与看微博和发微博的 QPS/TPS 相差 10 倍，建议将评论微博拆分到独立的服务。

三、热点事件的高可用计算架构设计

【用户行为建模和性能估算】

大 V 和明星爆料，一条微博可能造成大量的评论，短时间内给系统造成很大的压力。

【业务特性分析】

热点事件发生后，大多数的请求多落在了导致热点事件的那一条微博上。

【计算高可用架构分析】

评论微博的重要性和影响力不高，可以考虑对“评论微博”限流，因为评论数也是一项重要的指标，因此尽量少丢弃请求，考虑用“漏桶算法”。

【计算高可用架构示意图】