| 编辑推荐: |
本文来自于51cto，文章设计及服务可用性方面，详细解析了微博短视频高可用、高并发架构设计中的问题与解决方案等内容。
|
|
微博视频业务场景
我们的业务场景主要是应对热门事件的流量暴涨，例如明星绯闻、爆炸性新闻等势必会让流量在短时间内急剧增长的事件。
如何从架构上保证流量暴涨时整体平台的稳定性?如果只是简单地通过调整服务器规模解决，流量较小时过多的服务器冗余带来成本的浪费，流量暴涨时过少的服务器又令平台服务处于崩溃的边缘。
比较特别的是，我们面临的问题与诸如“双十一”这种在某一确定时间段内流量的可预见式高并发有着本质的不同，我们面临的流量暴涨是不可预见的。因此通过哪些技术手段来妥善解决以上问题，将是接下探讨的重点。
以上是基于微博的过去已经公开数据量级，非近期内部数据。微博视频是一个多业务接入的综合平台，你可以在微博上看见现在市面上的各种玩法。
这就导致我们即将面临的并不是某个垂直业务领域的命题，而是一个构建在庞大体量下的综合性命题，这就导致现有的通用技术框架无法妥善解决我们所面临的难题。
因为一些开源方案无法顺利通过技术压测，所以我们只能在开源方案的基础上进行自研与优化才能得到符合微博应用场景需求的技术解决方案。
微博的短视频业务被称为“微博故事”，上图展示的是“微博故事”的展现形态。这是一个布置在微博首页一级入口上的模块，主要展示的是用户关注的人所上传的
15 秒内的短视频。
我们希望强调其“即时互动”的属性，视频只有 24 小时的有效展示时间。不同用户的视频按照时间轴在上方排序，多个视频可依次观看、评论、点赞等。
“微博故事”业务场景架构设计
微服务架构
上图展示的是这项业务的微服务架构：在接口层我们混布了 Web API 与内部的 RPC 请求。
在这里我们并未集成具有实际意义的门面层，而接下来的服务层集成了许多微服务，每个微服务集中在一个垂直功能上并可对外提供接口，这里的门面层主要作用是聚合一些微服务并对外提供综合性接口。
除此之外还有一些依赖服务例如用户关注、也需要依赖于其他部门的 RPC 服务;最后的存储层则是集成了
Cache 与 db 的标准方案。
技术挑战
有人曾问到：微博短视频业务的高并发有多高?假设我关注了 500 名好友，如果有好友发布一个视频就会在“微博故事”头像列表上显示一个彩圈用以提示我去观看。
如果我想知道自己所有关注的 500 个人所发的视频内容，假设首页每秒刷新十万次，那么需要每秒钟五千万的
QPS。
除此之外我们还需要确定视频是否过期、视频发送顺序等，实际的资源层读取量将远远高于五千万。
方案比较
在构建解决方案时我们思考：可以借鉴微博之前的 Feed 解决方案，我们不会进行无意义的重复性工作与思考。
即使短视频与 Feed 都具有首页刷新与关注人发布消息聚合的特点，但以用户列表为形式，强调进度续播与即时互动的短视频和以内容列表为形式，强调无阅读状态与永久保存的微博具有本质的区别。
面对一般的 Feed 应用场景可以使用以下两种模型：
Feed 推模型
Feed 拉模型
①Feed 推模型
Feed 推模型是指将用户上传发布的内容推送至每一位粉丝，这种方案具有很大的弊端。由于用户尚未达成一定规模，早期的微博以
Feed 推模型为主导。
而现在一个大 V 用户的粉丝数量普遍都是千万级别，如果依旧使用 Feed 推模型则意味着千万量级的内容推送，在难以保证千万份推送一致性的情况下，势必会为服务器带来巨大压力。
微博的业务强调的就是强时效性下的内容一致性，我们需要确保热点事件推送的瞬时与一致。
除了从技术层面很难确保千万级别内容推送的时效性与一致性，由于用户上线状态的不统一，为离线的用户推送强时效性的内容无疑是对服务器等资源的巨大浪费，为了避免以上麻烦我们必须改变思路。
②Feed 拉模型
Feed 拉模型：拉取关注的人并实时查询状态及内容。综合微博的庞大用户体量、数据写入开销与确保一致性三方面，我们决定选择
Feed 拉模型。
如何通过 Feed 拉模型应对如此规模庞大的 QPS?首先我们采用了分布式缓存架构，在缓存层集成了数据分片并将缓存通过哈希算法合理分片，之后再把缓存去切片化并进行存取。
分布式缓存架构
其次我们使用了独有的多级缓存方案也就是 L1、 Master 、Slave 三层缓存方案。
L1 是一个热度极高容量极小的缓存，我们称其为“极热缓存”，其特点是便于横向扩展。
假设 L1 只有 200MB 缓存，我们使用 LRU 算法通过热度分析把访问最热的数据存储在 L1
中;之后的 Master 与 Slave 的缓存空间则是 4GB、6GB，比 L1 大很多倍。
因为微博的流量比较集中于热点事件中某几位明星或某个新闻，小容量的 L1 可进行快速扩容;在发生热门事件时利用云的弹性自动扩容从而分担热点事件短时间激增的流量压力。
由于自动扩容时 L1 仅占用每台缓存中很小的空间，扩容的速度就会非常快，通过这种手动或自动的瞬间弹性扩容来确保服务器稳定承受热点事件背后的数据激增量。
第二层的 Master 与 Slave 具有比 L1 大好多倍的缓存空间，主要用于防止数据冷穿。
虽然 L1 主要承担的是热点数据，但却无法确保一些短时间内不热但在某个时间段热度突然高涨所带来的流量短时间爆发时服务器的稳定性。
HA 多机房部署
而 Master 与 Slave 作为 L1 的逻辑分组可有效防止数据过冷，在这里我们采用的是 HA
多机房部署。
例如图中的的两台 IDC，我们称左边为 IDC-A，右边为 IDC-B。缓存层的 Master 与
Slave 是主从同步的关系，双机房的缓存互相主从同步。
这里的“互相主从同步”是指 IDC-A 的 MC 与 IDC-B 的 MC 之间进行双向同步互为主从。
因为在进行双机房部署时需要均衡两个机房的流量负载，在缓存层需要使用 LRU 算法进行热度分析。
如果我们将流量分为两份并传输至两个机房，通过每个机房的 IRU 算法得到的热度信息有一定失真。
如果我们在缓存层做相互同步后每个机房的 MC 都是一个全量的热度算法，那么两个机房的 L1 基本可实现同步计算得出的热度信息一定是准确的，只有保证热度信息的准确无误才能从容应对流量激增与整个系统的高可用性。
在这里需要强调的是，实际上我们在选型上使用的是 MC 而未使用 Redis。
MC 对于纯简单数据 Key，Value 的抗量远大于 Redis;MC 采用预分配内存的形式放置
Key，Value，也就是把内存分成若干组相同数据区域，实际上就是若干个数组。
这种特殊结构使其在数据定位数组寻址与读写上的速度非常快;这种结构的缺点是：一旦缓存的数据出现变动就会出现即使内存留有空余但数据依旧无法存储的现象。
由于这种问题的存在，MC 不适用于存储变动大、Value 跨度大、业务多变的数据。
而 Redis 作为单线程方案，一致性更好，但在超大规模简单 Key，Value 读取上速度比 MC
是要差很多的。
除了上述方案之外，我们还采用了弹性扩缩容。实际应用中，基于成本的考量我们无法部署大量的服务器，于是我们采用了自研的
DCP 弹性扩缩容平台。
首先，我们的自有机房有一些共享机器资源可在特殊情况下动态弹性扩充以应对增加的流量压力。
当然，这部分机器的性能是有限的，当数据量超过一定阈值后我们就会接入阿里云并利用我们与阿里云的混合云
DCP 方式构建一层弹性软平台用于自动扩容承担流量压力。
除了弹性扩容我们同时也采用了定时扩容的逻辑，在每天晚高峰时段进行扩缩容从而确保整体服务的稳定性。之所以这么做，主要是为了在保证用户体验的前提下尽可能节约成本。
需要强调的是，扩容对速度的要求十分严格。只有扩容的速度越快，流量峰值来临时可承受的数据量越大，才能确保整体服务的高可用，因而我们也在努力优化扩容的速度。
我们的 DCP 平台上也有晚高峰固定时段扩缩容与突发流量临时扩缩容，通过如流量监控等的自动化容量评估来判断服务器荷载，并通过自动化任务调度妥善解决突发流量对服务器的影响。
微服务熔断机制
当然，为了保证服务器整体的健康与稳定，我们也在其中集成了微服务熔断机制，其原理类似于家用电表中的保险丝，可在过载的情况下迅速自动熔断。
系统会定期进行自我评估并确定每个服务的最大荷载，假设将熔断值定为 3000QPS，那么当 QPS
超过 3000、超时或异常时服务即会迅速熔断并关闭，从而确保其他资源的安全稳定。
通过这种框架级、细粒度的自动降级机制，系统失败隔离能力可被有效提高，避免了雪崩式的链式宕机事件的发生。在熔断的同时，自动扩容也会同步运行。
熔断之后系统会不断更新服务流量荷载，一旦扩容完成或者服务还能继续承受流量即可重新恢复工作，这种熔断机制同样也是为服务器扩容争取时间。 |
