架构实战营 - 模块五作业

【作业要求】

基于模块 5 第 6 课的微博实战案例，分析“微博评论”这个核心场景的业务特性，然后设计其 高性能高可用计算架构，包括但不限于如下内容:

1. 计算性能预估(不需要考虑存储性能);

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

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

一、性能预估

首先我们给予对发微博的业务分析，依据发微博的每天每人 1 条微博假设，我们假设每人评论微博的数量为每人每天 10 条。那么计算得出每天发评论总数为 25 亿条。

同样的发评论的用户时间也集中在早上 8:00~9:00 点，中午 12:00~13:00，晚上 20:00~22:00 这 3 个碎片时间点内。同样假设这几个时间点评论微博的总量占比为 60%，则这 4 个小时的平均评论 TPS 为：25 亿*60%/（4*3600）≈ 100 K/s

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

1.业务特征分析

发评论与发微博一样时一个典型的写操作，因此同样适用负载均衡

2.架构分析

用户量过亿，采用多级负载均衡架构。覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡。

3.架构设计

发评论时只需要将评论信息同样可以发送给任意一台服务器，负载均衡可以采用简单的“轮询”或者“随机”算法。

我设计将发评论作为独立的微服务进行开发部署，因为评论功能与发微博功能虽然类似但可以解耦，并且拆分为独立的服务后可以更好的进行高性能部署。

发评论同样涉及内容审核(依赖审核系统)、数据写入存储(依赖存储系统)、数据写入缓存(依赖缓存系统)。但是发评论的逻辑相比发微博要简单的多数据只需要与微博进行关联，无需考虑关联多少推荐用户因此服务器的处理性能会比发微博要高我们按照一个服务每秒处理 1000 来估算，完成 100K/s 的 TPS 需要 100 台服务器，加上一定的预留量，120 台服务器即可。

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

热点事件时由于评论 TPS 无法预估因此我们可以考虑对服务进行限流控制。将整体服务限流在预设的 100 K/s 使用漏斗算法让部分用户的评论提示超时或失败来保证整体服务的稳定。