如何构建一个弹性的直播架构

了解更多关于流冗余的信息流媒体东部.

阅读这段录音的完整文本:

Kiran帕特尔: 传统的方式来获得很多这种类型的直播工作流, 更有弹性、更可靠的做法是重复这些步骤, 让多个基础设施的组件在这个链上做每一步或者在这个链上做组或那些步骤, 然后进行故障切换. 从一组组件转移到另一组组件. 我认为云给了你一种有趣的看待它的方式, 它不一定有——比如说, 从浅蓝到深蓝再到深蓝——故障转移什么都不做，只需要考虑在整个腿之间切换, 但是想想单个集合的失败.

然后他们昨天又谈了, 看看微服务的内容, 其实也没那么远, 但是如果你看一下工作流程中的各个步骤然后想想工作流程中每个步骤之间的故障转移, 你可以建立一些比传统的工作流程更有弹性和更可靠的东西，在传统的工作流程中，你只有a和B腿，你的故障转移本质上是在一个或另一个之间切换. 我们要讲的核心信息是...

我还想讲一些例子, 但你的弹性基本上是建立在冗余和冗余之间的故障转移之上的. 这种简单的形式就是复制你正在建造的东西, 然后手动在A和B之间切换.

我认为云所能提供的是一种更好的弹性形式, 也就是拥有云原生架构, 它利用了一些可能的自动缩放. 当你以这种方式架构时，自动伸缩组可能会带来一些修复，然后试图让尽可能多的故障转移也自动进行. 这张幻灯片被标记为“在混乱中生存”的原因是Netflix因为他们的很多架构而出名——他们已经开源了——混乱工程的概念, 你会有一个稳定的状态, 从现场拍摄的角度来看，你的观众应该能够继续观看你的现场输出.

不管你的架构或工作流程有什么中断, 如果组件故障或者网络连接故障, 只要你的观众能继续看直播, 你已经开发了一种架构，它基本上是一种防混乱猴子的架构. 所以你们知道, 你可以, 你可以在其中删除组件，这样你的观众就会观看直播.

所以这应该是我们的目标:不必注意到某些东西已经失败了, 或者确保你的观众没有注意到某些东西失败了，即使你注意到了. 然后你就可以专心修理它了, 知道你并没有真正影响到你的最终用户. 然后得到, 从本质上讲，备份到完整的弹性或冗余级别，对最终用户产生无形的影响. 然后你就达到了你的目标，或者如果你在看一个24/7的流媒体场景，理想的100%的时间. .

免费的

合资格订户

现在就订阅最新一期过去的问题

如何大规模交付弹性流

保证令人满意的最终用户体验, 无论你是提供直播内容还是视频点播, 需要弹性, 确保无论规模如何，溪流都不会中断, 爆发, 或其他交付需求的波动. 直播和视频点播面临的挑战是不同的, 在大多数情况下，现场证明更具挑战性. TAG视频系统公司的Michael Demb说, DAZN的鲍勃·汉内特报道, 和CDN联盟的Mark de Jong在这段来自流媒体连接2023的视频中讨论了主要挑战以及如何解决这些挑战.

2024年1月8日