【作业题目】

分析“微博评论”这个核心场景的业务特性，然后设计其高性能高可用计算架构，包括但不限于如下内容：

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

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

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

（本次作业总耗时：80min）

1、性能估算

• 根据《微博 2020 用户发展报告》日活为 2.24 亿，留点 buffer 假设现在日活为 2.5 亿

• 假设每个用户平均每天发布 5 条评论，则每日 2.5*5 = 12.5 亿条评论

• 假设 80% 请求在 20% 的时间内发生，则 TPS = 12.5*0.8/（3600*24*0.2） = 5.8 w/s

• 对业务需求留点 buffer，最终认为微博评论的最高峰 TPS 为 7 w/s

机器数量评估

设计排队服务，将请求丢到 MQ 中。然后写评论服务消费 MQ。

• 对于排队服务，业务非常轻量，只需要向 MQ 放消息。并且可以利用请求合并技术进一步提升 TPS。假设每台业务服务器能处理的 TPS 为 1000/s，则总共要 70 台机器，留 20% buffer，即 84 台

• 对于写评论服务，可以一次消费多条消息（按批），因此会比发微博业务性能高，预估 TPS 为 700。则需要 100 台机器，留 20% buffer，即 120 台

其实写评论服务不需要一直是 120 台，可以根据消息堆积数量进行动态扩缩，这里按最大机器计算，总共需要 84 + 120 = 204 台

2、非热点事件高性能计算架构

架构分析

• 写评论无法用到缓存

• 用户量过亿，使用多级负载均衡架构

• 负载均衡算法：

• 请求不需要定向分发到某一台服务器，因此不需要 hash

• 加权轮询/负载优先/性能优先：机器性能基本一样，避免增加额外复杂度，因此不选

• 因为请求量非常大，随机分布均匀，并且比轮询更简单一点，因此最终选择随机

• 写评论的应用，是否要和发微博应用在一个服务内？个人认为放在一个里更好

• 发微博 TPS 为 1w/s，写评论 TPS 为 7w/s，是一个量级

• 发微博和写评论业务流程相近，没有明显差异，业务复杂度也相近，有更好的代码复用

• 排队服务，不要和写服务放在一起，因为：

• 两者业务复杂度相差很大，排队服务 TPS 比写服务高得多

• 业务没有关系

• 任务分解：网关服务按照 url 分发到写服务还是读微博服务

架构设计

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

服务高可用

在上一节架构设计中，关于高可用的设计点：

• 两个 VIP，两组 LVS + keepalived，避免单点

• Nginx 集群 + 服务网关集群 + 业务集群 均为多实例

业务高可用

为了在热点事件中，保证业务的高可用，有如下设计点：

• 降级：读业务比写业务相对更重要，在故障情况下，在服务网关层对写业务做降级，直接返回错误，保证读业务的正确性

• 熔断：为了配合后端降级，我们在前端（主要是 APP）设计一个熔断机制，当写请求连续错误超过阈值，则进行熔断，不再对后端发起写请求

• 利用 MQ 进行排队：排队服务将写评论请求先丢到 MQ 里，然后写服务按自身处理能力，取任务做处理。业务上从同步改成了异步，可以避免写服务压力过大导致崩溃

4、疑问点

1、写评论和读评论要做服务拆分吗？决定是否放在一个服务里的常见核心因素有哪些？对这个问题理解不够深，感觉这一设计很重要，会影响 微服务复杂度、架构复杂度、各服务性能

2、对于耦合度非常高的业务，比如写评论和读评论，如果进行了服务拆分，存储数据怎么设计好呢？我能想到的方案有：

• 共用一个数据库（个人理解这个方案不错，但有点违背微服务设计原则，不共享数据库）

• 放在各自的库，在 DB 层做数据同步

• 放在各自的库，在业务层做数据同步