架构实战营模块 5 高性能高可用计算作业

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

【作业要求】

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

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

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

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

【提示】

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

性能估算

用户量预估：

2020.9 月月活 5.11 亿，日活 2.24 亿约等于 2.5 亿日活

用户行为建模：

发评论：假设每条微博平均文字评论 10 条，同样假设每天四个小时评论占总评论的 60%，则四个小时的评论 TPS 计算：

2.5 亿*10*60%/(4*3600)≈100K TPS

看评论：每条微博默认加载评论 10 条，继续下拉会一直分页加载，每天看微博 QPS 100K/S 峰值，一次加载 10 条算一次请求，假设平均每次请求加载 20 条，请求 2 次，则每天看微博评论：

1000K/S*2=2000K QPS

高性能架构设计

发评论

发评论是写操作，所以也不能使用缓存来优化性能，但可以使用负载均衡。

架构分析

用户量过亿，需要使用多级负载均衡架构。

架构设计

1. 负载均衡算法选择

由于加载一条微博时，页面会同时加载评论，将请求发给任意服务器都可以，所以选择轮询或者随机算法。

2. 业务服务器数量估算

发评论同发微博，也依赖以下处理：内容审核、数据写入存储、数据写入缓存，按照一个服务每秒处理 500 来计算，完成 100K TPS，则需要 200 台服务器，加上预留量 20%，大约 250 台服务器即可。

负载均衡架构同发微博，仅机器数量不同，此处略。

看评论

看评论是读操作，可以使用缓存优化性能，由于业务量很大，所以也要使用负载均衡。

架构分析

使用多级负载均衡；同时由于读请求量较大，所以需要使用多级缓存架构，同样需要使用 CDN 作为核心缓存。

架构设计

1. 负载均衡算法

看评论同样的，负载均衡算法选择轮询或随机。

2. 业务服务器数量估算

假设 CDN 可以承载 90%的流量，则会有 200KQPS 的请求量；

看评论服务逻辑比较简单，仅涉及数据读取，按照一个服务每秒处理 1000 QPS 来计算，则需要 200 台服务器来处理业务，按照 20%预留，则约为 250 台。

负载均衡架构同看微博。

缓存架构

微博评论排行是一个典型的计算量大但是实时要求没有非常高的场景，所以有必要进行结果缓存。

由于评论列表相对本地缓存失效而言，会经常性的变化，同时微博评论默认是按热度排序的，所以 APP、浏览器本地缓存比较没有意义。而其他环节的缓存需要设置，但是需要给定一定的有效时间，进行即时更新，保证评论在一定时间范围内是比较新的。

关于是否拆分独立服务，同发微博看微博，评论的读写也并不是一个非常集中的动作，同时量级差异也是比较大的，所以将两个服务拆分开，对于业务维护，以及后续扩展演进都是比较好的。

热点事件高可用架构分析

热点事件发生无法预估，所以在架构设计上要注重预防。

1. 发评论

限流

发评论实际上用户发完以后不一定马上要刷到自己的评论，在热点事件中，由于评论是按照热度排序，所以用户新发的评论更不可能立即看得到，所以时效性要求比较低。

①所以写入方案应该使用限频中的漏桶算法，写缓冲方案，以应对热门微博评论的突然高并发写入场景。写缓冲长度超出，则考虑拒绝掉后续溢出的写入需求。

②同时在热点事件中，可以考虑在客户端侧提示服务繁忙，限制用户写入频率，避免用户写入失败影响体验。

2. 看评论

看评论存在热点效应，对于粉丝量较大的微博博主，首先就应该提前设置多副本缓存，应对可能的热点。

同时对于看评论，并不是热点事件的主要功能，如果该条微博评论访问量过大，可以考虑进行限流或者熔断，避免产生雪崩事故。

3. 人工扩容

当热点事件发生时，可以考虑通过监控系统预警，人工介入视情况扩容服务。