已阅读
如何用免费CDN加速设计一套RTC PaaS服务
目前实时音视频通信RTC(Real-Time Communication) 服务常见的有两种形态：SaaS(Software as a Service)和PaaS(Platform as Service)[1]
SaaS服务往往是一个大的集合。如在线教育场景，不仅包含RTC服务，还包含一系列线上上课流程所需的基础服务保障和提升上课效率、体验的一些列教具，如即时通信IM服务、课程管理系统、互动课件和电子白板、点播回放等。
PaaS服务则聚焦音视频实时通信的能力，依托音频3A前处理(回声消除、噪声抑制和自动增益控制算法)、音视频编解码、信道传输、弱网对抗、网络调度等技术，为用户提供高可用、高品质、低延时的音视频通信服务。用户可通过集成不同平台的SDK，快速搭建多端实时应用，在项目中实现语音通话、视频通话、音频互动直播、视频互动直播等，适用于在线教育、视频会议、互动娱乐、音视频社交等场景。
1、面临的问题和挑战
首先从需求和问题出发，对于公有云RTC PaaS服务来说，先抛开不同平台音视频设备采集、编码、网络发送、网络接收、解码、渲染的差异不谈，主要围绕的问题就是如何在当前复杂、不稳定的公有云环境下提供高可用、高质量、低延时的音视频通话服务，而其中几个主要影响音视频QOS(Quality of Service)[2]的因素[3]主要包含以下几个方面：
-
网络延时(Latency/Delay) -
网络丢包(Packect Loss) -
网络乱序(Out-of-order delivery) -
网络抖动(Jitter) -
网络拥塞(Bandwidth Overuse/network congestion)
所以如何设计服务的架构，提供一张优质、高效的网络传输链路和一系列保证弱网情形下音视频QOS的手段或策略，则显得尤为重要。对于网络这一层，往往是优先解决用户最后一公里的问题，这也是跟传统的边缘节点或者免费CDN加速的思路一脉传承。
2、RTC服务架构
按照功能划分，设计一套完整的RTC PaaS服务[4]，需要完成：
-
调度服务器(Coordinator)
因为无论如何优化压缩算法和代码，网络仍然是贡献大部分延时至关重要的因素，服务架构需提供一种机制，保证用户就近接入负载最低的最优媒体节点，来减少RTT(Round Trip Time)和尽可能保证用户最后一公里的网络质量，这就是调度服务器的价值所在。
如上图steps 1、2所示，当新用户接入RTC服务时，首先请求调度服务器获取可用媒体服务器的列表，调度服务器通过请求中携带的用户的外网IP获取用户的地理位置和运营商信息，按照一定的策略返回媒体服务器列表，然后在step 3，客户端通过ping消息探测与所有候选媒体服务器之间的实时网络状况，从而选择最佳的媒体服务器进行推拉流。这些探测获取到的网络状况列表，特别是延时信息，将稍后被反馈发送至调度服务器，以致于它能够更加准确地分配最合适的媒体服务器，服务于后续新的用户。
-
信令服务器(Signaling Server)
设计一个视频会议系统，信令协商和消息交互是一个必不可少的部分，不过我一直主张：「轻信令重媒体」，「在保证必要消息交互的前提下尽可能减少消息交互的次数和消息体的大小，怎么简单怎么来」。对于信令服务器的设计，建议简洁、够用即可。如上图所示，建议一种思路，将「轻薄」的信令服务也放在媒体服务器这一侧，这样不仅维护起来比较方便，而且媒体服务器能够独立于其他服务对外提供服务，即使其他服务出现异常也不受影响。另外测试和排查问题也更加高效便捷。缺点就是对于调度服务器来说，获取到的用户媒体信息有限，对于负载消耗的预估、控制不能很精细。
在这里，想讨论一个问题，「RTC PaaS服务一定需要会议、Channel或者房间的概念吗？」
对于这个问题，我认为可以抽象为「长连接vs短连接」的问题， 因为对于同一个会议或者房间这种概念，听的更多的是来自于IM即时通讯，在房间里的人能够立马收到或者消费其他人发送的消息，而且能感知其他人在线或者离线的状态。对于RTC PaaS服务来说，目前有两种方式供用户使用：
在信令层面上，还想讨论的是在抗弱网的表现上，tcp明显不如udp，所以往往会存在媒体传输还可以信令却无法建立的情形，所以建议在信令层面上可以尝试udp的可靠传输，如QUIC[5]等。
-
「无会议、房间的概念，不打包长连接服务」。使用方在使用SDK进行推拉流时，不用先JoinChannel或者JoinRoom，只需通过调度服务器拿到媒体服务列表之后选择一个最优节点进行推拉流即可。而此时RTC PaaS服务本身无法感知与会者的加入和离开，对于拉流动作只能依赖SDK的定时不断重试去保证，不能提供消息的发布(Publish)和订阅(Subscribe)。好处当然是不用去新开发一个类似IM的服务，要做一个稳定高效的长连接IM服务同样不是很容易，而且开发逻辑和调用流程都很简单；相反，就必须牺牲一些东西，如SDK侧拉流动作需要不断重试，这个就显得不是很优雅，另外由于缺乏长连接，服务端无法感知端上的实际在线状态，如客户端Crash，很多消息无法正常触发。对于某些任务session或记录的销毁严重依赖端上消息的抵达，否则的话就只能依赖定时超时去清理。
适合的场景：很多业务使用方往往有自己的IM即时通信服务，因为现在的app在线长连接和直播间内发消息、点赞、送礼物等基本上已成为标配，所以可以依赖偏上层业务的信道消息去实现消息的发布和订阅，从而决定推拉流的时机。
-
「有会议、房间的概念，打包长连接服务」。与第一种情况相反，这种情况下就需要为使用方提供稳定高效的IM服务，一般情况下，可使用websocket+消息队列(如RabbitMQ)的方式来实现，使用方在使用SDK进行推拉流前，必须先JoinChannel或者JoinRoom，然后才能订阅或者消费消息，从而在其他人加入、离开房间或者推流时收到通知后去处理相应的回调。对应的由于长连接的存在，服务端能够准确感知客户端的状态，当用户离线时，及时清理任务session或记录。
适合的场景：有些小公司没有能力开发自己的IM服务，从他们的角度来说，给我提供一整完整的解决方案即可，我不需要care其他的技术细节，只需要知道什么样的事件回调执行什么调用即可。
-
-
媒体服务器(Media Server或者Streaming Server)
所有媒体服务器是完全独立的，当一个服务器加入或者离开RTC网络时，系统能自动调整它的分配，不让用户有感知和影响。在高负载的情况下，可以通过新增机器部署服务来进行「水平扩展」(horizontal scaling)。
媒体服务器一般按照网络拓扑架构可以划分为两大类[6]：「SFU(Selected Forward Unit)「和」MCU(Multipoint Control Unit)」。
如图所示，SFU只负责媒体流的转发，不做太多复杂的媒体处理，瓶颈在IO，并发能力强；劣势是下行转发路数多，带宽占用高，对用户侧带宽和设备的要求高。MCU除了媒体流的接收/发送，还要进行转码和混流，对服务器性能要求高，服务部署成本高，瓶颈在CPU，并发能力差，转发流数少，而且实时传输系统中，转码会带来额外的延时，实时性稍差；优势就是下行带宽占用少，对用户侧带宽和设备的要求低。
对于实时性和高并发有强要求的会议场景，更多的是选择SFU架构。随着未来5G技术的推广，可以预见带宽越来越不是问题，SFU的优势会更加明显。
然而在实际业务场景中，服务架构往往是「SFU+MCU混合」的方式去满足业务的需求。那么问题来了，是将MCU和SFU做在一起呢？即该服务既可以转发也可以混流，还是SFU和MCU完全独立，转发路径上的媒体节点都是单纯的SFU呢？
因为从媒体处理流程和功能层面上，SFU可视为MCU的子集，MCU支持一定的转发能力，比如混流完成后可选择不同的媒体封装输出方式，可直接被客户端拉流(这个就是MCU也具有SFU的功能了)。
如图所示，建议将不同能力分由不同的节点来实现[7]，如转发服务SFU节点负责媒体的转发和跨国级联，混流服务器MCU节点负载转码、混音和混流，因为这样服务的设计能尽量简单，耦合性低，同时对于不同类型的服务调度策略也能简单很多，降低整体系统的复杂度和提高效率。
对于一套完整的RTC PaaS服务来说，往往需要将各种能力补齐，除了上述的媒体服务类型以外，还需要：
「云录制服务器(RTP to flv or mp4)「和」云转推服务器(RTP to RTMP)」，云录制主要用于回放点播，云转推主要用于旁路直播，在1vsN的场景下减少转发节点的压力，降低成本。如上图所示，SFU和MCU都可作为云录制和云转推的输入端，类比选择不同的媒体封装输出方式。另外也可使用CDN RTMP直播的录制来做回放点播，不过链路增加了，相应出现问题的概率也增大了，需结合着业务形态和研发阶段进行合理的选择。
如果是走的私有协议，为了支持Web端，还需要设计开发「WebRTC网关」，进行信令和媒体的转换。
3、网络架构演进
历史总是惊人的相似，可以参考RTMP直播架构的发展和演进，因为从本质上网络这一层面上RTMP直播和RTC要解决的问题是一样的。
-
第一阶段，「单区域源站模式」，各个区域都从源站上进行推拉流。如上图所示，很显然跨地域跨运营商时推拉流效果是无法保证的。
-
第二阶段，「多区域多线BGP+专线级联回源模式」，如上图所示，能有效改善用户与服务器之间的网络状况。阿里云ECS为多线BGP机房，不同区域间通过拉专线保持级联互通，相比运营商的主干网网络状况会稳定很多；但这种模式成本很高，多线BGP机房按照流量收费单价很贵，同时专线成本更高；另外对于阿里云ECS来说，并不是每个地区都有相应的VPC，存在一些区域无法正常覆盖，而且每引入新的节点，可能就需要重新购买专线，节点与节点之间的专线有的还受物理因素的限制，如国内到国外的出海光缆只有从华东上海出。
这一阶段就需要根据实际的需求进行「合理的区划」、「选点部署」和「定制一定的调度策略」，如同一区域一个room尽可能分配到同一台服务器上来避免级联；根据实际布点的网络拓扑动态生成路由，用户拉流时，通过调度服务器选择最优路径，动态回源；在一定情形下避免专线带宽的消耗，同时监控专线带宽的消耗，当超过一定阈值的情况下报警和使用外网通信，避免雪崩。
-
第三阶段，「多区域边缘节点(ENS)接入+多线BGP(ECS)跨区域跨运营商中转+云企业网(CEN)模式」。如上图所示(偷了个懒~
