Facebook Live 直播项目启动于两年前的一次黑客马拉松(hackathon),八个月后就匆匆上线。在近期的 QCon 伦敦大会上,Facebook 视频架构主管 Sachin Kulkarni 做了演讲并指出,如何处理同一直播流中数量变化无法预测的观看者是Facebook Live 的一个挑战。在报告中,Kulkarni 还介绍了构建Facebook Live 直播流时所面对的架构上和设计上的挑战。
从较高层次上看Facebook Live 架构,一旦一个观看者连接到最近的“接入点”(PoP,Point of Presence),就会启动一个Live 直播流。PoP 连接会被依次提交给数据中心,在数据中心中完成直播流的编码。之后,数据中心会将直播流发送给多个不同的PoP 和回放客户端。据Kulkarni 介绍,PoP 负责视频的缓存、终止观看直播的客户连接,并通过Facebook 自建网络将直播流传递给数据中心。自建网络传输更为可靠,并降低了往返时间。
针对在扩展性上的挑战,Kulkarni 指出,并发直播流的数量和全部直播流的总计观看者数量都是可预测的,因此并不存在多少挑战性问题。真正的问题在于,单一直播流上的观看者数量不定,从寥寥数人到门庭若市。因为观看者是不可预测的,也就无法对其做出规划。为解决该问题,Facebook 采用了缓存和直播流分配这两种方法。
Kulkarni 指出了相比于常规视频而言,Live 直播流中存在的其它一些挑战:
- 因为直播内容是实时创建的,所以不可能预先建立缓存,任何形式的预缓存都是不可行的。
- 对直播事件做预先规划并扩展资源,这一做法是存在问题的。
- 难以预测由全球热点事件所导致的并发流和观看者的激增问题。
网络问题是直播流可靠性的主要挑战。为解决这些问题,Kulkarni 提出了三个建议:
- 通过使用自适应码率进行调整,降低视频质量以适应较低的带宽,虽然这项技术常用于回放端,但他们也正在将其用于采集端了。
- 使用客户端的临时缓存处理暂时性连接丢失。
- 最坏的情况是带宽不够,这时需要将广播和回放转换成只提供音频。Facebook Live 认为,能听到要比能看到更重要。
Kulkarni 还给出了一些从项目中得到的经验教训:
- 不积跬步,无以至千里。任何大型服务都是从细微之处开始的。动手去编写代码远胜于无休止地纸上谈兵。
- 可靠性和可扩展性是设计中必须要考虑的问题。无论运行故障是否有规划,都应做出相应的设计。
- 为交付大型项目,需要做出妥协。
- 考虑未来的特性,应保持架构的灵活性,使得团队的演进可以超越架构的变更。
查看英文原文: Challenges Building Facebook Live Streams
感谢冬雨对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ , @丁晓昀),微信(微信号: InfoQChina )关注我们。
评论