题目

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

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

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

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

题目分析

跟往常一样，还是先对题目进行一下分析，课上老师已经快速的完成了发微博和看微博两个场景的性能分析和架构设计，一气呵成，看起来一切都是水到渠成，作业中的微博评论跟发微博有些类似，所以可以照猫画虎，做出来难度应该不高。

第一个问题计算性能预估，这个就是在现在信息的基础上，估计微博评论的性能情况，。

第二个问题是非热点事件的高性能计算架构，微博评论本质上是一种写操作，所以推测应该与发微博有很大的相似性。

第三个问题是热点事件的高可用计算架构，这个老师上课提到了一个写缓冲应该很有用，不过个人觉得写缓冲的本质仍然是限流，只不过这个限流是在最大限度的不丢弃数据的基础上来实现的。不过在扛不住的情况下，仍然要优先保证看微博和发微博这两个核心业务，所以肯定也要用到降级和熔断等技术。

个人回答

计算性能预估

课上已经评估过发微博的性能了，每天微博发送量约为 2.5 亿条，微博评论与发微博的时间基本重合，假设【发出的微博有 20%会有 10 条评论】，那么性能股评如下。

2.5 亿*0.2*10*0.6/(4*3600)约 20K/s

非热点事件的高性能计算机构

业务特性分析

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

架构分析

用户量过亿，多级负载均衡都要上，DNS->F5->Nginx/LVS->网关

架构设计

负载均衡算法的选择

微博评论要在登录时才可以进行，因此跟发微博一样依赖登录状态，登录状态保存在分布式缓存中，负载均衡算法选择轮询或随机算法、

业务服务器数量评估

跟发微博类似，一样涉及到内容审核，数据写入存储，数据写入缓存。基本也是按照一个服务每秒处理 500 来估算，完成 2W 的 TPS，需要 40 台服务器，加上一定的松弛量，评估为 60 台服务器。

负载均衡架构

是否拆分

由于微博评论与发微博高度相似，所以考虑与发微博放在一起，不需要拆分

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

课上有一个非常核心的数据那就是大概 10%的观看者会在 60 分钟内进行转发。基本基于这个信息就可以大体估算出微博评论的性能量级了。个人觉得评论与转发的人基本属于同一个量级，可以用同一个评估模型评估，即 10%的观看者会在 60 分钟内进行评论。

架构设计分析

需要对微博评论进行限流，老师在课上已经提到了由于评论也能够带来更好的传播和人气，所以也要尽量少丢弃请求，因此采用“漏桶算法”，具体采用写缓冲实现，如下所示。

弹性扩容

通过监控上面的写缓冲队列的长度，服务节点负载情况，借助 K8S 等 PAAS 平台，可以实现服务节点的弹性扩容，甚至可以缩减非核心的服务数量，提高核心服务的节点数量，提高用户体验。

学习总结

终于在下一次作业之前补上了模块五的作业，其实完成作业的最好的时间就是刚刚学完的时候，那时候印象比较深，各种资料找起来也是比较简单。

作业这种事情是越拖越糟糕的，工作生活也是一样的道理，所以才有先做重要的事这个说法，但真正的要做起来却也是充满挑战性，就算你知道应该先做重要的事，有时候也没有办法能够抗住各种急事的压力来全心全意的完成重要事。

额，跑题了跑题了。

模块五主要讲了缓存和负载均衡在高性能计算中的作用、典型技术的特性和使用技巧。

负载均衡主要讲解了 DNS/F5/LVS/Nginx/网关,这几级，特别贴心的给出了各级负载均衡的大体性能，这样以后评估就方便和有底气多了。

高可用方面主要讲了限流，熔断和降级等方式，这些功能主要可以集成到网关，排队则一般归位相对独立的组件。

最后通过微博的案例，来将本模块的全部知识点串起来，完成了从理论到实战的落地。

OK，时间也不早了，收工，回家。