详细架构设计文档

前言

本次实现的是针对微博系统中”微博评论“的高性能高可用计算架构的设计需求，进行详细架构设计的描述和说明，用于指导后续架构设计的落地实现。

词汇表

DNS：Content Delivery Network，即内容分发网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率，关键技术是内容存储和分发技术。

LVS：是 Linux Virtual Server 的简写，意即 Linux 虚拟服务器，是一个虚拟的服务器集群系统。

Nginx：是一款自由的、开源的、高性能的 HTTP 服务器和反向代理服务器；同时也是一个 IMAP、POP3、SMTP 代理服务器；Nginx 可以作为一个 HTTP 服务器进行网站的发布处理，另外 Nginx 可以作为反向代理进行负载均衡的实现。

Redis：是最受欢迎的 NoSQL 数据库之一，它是一个 key-value 存储系统，及内存高速缓存数据库。

GSLB：(Global Server Load Balancing)：全局负载均衡，主要用于在多个区域拥有自己服务器的站点，为了使全球用户只以一个 IP 地址或域名就能访问到离自己最近的服务器，从而获得最快的访问速度

1. 业务背景

【发微博】

考虑到微博是一个看得多发的少的业务，假设平均每天每人发 1 条微博（只考虑文字微博），则微博每天的发送量约为 2.5 亿条。

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

【看微博】

由于绝大部分微博用户看微博的对象是大 V 和明星，因此我们假设平均一条微博观看人数有 100 次，则观看微博的次数为：2.5 亿 * 100 = 250 亿。

大部分人看微博的时间段和发微博的时间段基本重合，因此看微博的平均 QPS 计算如下：250 亿 * 60% / (4*3600) = 1000K/s。

【评论微博】

假设每条发出去的微博都能收到 10 条评论，基于发微博的 TPS 换算评论微博场景的 TPS 为： 10K/S*10 = 100K/S。

2. 约束和限制

l 采用多机负载均衡

l 成本限制在 XXX 元以内

l 开发周期在 XX 年 XX 月 XX 日完成发布上线

l 数据库限制使用 MySQL

l 开发方式采用敏捷开发方式推进

l 系统数据不能丢失

3.设计分析

业务特性：发评论场景也是典型的写操作，但是实时性要求没有发微博场景高，热点事件场景评论较多，评论易被快速淹没，用户一般对实时性要求没那么高，但是写好的评论数据不可丢弃

架构分析：

（1）、用户量过亿，应该要用多级负载均衡架构，覆盖 DNS -> F5 -> Nginx ->网关的多级负载均衡

（2）、考虑到微博评论场景实时性要求不高，因此考虑引入 kafka 这类消息队列作为写缓冲，做异步缓写架构，同时也可以应对热点事件突发流量，对请求进行削峰填谷

（3）、看评论场景和看微博场景处理方式类似，请求量同样达百亿级，因此需要多级缓存技术

架构设计：

（1）、负载均衡架构中算法选择

评论请求同样无状态，无需 ip hash 到固定服务器，可以发到任意服务器，因此可以采用“轮询”或“随机”算法即可

（2）、业务服务器数量估算

写评论同发微博，涉及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），因此按照一个服务每秒处理 500 来估算，完成 50K/s 的 TPS，需要 50 台服务器，考虑到核心业务都是异步缓写，按 20%比例预留，则总台数为 60 台。

看评论参照看微博，假设 CDN 能够承载 90%的用户流量，那么剩下 10%的读微博的请求进入系统，则请求 QPS 为 1000K/s * 10% = 100K/s，看评论主要是读缓存系统，因此假设单台业务服务器处理能力是 1000/s，则机器数量为 100 台，按照 20%的预留量，最终机器数量为 120 台。

4.总体架构