网宿超大规模直播运营优化之旅

近3年直播应用及技术快速发展，百万级并发在线成为常态，需要支持数TB直播及TB级别突发情况。在LiveVideoStack Meet广州站网宿科技吕士表分享了网宿直播平台发展历程及遇到的技术挑战和应对策略，并对展望未来发展趋势。

内容 / 吕士表

整理 / LiveVideoStack

我是来自网宿科技的吕士表，现在负责网宿流媒体产品线，很荣幸能够有机会跟大家分享。今天主要介绍网宿从流媒体创建至今的架构核心变化及关键点优化。CDN系统所涉及层面非常多，网络层、传输层及应用层都涉及很多技术。甚至仅传输协议优化就有很大的Team专职去做。

今天分享的主要内容有四大部分：首先是网宿直播平台的发展历程；发展过程中遇到哪些挑战，以及应对挑战所作的优化工作，最后是对直播未来场景的展望。

网宿直播平台发展历程

平台发展

网宿在08年对市面上所有直播相关的产品进行了评估，当时市场的大环境是多种协议、多种产品并存，包含Adobe的Flash Media Server（FMS）、微软的WMS、机顶盒上RTSP、HLS等等，。我们最后从中选择了支持两个协议，一个就是Adobe的RTMP协议，这个选择是因为flash在当时浏览器的普及率在90%以上；另一个选择是HTTP，因为当时点播大部分采用HTTP传输。直播技术方案选择HDL和HLS，我们认为直播未来主流技术会如此。

我们刚开始采用Adobe的FMS，即RTMP协议，但却发现了很多坑：机器带宽很低但总掉线了，可运维性很差，因为并不知道它每个环节到底是什么状态，系统未提高状态监测。因此，网宿开始自研底层传输框架——StreamCache平台，支持HTTP和RTMP模块，并可实现级联结构，梳理更环节指标并建立质量评估系统。因为当时RTMP是Adobe的私有协议，业界无开源方案。我们就逐帧分析协议实现了RTMP，后来也和多家第三方编码、推流的硬件厂商做适配与磨合。这个过程非常痛苦的。

2010年底，苹果使用HLS直播开发布会后，HLS也正式步入大规模应用。当时我们HLS和RTMP放在一起，基于RTMP做切片、封装，但存在一个问题：机器故障后切换到其它服务器，流会有时间同步等等问题。因此最终是StreamCache上切片，但通过CDN Cache分发。2012年又支持了P2P功能，对于热的流，当时P2P的延迟大概在15秒左右，可以做到80%的分享率。现在，当延迟和正常RTMP或者HDL差不多时，网宿的p2p 50%的分享率。

2015年斗鱼等直播企业的兴起，使得整个直播流量规模进入了另一个层面——从原本几十G、到几百G变成了TB级别。同时，网宿做了PaaS系统，以保证能够满足各类监管的要求，集成了鉴黄、录制、打水印、转码等功能。在去年直播元年——我个人更倾向于互动直播元年，像前端的连麦技术逐步成熟。网宿连麦及内容分发的接口开放出来，跟很技术服务商一起合作。同年，网宿也实现了对H265的支持。而今年则做了解决方案方案式的服务，这就是网宿整个发展的流程。

直播架构演变

网宿云直播架构v1.0

近10年的发展过程中，让我印象深刻的首先就是架构的改变。最初架构很简单，就是一个树型结构：在中心架设一个双线机器，全国布几十个节点可以提供服务。整个调度就是基础的DNS静态解析；采用 HLS及RTMP协议做级联，还有不少兼容性问题。

网宿云直播架构v3.0

到今天，直播的架构已经变得特别的复杂，功能方面也发生了很大的变化，从原来只做传输，到现在从采集侧、到编码推流、到传输、到最后解码播放，还有各种协议的转换，像截图、录制、鉴黄等配套的功能，转码以及一些分析系统，都是可以直接对外开放的，这是我们在过去很大的一个变化。

超大规模直播运营挑战

最有挑战的事情是规模，网宿在全球大概有一千多个节点——国内有700个节点，海外300多个节点。这必然会带来挑战——规模、调度，例如，要保证美国区域是能够访问到美国的节点上面，而传统DNS调度不是基于终端用户的IP库，而是DNS IP库，调度系统要准确映射；此外跨国会导致网络丢包和延时波动非常大，网宿在这方面也做了很多传输的工作。

核心挑战，除了功能之外，主要还是三个：第一个就是规模，它会涉及到服务器、网络、带宽、调度各个模块，包括整体的运营、并行监控，其次就是质量和成本。其实对于2B企业永远会面对的几个话题：首先就是技术或服务能力在行业内的水平如何？首屏怎么样？流畅率好不好？然后就是响应是否迅速？什么时候能完成部署？最后肯定是是否有足够的性价比？针对这三点我们也做了比较多的优化，以保证能够让平台持续跟上行业比较领先的状态。

