查看原文

视频直播服务很容易收到特殊事件的冲击导致出现流量高峰。对于 Facebook Live 服务，他们的系统有三种常见的模式：Routine（作息导致的高峰和低谷），完全无法预测的高峰（例如自然灾害或者灾难或者哪里枪击案了），预期的高峰（例如节日）。要让系统很好地应对流量高峰，首先需要对系统架构有认知，找出瓶颈，然后逐个测试其上限，平时做演练，最后真刀真枪时上备好的服务器增强容量。

对于 Facebook Live，他们的架构分三层，直播的客户端的 RTMPS TCP 流数据通过 Edge PoP 到达 Facebook Live Servers (FBLS), 完成 HD/SD encoding 以后永久存储到 Distributed Media Storage，同时数据会通过 Facebook CDN 到达 回放的客户端。

这个系统架构的主要资源消耗在这几个组件中：

• Edge PoP
• Facebook Live Servers (FBLS)
• Distributed Media Storage
• FB CDN

同时，一些基础服务，例如 log storage, metrics collection, configuration distribution 都有可能受到影响。说到 metrics，他们使用了三种指标，分别是每天直播的总量，一天的峰值，以及 scaling 对其它系统造成的负载。其中峰值是最主要的指标，特别是用于预备 capacity 的时候。最后的指标也很重要，主要体现在 routing host 和 app server 中间会有 many-to-many 的连接，当 scale 上去以后，健康检查会产生更多的网络流量，相应地，要调低健康检查的间隔。

应对突发流量的操作倒是简单：备好服务器，不够了就补上去。同时照顾好监控的指标，相应的调整一些参数，除了上限提到的健康检查间隔，还有视频存储的最小单元调长，以减少 IO 写次数。

预演是应对突发流量所必须的。在没出现流量高峰的时候就做 Load Testing，确保系统来流量的时候扛得住。造流量的方法可以是：

• 把流量调到一部分服务器去
• 对存储系统做 Synthetic load test，简单写入大容量的合成数据。
• 或者把生产环境的流量 replicate，导到独立的环境里面去测试。当然，要确保这些流量不会和线上的混起来。