分享千万级直播系统后端架构设计

Posted 2022-06-11 wecloud1314

直播技术架构，分为几大部分：

    1）视频直播中心（LMS——Live Manage Service）：负责直播流的逻辑管理和操作控制，包括存储和下发实时转码、加密等媒体处理的配置信息；

    2）实时互动直播服：由连麦互动和直播两部分组成，主播和连麦者的音视频数据在互动直播高性能服务器合成为一道流后推流到直播流媒体服务器；

    3）直播源站服务（LSS——Live Source Service）：网易云信自建的直播流媒体服务器节点，结合全局智能调度系统，提供第一公里的最佳链路选择，同时融合支持接入多家CDN厂商；

    4）媒体处理服务（MPS——Media Processing Service）：提供实时水印、实时转码、媒体数据加密等强大的流媒体处理能力；

    5）融合CDN与全局智能调度（GSLB——Golabal Server Load Balancing）：提供敏捷智能的CDN调度策略和分配算法，结合全链路、端到端的流媒体控制，来达到最终端侧优良的用户体验；

    6）客户端SDK：提供推流、拉流以及上下行的调度能力，便于用户快速接入使用网易云信平台一站式的音视频解决方案。

 

融合CDN与智能调度

这是一个端到端的服务，通过平台的SDK执行一个类似HTTPDNS的调度，来做到真正根据用户IP做就近的接入。

针对国内相对复杂的运营商网络环境，在直播上行方面通过BGP网络以及与相关运营商在网络接入方面的合作，能够更加精准地控制网络链路的选择。

而对于下行，也提供了播放端的SDK接入，通过端到端的调度策略就近选择合适的下行链路。

调度的准确性以及最终效果，依赖及时准确的数据支撑。

我们有一个全链路、立体的数据监控体系，一方面利用CDN上的一些实时日志，另一方面结合自建节点、客户端侧上报收集链路上探测的数据，然后整合做一个实时计算来支撑整个调度的策略。

融合CDN方案，通过调度、监控、高可用等技术和手段来解决CDN网络方面的问题。但是对于技术人员来说，就和在使用一个传统的CDN网络一样没有大的差异，这些技术细节对技术人员透明无感知。

流量精准调度

大型演唱会直播活动，尤其是正式开播时的进场阶段，突发流量峰值会非常高，这就需要实时精准的智能调度策略。

融合CDN的智能调度包含两大部分：CDN分配调度和节点调度。

节点调度：比较常见的是DNS协议解析调度和IP调度（302/HTTPDNS）。前者由于DNS协议原因，调度生效时间较慢，而后者则可以做到请求级别的调度，也就是支持任意比例的负载均衡，更加及时精准。在我们的智能调度的场景里，正常情况下会遵循IP调度，在IP调度解析失败时，客户端上会启动loacl DNS解析逻辑，两者的结合确保了调度的精准和稳定可靠。

Don't put all your eggs in one basket.

“永远不要将鸡蛋放在同一个篮子里”。

从风险管控的角度来说：大型活动保障的CDN厂商资源，通常没法通过一家CDN资源进行满足。融合CDN方案则是将多家CDN厂商进行整合与流量分配调度。

通常在一次大型直播中，多家CDN厂商提供的容量（区域带宽、最高带宽）、质量会各不相同。我们则是通过动态调整调度比例，在确保不超过最大带宽的前提下，精确化按比例分配流量，以及尽可能地确保体验。

我们设计了一套针对CDN厂商的打分算法：影响因子包含当前带宽、保底带宽、最大带宽、带宽预测、带宽质量。

 

算法遵循以下原则：

    1）没超保底的带宽，比超过保底的带宽，得分更高；

    2）没超保底的时候，剩余保底和剩余总带宽越大，得分更高；

    3）超过保底的时候，剩余总带宽越大、质量越好，得分更高。

各CDN的分数之比决定了调度比例，CDN打分算法是在持续地迭代更新计算，最大化分配使用各家CDN的带宽，然后再分配各家CDN厂商的保障之外的资源。同时优先选择质量较好的厂家，避免单价CDN厂商超分配。

单元化部署

上面所说，在大型直播活动中，短时间大量涌入的用户请求，对以全局智能调度服务为主的相关非媒体流链路应用，也提出了更高的并发处理挑战。

除了上行的推流链路我们做了主备两个单元的部署，非媒体数据链路上的服务也采用了单元化的部署方案。

在此部署方案下，可用性做到任意单元机房故障，不影响整体可用性，即异地多活。

单元化部署遵循以下原则：

    1）单元化的依赖也必须单元化（核心业务）；

    2）单元化粒度为应用，非api；

    3）单元化技术栈对应用尽量避免产生侵入性。

非单元化的业务部署在主机房，单元化的业务则部署在主机房和单元机房。

整体方案可以承受任何单节点、单线路、单机房网络出口的故障。

如直播源站部分：采用了多线策略收流，包含机房专线和4G背包方案，一主一备两个线路。同时每个单元的源站集群都有4层负载均衡，一台机器宕机不会影响整体可用性。LMS、LSS、MPS都是跨机房部署，所有服务模块都可配置专有资源池供使用，保证不会受其他租户影响。

整个推流链路：采用双路热流、互为主备，且部署上是互相独立的两个单元，能做到支持Rack级别的故障灾备。双路热流实现了自动主备切换，端上无需专门添加应用层的线路切换逻辑。当任何一个链路出现问题的时候，观众的直播流不会受到影响，端上平均卡顿感知时间在1s以内。

除了推流链路的整体主备单元容灾，每个单元的服务本身也会有容灾手段。比如UPS接入，可以接受30min的供电故障，比如当实时互动流出现问题时，导播台会推垫片流以保证链路数据不中断。

下行链路稳定

在访次直播活动中，全局智能调度服务会承受较大的峰值压力，在单元化部署的基础上，我们经过多轮压测和性能调优，模型上可支撑千万级用户在半分钟内全部进入直播间。即时通讯开发

除了上述关于推流链路的高可用，下行链路也有相关的容灾策略。当GSLB智能调度服务整体不可用，在客户端SDK预埋了融合CDN的local DNS灾备逻辑与比例配置，将云端的全局智能调度fail-over到客户端的本地兜底调度，并保持大数据统计层面的各CDN厂商的流量分配均衡。

同时：客户端也会有播放体验方面的容灾策略，诸如清晰度降级、线路调整等。