超大规模直播优化之旅

规模：从GB到TB级别的优化

规模方面，我认为节点数量多只是其中一方面，更多的在于架构如何满足现实需求，比如南北互通的问题，只需要一台双线，或者再加上教育网、长宽就可以解决了。但是在T级别的规模下，就会有回源带宽规模问题。CDN内部回源机器可以分多层，每一层都可以通过配置去定位上游服务器，而且每个组作为集群扩展，包括横向扩展以及冷流调度。实现运营过程中，但我们发现边缘可扩展性才是最大的挑战，所以我们在边缘上也做了集群。

第一个阶段是用LVS，布几十台机器，用一个LVS或者VIP的方式对外服务，若服务器有故障直接把它踢掉，但也会带来一个问题——如果流很多，那流随机调度到每一台边缘，每台都要回源，怎么办？我们就开始在应用层做哈希，前端服务器先做判断，如果刚才已经有人访问过某台机房，那么流直接到这台机房就可以了，这个方法解决了扩展性问题以及首屏时间，因为在服务节点上已经有流，所以可以很快速的响应，如果要进一步优化首屏时间，那么可以选择设置2-3秒缓冲时间，把TCP传输发送窗口开更大一点，或者对RTMP传输再做相关的优化，都可以缩短首屏时间。但它并不能解决机器回源的带宽大的问题，所以我们对冷流和热流做了区分，这样可以降低比较大的内耗。热流可按树形回源，冷流就聚合回源，或不回源就地提供访问。网宿在每层服务都做了集群，甚至为减少回源站流量回源集群做了跨机房集群，可做到回源只有一路流。集群还要有很强大的管理系统把它串起来，能够高效的处理实时流的调度及回源管理。抽象来讲是把原来树型结构，转变为以树型为主体、网状兼顾，这样局部访问就不需要全局流量访问。

质量

第二点是质量，从直播的角度来看，每家客户对质量定义都不太一样，但最核心的基本是首屏时间、正确率/错误率、流畅率以及时延短。首先首屏时间，每家的要求和统计方式不太一样，有的是打开时间，有的是一秒内打开比例等等；正确/错误率非常重要的，它关系到是否能正常被打开；对流畅率的定义基本是从首次拿到关键帧开始播放后，在一段时间内出现卡顿即记为一次不流畅。另一个就是时延，你要做到均衡，比如你通过HLS延时很长。它原本就是为了满足足够广泛的网络情况，所以它可以比较好的抗抖动，突然的抖动可以被缓冲掉，所以HLS一个片3秒，先下载3个片再播放，你要做到九秒、十秒的延迟； RTMP可在延时三秒内比较流畅的播放。

影响质量的因素有很多，首先就是资源，直接来讲资源就是带宽，而带宽核心就是节点（机房及网络接入）。然后是软件、配置，以及运营平台是否足够强悍？网宿在解决这些问题时，要把相关因素做到最好的搭配：首先我们做了质量的可视化，因为一个无办法衡量的系统是无法运营的，更是无法优化的；第二个是尽量做到核心服务是要本地覆盖的，比如连麦互动的部分；第三点软件优化，如响应能力，是需要持续去做的；第四个是配置方面，比如服务器发送的Buffer的设置，是否设置长连接等等逐项优化；最后是刚刚提到的冷热分流。

• NGB系统

其中涉及到比较重要的部分是调度系统，我们的调度系统经历了三个大阶段：第一阶段是用静态的方式去做覆盖，也就是指定用户到当地的服务器节点访问，而为了保证突发会单独设置一个大的资源池，假设流量超过当地服务器的负载，就将新进来的业务调整到大的资源池里访问，若面临更大规模再大的节点也会承受不住，而且很不精确；第二阶段我们做了一个类似中心调度的方式，通过中心知道访问用户的IP，从而调度到相应节点上，这样就可以做到可扩展和精确度，但它同样存在还是按区域、按运营商来划分的，对内容冷热以及服务器的计算能力的关注是不够的；因此我们根据内容，我们根据内容的特性以及对流的使用用户数量做统计将其区分，冷流就用推流节点提供服务，热流则按离用户最近节点方式处理，如果层级性有突发，我们可以实时获取信息并处理。

• 终端实时优选

用户所处的网络环境时刻发成变化，当前时刻的最优节点在下一时刻就并非最佳，因此我们做了一个终端实时优选的方案，就是在客户播放器中一个嵌入轻量级的SDK，当其中出现卡顿时可以自动或手动切换到其他节点，这个方案其实更多是解决了后面5%的极端场景。网宿在细节处做了很多工作。

• 传输协议&SDN

