作业：架构实战营模块 5

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

用户量估算

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

关键行为：

1. 发微博

2. 看微博

3. 发评论

4. 看评论

本作业主要针对评论微博和看评论两个关键行为。根据业务重要性及耗时容忍度排序， 看微博 < 发微博 < 看评论 < 发评论。

按照课程中的预估，每天微博发送量约为 2.5 亿条。看微博量 250 亿次。发评论、看评论的数据量缺少支撑。

因此假设发评论量也为 2.5 亿条。看评论量约为看微博量的 30%，大约 75 亿次。

假设 4 个小时内数据量占比 60%，则：

发评论 TPS 为 2.5 亿 * 60% /(4*3600)  ≈ 10 K/s

看评论 QPS 为 75 亿 * 60%/(4*3600)  ≈ 300K/s

发评论

发评论是个典型的写操作，不能用缓存，可以用负载均衡。考虑到业务容忍度，可以利用消息队列实现写缓存。

架构分析

需要使用多级负载均衡，覆盖 DNS -> F5 -> Nginx -> 网关等多级负载均衡。利用 MQ 实现写缓存。

负载均衡算法选择

可以选用轮训算法 或随机算法。

业务服务器量预估

发评论也涉及到审核等多个步骤，评估 MQ 的性能，以及服务器消费性能，因此按照一个服务支撑突发流量 2000/s 计算，完成 10K/s，需要 5 台服务器，加上一些与流量 8 台差不多了。

看评论

看评论是查询的读场景，由于评论发布后不能修改，因此非常适合用缓存架构，同时由于请求量很大，负载均衡架构也需要。

负载均衡算法选择

可以选用轮训算法 或随机算法。

业务服务器预估

CDN 可以承载 90 的用户流量（主要针对热点事件的微博评论），剩下的 10%的读评论请求进入服务器，则请求 QPS 为 300K/s*10%=30K/s。由于对业务耗时有一定容忍，因此可以采用 Reactive 模式处理请求，假设 QPS 可以做到 2000，则机器数量为 15 台，按照 20%预留量，最终机器数量为 18 台。