近3年直播应用及技术快速发展，百万级并发在线成为常态，需要支持数TB直播及TB级别突发情况。在LiveVideoStackMeet广州站网宿科技吕士表分享了网宿直播平台发展历程及遇到的技术挑战和应对策略，并对展望未来发展趋势。
内容/吕士表
整理/LiveVideoStack
我是来自网宿科技的吕士表，现在负责网宿流媒体产品线，很荣幸能够有机会跟大家分享。今天主要介绍网宿从流媒体创建至今的架构核心变化及关键点优化。CDN系统所涉及层面非常多，网络层、传输层及应用层都涉及很多技术。甚至仅传输协议优化就有很大的Team专职去做。
今天分享的主要内容有四大部分：首先是网宿直播平台的发展历程；发展过程中遇到哪些挑战，以及应对挑战所作的优化工作，最后是对直播未来场景的展望。
网宿直播平台发展历程
平台发展
网宿在08年对市面上所有直播相关的产品进行了评估，当时市场的大环境是多种协议、多种产品并存，包含Adobe的FlashMediaServer（FMS）、微软的WMS、机顶盒上RTSP、HLS等等，。我们最后从中选择了支持两个协议，一个就是Adobe的RTMP协议，这个选择是因为flash在当时浏览器的普及率在90%以上；另一个选择是HTTP，因为当时点播大部分采用HTTP传输。直播技术方案选择HDL和HLS，我们认为直播未来主流技术会如此。
我们刚开始采用Adobe的FMS，即RTMP协议，但却发现了很多坑：机器带宽很低但总掉线了，可运维性很差，因为并不知道它每个环节到底是什么状态，系统未提高状态监测。因此，网宿开始自研底层传输框架——StreamCache平台，支持HTTP和RTMP模块，并可实现级联结构，梳理更环节指标并建立质量评估系统。因为当时RTMP是Adobe的私有协议，业界无开源方案。我们就逐帧分析协议实现了RTMP，后来也和多家第三方编码、推流的硬件厂商做适配与磨合。这个过程非常痛苦的。
年底，苹果使用HLS直播开发布会后，HLS也正式步入大规模应用。当时我们HLS和RTMP放在一起，基于RTMP做切片、封装，但存在一个问题：机器故障后切换到其它服务器，流会有时间同步等等问题。因此最终是StreamCache上切片，但通过CDNCache分发。年又支持了P2P功能，对于热的流，当时P2P的延迟大概在15秒左右，可以做到80%的分享率。现在，当延迟和正常RTMP或者HDL差不多时，网宿的p2p50%的分享率。
年斗鱼等直播企业的兴起，使得整个直播流量规模进入了另一个层面——从原本几十G、到几百G变成了TB级别。同时，网宿做了PaaS系统，以保证能够满足各类监管的要求，集成了鉴黄、录制、打水印、转码等功能。在去年直播元年——我个人更倾向于互动直播元年，像前端的连麦技术逐步成熟。网宿连麦及内容分发的接口开放出来，跟很技术服务商一起合作。同年，网宿也实现了对H的支持。而今年则做了解决方案方案式的服务，这就是网宿整个发展的流程。
直播架构演变
网宿云直播架构v1.0
近10年的发展过程中，让我印象深刻的首先就是架构的改变。最初架构很简单，就是一个树型结构：在中心架设一个双线机器，全国布几十个节点可以提供服务。整个调度就是基础的DNS静态解析；采用HLS及RTMP协议做级联，还有不少兼容性问题。
网宿云直播架构v3.0
到今天，直播的架构已经变得特别的复杂，功能方面也发生了很大的变化，从原来只做传输，到现在从采集侧、到编码推流、到传输、到最后解码播放，还有各种协议的转换，像截图、录制、鉴黄等配套的功能，转码以及一些分析系统，都是可以直接对外开放的，这是我们在过去很大的一个变化。
超大规模直播运营挑战
最有挑战的事情是规模，网宿在全球大概有一千多个节点——国内有个节点，海外多个节点。这必然会带来挑战——规模、调度，例如，要保证美国区域是能够访问到美国的节点上面，而传统DNS调度不是基于终端用户的IP库，而是DNSIP库，调度系统要准确映射；此外跨国会导致网络丢包和延时波动非常大，网宿在这方面也做了很多传输的工作。
核心挑战，除了功能之外，主要还是三个：第一个就是规模，它会涉及到服务器、网络、带宽、调度各个模块，包括整体的运营、并行监控，其次就是质量和成本。其实对于2B企业永远会面对的几个话题：首先就是技术或服务能力在行业内的水平如何？首屏怎么样？流畅率好不好？然后就是响应是否迅速？什么时候能完成部署？最后肯定是是否有足够的性价比？针对这三点我们也做了比较多的优化，以保证能够让平台持续跟上行业比较领先的状态。
超大规模直播优化之旅
规模：从GB到TB级别的优化
规模方面，我认为节点数量多只是其中一方面，更多的在于架构如何满足现实需求，比如南北互通的问题，只需要一台双线，或者再加上教育网、长宽就可以解决了。但是在T级别的规模下，就会有回源带宽规模问题。CDN内部回源机器可以分多层，每一层都可以通过配置去定位上游服务器，而且每个组作为集群扩展，包括横向扩展以及冷流调度。实现运营过程中，但我们发现边缘可扩展性才是最大的挑战，所以我们在边缘上也做了集群。
第一个阶段是用LVS，布几十台机器，用一个LVS或者VIP的方式对外服务，若服务器有故障直接把它踢掉，但也会带来一个问题——如果流很多，那流随机调度到每一台边缘，每台都要回源，怎么办？我们就开始在应用层做哈希，前端服务器先做判断，如果刚才已经有人访问过某台机房，那么流直接到这台机房就可以了，这个方法解决了扩展性问题以及首屏时间，因为在服务节点上已经有流，所以可以很快速的响应，如果要进一步优化首屏时间，那么可以选择设置2-3秒缓冲时间，把TCP传输发送窗口开更大一点，或者对RTMP传输再做相关的优化，都可以缩短首屏时间。但它并不能解决机器回源的带宽大的问题，所以我们对冷流和热流做了区分，这样可以降低比较大的内耗。热流可按树形回源，冷流就聚合回源，或不回源就地提供访问。网宿在每层服务都做了集群，甚至为减少回源站流量回源集群做了跨机房集群，可做到回源只有一路流。集群还要有很强大的管理系统把它串起来，能够高效的处理实时流的调度及回源管理。抽象来讲是把原来树型结构，转变为以树型为主体、网状兼顾，这样局部访问就不需要全局流量访问。
质量
第二点是质量，从直播的角度来看，每家客户对质量定义都不太一样，但最核心的基本是首屏时间、正确率/错误率、流畅率以及时延短。首先首屏时间，每家的要求和统计方式不太一样，有的是打开时间，有的是一秒内打开比例等等；正确/错误率非常重要的，它关系到是否能正常被打开；对流畅率的定义基本是从首次拿到关键帧开始播放后，在一段时间内出现卡顿即记为一次不流畅。另一个就是时延，你要做到均衡，比如你通过HLS延时很长。它原本就是为了满足足够广泛的网络情况，所以它可以比较好的抗抖动，突然的抖动可以被缓冲掉，所以HLS一个片3秒，先下载3个片再播放，你要做到九秒、十秒的延迟；RTMP可在延时三秒内比较流畅的播放。
影响质量的因素有很多，首先就是资源，直接来讲资源就是带宽，而带宽核心就是节点（机房及网络接入）。然后是软件、配置，以及运营平台是否足够强悍？网宿在解决这些问题时，要把相关因素做到最好的搭配：首先我们做了质量的可视化，因为一个无办法衡量的系统是无法运营的，更是无法优化的；第二个是尽量做到核心服务是要本地覆盖的，比如连麦互动的部分；第三点软件优化，如响应能力，是需要持续去做的；第四个是配置方面，比如服务器发送的Buffer的设置，是否设置长连接等等逐项优化；最后是刚刚提到的冷热分流。
NGB系统
其中涉及到比较重要的部分是调度系统，我们的调度系统经历了三个大阶段：第一阶段是用静态的方式去做覆盖，也就是指定用户到当地的服务器节点访问，而为了保证突发会单独设置一个大的资源池，假设流量超过当地服务器的负载，就将新进来的业务调整到大的资源池里访问，若面临更大规模再大的节点也会承受不住，而且很不精确；第二阶段我们做了一个类似中心调度的方式，通过中心知道访问用户的IP，从而调度到相应节点上，这样就可以做到可扩展和精确度，但它同样存在还是按区域、按运营商来划分的，对内容冷热以及服务器的计算能力的北京哪治白癜风最好北京中科医院正规吗