流媒体地址（流媒体服务器架构与应用分析）

　　流媒体地址（流媒体服务器架构与应用分析）
　　1。应用场景
　　目前在流媒体领域，有很多应用场景。由于网络服务升级，越来越多的行业开始使用音视频互动作为最快速的通信工具。我相信在5G正真普及时，会有更多的传统行业会借助流媒体，能够实现快速升级，提高生产效率。目前视频互动，远程教育和医疗，直播带货等等，这些行业，都使用流媒体技术，带来了产业腾飞。
　　直播主要功能
　　主要功能如下，这些功能中，处了直播，录播等，还有些其它技术，包括聊天通信，刷礼物，直播列表，房间，系统设置等。这些技术里，有些是需要后台支撑，有些是要前端展现，如果想要成为一个CTO或系统架构师，这些都是必备的技能。
　　直播平台系统架构图
　　下面这张图就是一个直播平台系统架构图，这张架构图，包括了非常多的技术。其中包括，前端音视频推流，Nginx负载均衡，反向代理，应用网关集群，服务注册中心集群，业务服务集群，存储服务，区域部署，redis集群，直播集群，中间件等。其中画红色框框部分，就是流媒体需要的技术，这里面也有很多学问，也是需要重点关注。比如推流到分布式流媒体服务器，如果边缘服务器部署到不同城市，那处在不同城市的观众，根据边缘计算，会使用相应的服务器。作为主播端，如果推送到不同的边缘服务器，首先要回源，回源（不一定是必须，需要根据调度策略计算，比如热门视频需要回源，一些冷门视频就不回源）后，在传输到不同的边缘服务器，这样转发给不同的地方观众去拉取。
　　注意：专业的CDN，一般都是有专线。集群一般都是在内网搭建，分布式一般是指外网部署。
　　如果把架构分层，那可以分为访问层，数据接入层，接口层，业务服务层。其中访问层包括PC客户端，H5、微信接入。访问层接通WEB和APP。数据接入层主要是Nginx做负载均衡，API网关，提供各类服务，包括日志管理，权限控制，监控管理，流量监控，路由服务，支付服务等。接口层包括第三方API及接口服务和后台管理，比如推流服务，拉流服务，CDN服务，还有一些用户后台，用户管理等。推流服务主要功能，比如视频直播、录播，录屏，边缘加速，数据分发，互动。后台服务包括直播管理，录播管理，转码管理，支付管理，订单管理，流量管理，内存监控，短信和邮件管理，会员管理等。业务服务层主要就是各类需求相关的服务，如用户服务，讲师服务，直播服务等，一些账号，收费，讲师等相关业务需求。最后就是穿梭各层的公共组件，如支付组件，登陆注册，短信组件等。整体来说这些东西很复杂，但是要想成为CTO，技术的广度和深度都是必不可少。希望这2张图，能够成为你我共同的发展蓝图。
　　注意：一些鉴权，防盗链机制，都是一些token机制，都是可以借鉴阿里云做法。
　　直播框架简化版
　　直播框架简化后如下，推流端主要包括音视频采集，音视频处理，音视频编码，音视频推流。拉流端主要包括音视频解码，音视频同步，音视频播放。音视频采集在不同平台都有不同方案。然后送入音视频处理，音频如混音，降噪等，视频如水印，美颜等，这些都很重要，如果音频不消除噪声，主播不美颜，用户体验会很差。音视频编码，指定编码为不同格式，然后封装，推流到流媒体服务器。在拉流端，主要就是解封装，音视频解码，音视频同步，音视频播放。其中音视频解码，同步，播放，在不同平台都有不同的方案。
　　直播流程和技术栈
　　在采集和推流端，一般常用框架有FFmpeg框架，X264框架，open264框架，fdkaac框架，librtmp框架，OpenGL框架，OpenCV框架。FFmpeg框架一般可以用提供的接口做解封装、编解码、推流，使用这种方法，需要注意的是buffer比较难控制。X264框架一般用于做视频编码，属于更加偏向底层。openh264框架也是用于做视频编码，效率更高。fdkaac框架一般用于做音频编码，也是更偏向底层了。librtmp框架用于做音视频推流，也是更偏向底层。OpenGL框架一般用于视频渲染和视频处理，如滤镜处理，效果也是非常好，是常用的方案之一。OpenCV框架一般用于做视频处理，也可以用于解码等操作，OpenCV也调用了FFmpeg的某些功能，也是常用方案之一。
　　在流媒体服务器，一般流媒体服务器有数据分发、实时转码、截屏、录制视频等。数据分发就包括了一些CDN。截屏可以应用于封面。录制视频一般用于审核视频或回放使用。常用服务器有nginxrtmpmodule、SRS（这个也是常用方案之一，使用协程框架，效率很高），Red5（这个是java版本）。
　　在播放端，一般有拉取视频，解码，渲染，聊天互动功能。常用框架有FFmpeg框架，ijkPlayer框架，OpenGL框架，SDL框架。FFmpeg框架可直接用于解码。ijkPlayer是哔哩哔哩一整套基于FFplay开源二次封装框架。OpenGL框架（win和android端都有）一般用于视频处理和渲染。SDL框架（大都用于win端）一般用于渲染。
　　ijkplayer：基于FFmpeg的开源AndroidiOS视频播放器。
　　有以下优点：
　　API易于集成。
　　编译配置可裁剪，方便控制安装包大小。
　　支持硬件加速解码，更加省电。
　　简单易用，指定拉流URL，自动解码播放。
　　缺点：
　　不能满足一些播放器，定制化需求。
　　延时高。
　　所以根据优点和确定选择合适的方案。
　　压测工具
　　SRS自带工具：stload
　　流媒体服务器简介
　　SRS：一款国人开发的优秀开源流媒体服务器系统。
　　BMS：也是一款流媒体服务器系统，但不开源，是SRS的商业版，比SRS功能更多。
　　nginx：免费开源web服务器，也常用来配置流媒体服务器。集成Rtmpmodule即可。
　　Red5：是java写的一款稳定的开源的rtmp服务器。
　　CDN
　　CDN的全称是ContentDeliveryNetwork，即内容分发网络。CDN是构建在现有网络基础之上的智能虚拟网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术。
　　CDN网络中包含的功能实体包括内容缓存设备、内容交换机、内容路由器、CDN内容管理系统等组成。内容缓存为CDN网络节点，位于用户接入点，是面向最终用户的内容提供设备，可缓存静态Web内容和流媒体内容，实现内容的边缘传播和存储，以便用户的就近访问。
　　内容交换机处于用户接入集中点，可以均衡单点多个内容缓存设备的负载，并对内容进行缓存负载平衡及访问控制。
　　内容路由器负责将用户的请求调度到适当的设备上。内容路由通常通过负载均衡系统来实现，动态均衡各个内容缓存站点的载荷分配，为用户的请求选择最佳的访问站点，同时提高网站的可用性。内容路由器可根据多种因素制定路由，包括站点与用户的临近度、内容的可用性、网络负载、设备状况等。负载均衡系统是整个CDN的核心。负载均衡的准确性和效率直接决定了整个CDN的效率和性能。内容管理系统负责整个CDN的管理，是可选部件，作用是进行内容管理，如内容的注入和发布、内容的分发、内容的审核、内容的服务等。
　　归纳起来，CDN具有以下主要功能：
　　（1）节省骨干网带宽，减少带宽需求量；
　　（2）提供服务器端加速，解决由于用户访问量大造成的服务器过载问题；
　　（3）服务商能使用WebCache技术在本地缓存用户访问过的Web页面和对象，实现相同对象的访问无须占用主干的出口带宽，并提高用户访问因特网页面的相应时间的需求；
　　（4）能克服网站分布不均的问题，并且能降低网站自身建设和维护成本；
　　（5）降低通信风暴的影响，提高网络访问的稳定性。
　　CDN关键技术内容发布
　　它借助于建立索引、缓存、流分裂、组播（Multicast）等技术，将内容发布或投递到距离用户最近的远程服务点（POP）处。内容分发包含从内容源到CDN边缘的Cache的过程。从实现上，有两种主流的内容分发技术：PUSH和PULL。
　　PUSH是一种主动分发的技术。通常，PUSH由内容管理系统发起，将内容从源或者中心媒体资源库分发到各边缘的Cache节点。分发的协议可以采用Httpftp等。通过PUSH分发的内容一般是比较热点的内容，这些内容通过PUSH方式预分发（Preload）到边缘Cache，可以实现有针对的内容提供。对于PUSH分发需要考虑的主要问题是分发策略，即在什么时候分发什么内容。一般来说，内容分发可以由CP（内容提供商）或者CDN内容管理员人工确定，也可以通过智能的方式决定，即所谓的智能分发，它根据用户访问的统计信息，以及预定义的内容分发的规则，确定内容分发的过程PULL是一种被动的分发技术，PULL分发通常由用户请求驱动。当用户请求的内容在本地的边缘Cache上不存在（未命中）时，Cache启动PUL方法从内容源或者其他CDN节点实时获取内容。在PULL方式下，内容的分发是按需的。内容路由
　　它是整体性的网络负载均衡技术，通过内容路由器中的重定向（DNS）机制，在多个远程POP上均衡用户的请求，以使用户请求得到最近内容源的响应。
　　CDN负载均衡系统实现CDN的内容路由功能。它的作用是将用户的请求导向整个CDN网络中的最佳节点。最佳节点的选定可以根据多种策略，例如距离最近、节点负载最轻等。负载均衡系统是整个CDN的核心，负载均衡的准确性和效率直接决定了整个CDN的效率和性能。通常负载均衡可以分为两个层次：全局负载均衡（GSLB）和本地负载均衡（SLB）。全局负载均衡主要的目的是在整个网络范围内将用户的请求定向到最近的节点（或者区域）。因此，就近性判断是全局负载均衡的主要功能。本地负载均衡一般局限于一定的区域范围内，其目标是在特定的区域范围内寻找一台最适合的节点提供服务，因此，CDN节点的健康性、负载情况、支持的媒体格式等运行状态是本地负载均衡进行决策的主要依据。内容存储
　　对于CDN系统而言，需要考虑两个方面的内容存储问题。一个是内容源的存储，一个是内容在Cache节点中的存储。
　　对于内容源的存储，由于内容的规模比较大（通常可以达到几个甚至几十个TB），而且内容的吞吐量较大，因此，通常采用海量存储架构，如NAS和SON。对于在Cache节点中的存储，是Cache设计的一个关键问题。需要考虑的因素包括功能和性能两个方面：功能上包括对各种内容格式的支持，对部分缓存的支持；在性能上包括支持的容量、多文件吞吐率、可靠性、稳定性。
　　其中，多种内容格式的支持要求存储系统根据不同文件格式的读写特点进行优化，以提高文件内容读写的效率。特别是对针对流媒体文件的读写。部分缓存能力指流媒体内容可以以不完整的方式存储和读取。部分缓存的需求来自用户访问行为的随机性，因为许多用户并不会完整地收看整个流媒体节目。事实上，许多用户访问单个流媒体节目的时间不超过10分钟。因此，部分缓存能力能够大大提高存储空间的利用率，并有效提高用户请求的响应时间。但是部分缓存可能导致内容的碎片问题，需要进行良好的设计和控制。
　　Cache存储的另一个重要因素是存储的可靠性，目前，多数存储系统都采用了独立磁盘冗余阵列（RAID）技术进行可靠存储。但是不同设备使用的RAID方式各有不同。内容管理
　　它通过内部和外部监控系统，获取网络部件的状况信息，测量内容发布的端到端性能（如包丢失、延时、平均带宽、启动时间、帧速率等），保证网络处于最佳的运行状态。
　　内容管理在广义上涵盖了从内容的发布、注入、分发、调整、传递等一系列过程。在这里，内容管理重点强调内容进人Cache点后的内容管理，称其为本地内容管理。本地内容管理主要针对一个ODN节点（有多个CDNCache设备和一个SLB设备构成）进行。本地内容管理的主要目标是提高内容服务的效率，提高本地节点的存储利用率。通过本地内容管理，可以在CDN节点实现基于内容感知的调度，通过内容感知的调度，可以避免将用户重定向到没有该内容的Cache设备上，从而提高负载均衡的效率。通过本地内容管理还可以有效实现在ODN节点内容的存储共享，提高存储空间的利用率。
　　关于CDN，也是很复杂，下面这张图，可以简单的说明。
　　采集端业务逻辑
　　（1）一般在客户端，都会先创建房间，请求创建直播流地址。
　　（2）流媒体服务器会返回一个直播流地址给采集端。
　　（3）采集端拿到直播流地址，就把编码，封装后的码流推送到流媒体服务器上去。
　　注意：不同采集端，所生成地址都是不一样，不固定。
　　播放端逻辑
　　（1）播放端，向业务服务器查询房间列表。
　　（2）业务服务器返回房间列表及播放地址给播放端。这个一般就是自动生成。
　　（3）播放端拿到地址后，就可以拉取流媒体服务器内容。
　　推流拉流模块
　　（1）在推流端，一般包括音视频采集，同步，编码，复用，发送。
　　（2）在拉流端，一般包括音视频解封装，解码，同步，显示。
　　注意：
　　（1）在推流端，会实时监测编码后队列的数据，当网络不好的时候，视频队列会把非I帧或一组GOP全部丢掉，降低延时。把音频队列数据取出来，然后重新解码，重采样，如实现变速播放，降低延时。
　　（2）在推流端，实现数据加密，一般是在编码后。如果在编码前加密，数据量太大了。
　　（3）直播一般都不用B帧或减少B帧，为什么呢？因为B帧会增加延时时间，解码B帧是需要参考I帧和P帧，所以B帧需要缓存，如果B帧越多，那么缓存的时间就越长，这样延时就越大。
　　缓冲控制
　　（1）确定延时时间
　　实时采集画面与播放展示画面的时间差，一般就是用手机拍照，同时拍下采集与播放画面，看看延时时间差。如下图：
　　一般当网络抖动较大，数据堆积导致GOP缓存过多，降低延时实际也是在怎样实时改变缓存的大小。
　　（2）首帧秒开
　　如果CDN节点级数越多耗时，首帧秒开考验的是直播CDN的组网方式，网络覆盖率和传输协议的优化程度。一般首帧秒开，服务器需要提前缓存一组GOP，客户端发起拉流请求，服务器会把缓存的一组GOP发送到客户端，这样一组完整的GOP，保证客户端接收的第一帧就是I帧，可以达到首帧秒开。但是由于服务器提前缓存了，所以回带来播放延时。这两者是冲突了，所以设计的时候，就需要折中考虑。
　　策略
　　预热：提前拉取热门直播。
　　集群：通过CDN内容分发调度，就近共享数据。
　　（3）卡顿
　　卡顿一般在推流端，CDN内部，客户端发生。在设计时最好能够统计卡顿次数或时长。
　　根据上面分析，延时、首屏、卡顿本质都涉及到buffer控制。
　　质量监控
　　推流端，CDN、播放端都会有相应的监控。通过分析，选择相应策略。
　　CDN监控
　　具体指标如下：
　　建立连接时间、首帧时间、缓存大小、帧率、码率、丢帧等。
　　拉流端和播放端监控：
　　DNS解析时间、建立连接时间、首帧时间、缓存大小，帧率，码率，丢帧，码率，卡顿率，失败率等。
　　关于卡顿原因分析
　　卡顿原因一般有音视频不同步，丢视频，丢音频，画质低，帧率低，时间戳异常，采集丢帧，采集端送入编码端不是完整帧等。
　　解决办法一般有增加带宽，优化编码参数，调整资源，修复时间戳增量，使用动态缓冲区等。
　　卡顿排查
　　（1）网络卡顿
　　观察是全网卡顿，还是局部卡顿。全网卡顿查上行带宽（全网卡也有可能是流异常，如码率过大），局部卡顿查下行带宽。所以在推流端和播放端一般都有这种卡顿的可能。
　　（2）推流卡顿
　　推流路径监控
　　是否频繁断开。
　　推流端是否推送速度不够。
　　内部上行是否推送速度不够。
　　常见原因
　　推流端网络问题。如ping推流点，speedtest测速。
　　连接的推流点不合理。可能是调度问题，也可能是dns配置不对或localdns不对。
　　内部链路问题。查丢包。
　　节点高负载（cpu、内存、io、带宽、机房带宽等）。
　　（3）拉流卡顿
　　部分区域卡顿高
　　常见原因：
　　丢包。
　　高负载（cpu、内存、io、带宽、机房带宽）。
　　节点覆盖。
　　关于播放异常分析
　　（1）时间戳问题
　　时间戳跳变。
　　音视频差距大。
　　如何验证？
　　可以播放原流来验证，是原流问题，还是播放异常。
　　（2）声音异常
　　网络抖动导致没有声音播放。
　　（3）黑屏
　　metadata是否正常，如果没有正确读出metadata，会出现黑屏问题。
　　是否有视频sequenceheader。比如用工具查看，是否解析到SPS、PPS、SEI。
　　原视频是否有视频帧数据，有可能本身就是黑屏数据。
　　音视频时间戳是否单增。