接下来是传输方面，应用层，我们在底层也做了SDN。一开始只是做了TCP协议本身的优化——通过调整优化接入窗口、发生窗口、拥塞协议基本可以达到优化目标，但在跨运营商、跨地区的访问仅仅通过TCP这个比较有限的方式去做就很困难，因为TCP的设计原则上要保证效率的同时还要保证公平。所以在第二阶段我们引入了UDP，我们把在TCP上积累的经验总结到UDP上，然后将UDP模块整合到内核里，这样整个效率就变得非常高——在大规模的情况下，流畅率和达标率都有比较明显的提升。

• 全链路监控&离线分析系统

一个好的运营系统对大规模服务是非常重要的，我们从底层的网络层、到机器的层面、服务的层面、应用的层面，每一层都有相应的监控，我认为最困难的不是收集数据，而是将这些数据汇总起来并能从连锁反应中找出问题的关键，而数据只是基础。我们在应用层面用延时数据来计算传输的质量，从而评估到底是哪个环节是出现问题，为了减小数据延时，基本上按照5分钟一个点来做的。因为各家指标差异会很多，我们对部分指标做了细化，这样更方便去组合评估。再往下可以细化到每一路流，知道在推流的边缘、顶层的双线以及拉流的边缘的所有数据，包括丢帧、码率、延迟等等。此外我们搭建了离线分析系统，开源组件基本可完成。通过这个离线化平台可以分析各个环节质量数据。。

成本

成本应该说是行业中最关注的点，从优化的角度来看，成本结构主要是硬件加软件，带宽的复用程度也比较重要。硬件方面包括单机能力、设备选型以及机器冗余方案。带宽方面，我们目前已经能够实现成本加质量、再加应用内容结合起来去做全球调度；同时我们在内部传输的消耗上也做了很多的优化，包含在推流的边缘节点直接对外服务的方式，它一方面可以保证当地或者大区域的用户体验足够好，另一方面也能够减少自身的内耗；另外我还通过机器学习的方式根据历史数据识别流的冷热，并辅以应用数据修正，最终完成相应的调度，把带宽的利用率做到最好。最后在研发方面，我们在做全平台的虚拟化、组件化和API化。

未来演进

对于2B业务而言，商业核心就是更有效率地做事，所以规模是前提，质量、成本、效益是关键。另外直播已经将近十年时间，标准化也成为一件很重要的事情，包括H265、P2P、RTMP等协议的标准化、接口的标准化，对行业发展是有帮助的。在4K和VR的普及也会推动整个节点更加的下沉，这个不仅仅是分发，在计算方面可能也是这样的，因为VR本身对低时延的要求，现在中心式的数据服务是不现实的。

H.265普及

苹果在6月份开发者大会表示iOS和mac系统支持H.265，网宿在去年已经做了全平台支持H.265，但目前比较大的问题实际是适配的问题，虽然苹果操作系统支持，但硬件方面是否支持待确认；而安卓在15年10月之后98%的机器支持H.265的硬解，但硬编还会差一些。针对这个问题，我们做了适配库，大家可以根据适配库的反馈决定最终使用H265软编软解或其他编码（如h264）。

实时互动趋势

我们现在处于一个实时互动的大社区，对于低延时要求也越来越多。相比过去的设备，现在手机本身的计算能力、接入的宽带、移动网络都完全可以取代过去会议系统的硬件。这无疑会直接的改变未来使用互联网方式。在这样的大环境下，以后是否可以满足不限于几个人的小房间实时互动（类似连麦），而是让更多的人享受实时的服务呢？我认为这是非常值得期待的事情，而WebRTC及服务端开源后，WebRTC有可能成为特别流行技术方案。

云导播——直播加速

最后是服务方面，传统的导播会慢慢迁到互联网上。企业自身解决音视频在线合并、特别是音视频同步等是很麻烦的，所以网宿做了云导播系统。网宿云导播可以使用网宿线上几千台转码服务器实时、大规模解决这些困难，使用方式也很简单，可以通过API的方式对多路流进行拼装——单音画切换、画中画、多画面同屏，我认为它能够让内容未来有更多的玩法。

LiveVideoStack Meet：WebRTC开发及实践

伴随视频直播市场的持续火热，互联网+视频行业也在积极寻求在秀场和游戏直播外的领域，如互动游戏、在线教育、电商、互联网金融等，而WebRTC技术经过业界的共同努力也已经发展成为互联网音视频通信的主流技术，生态日渐完善，未来将成为企业音视频应用中不可或缺的技术。

11月16日 | 音视频技术社区LiveVideoStack联合英特尔走进上海，携手阿里巴巴、爱奇艺、Zealcomm等企业技术大咖，与大家一同探讨基于WebRTC的在线实时互动服务的构建，服务平台的设计、解析及应用，以及结合机器学习和虚拟现实技术的视频分析与沉浸式体验开发，更有基于WebRTC的现场实践演示和动手实验室。