架构实战营 4 期 - 模块 5 作业

作业要求

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

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

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

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

性能预估

【用户量】

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

【关键行为】

1. 发评论；

2. 看评论；

【性能估算】

发评论：假设平均每人每天看 10 次评论，大部分人发评论集中在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00，假设这几个时间段发微博总量占比为 60%，则这 4 个小时的平均发评论的 TPS 计算如下：2.5 亿 * 0.6 *（4 *3600) *10 ≈ 100k/s

看评论：假设看评论的次数是发评论的 10 倍，即平均每人每天看 50 次评论，则 TPS 计算如下：100k/s*10=1000k/s

计算架构设计

服务拆分设计

发评论和看评论服务拆开

理由：

1、发评论和看评论并没有特别强的关联，举个例子发评论以后并不需要被马上看到

2、发评论和看评论的性能差距比较大，特别是热点微博的热点评论，在架构设计上也有一些差别，所以拆开比较好设计和维护

负载均衡架构设计

发评论和看评论均采用 5 层负载均衡：

1 层负载均衡：dns，采用双机房负载均衡

2 层负载均衡：F5

3 层负载均衡：LVS

4 层负载均衡：nginx

5 层负载均衡：网关

缓存架构设计

采用多级缓存：

1 级缓存：客户端缓存

2 级缓存：CDN 缓存；设计细节：这里主要是为了应对看评论，而并不是所有评论都需要缓存，一般来说仅需要缓存前几页（比如 500 条）。在 CDN 缓存层，一般能挡掉 90%的服务端压力

3 级缓存：web 容器缓存

4 级缓存：本地缓存（如 guava cache）

5 级缓存：分布式缓存（如 Redis），这里主要还是缓存热门评论和最新评论

服务器数量估计

每台机器按照每秒处理 1000 条发评论请求计算，100k/s 需要 100 台机器

由于看评论可以使用缓存，所以估算的 1000k/s 实际可以按 100k/s 算，也即需要 100 台机器

总计共需 200 台服务器（不算分布式缓存服务器）

整体负载均衡架构

热点事件高可用架构设计

请求量预估

由于热点事件的时间和流量的不确定性，因此不太好预估请求量

限流/缓冲设计

发评论

由于发评论的数据是不能丢的，否则会造成较差的用户体验，因此发评论不适合使用类似令牌桶算法的限流策略；

这里可以使用消息队列实现缓冲，设计理由：

1、消息队列有出色的消息积压能力

2、消息队列能做到削峰填谷，

3、评论实时性要求没有很高，发出去 1 分钟后才展示出来并没有太大的影响

看评论

看评论是允许消息丢失的，因为丢失后无非就是重新请求一次，并没有太大的影响，那么就可以使用我们常用的令牌桶算法，也可以使用漏桶算法

降级设计

如果实在不幸系统没办法抗住高峰，则采取降级。

1、事先在代码中设置好埋点/开关

2、当出现系统瓶颈时，人为操作开关停用一些非核心功能，如评论点赞