腾讯云实时音视频云端录制子系统上线，为多个行业带来全新改变
- 云端录制系统的技术实现 -
在远程教育、秀场直播、视频会议、远程定损、金融双录、在线医疗等应用场景中，考虑取证、质检、审核、存档和回放等需求，常需要将整个视频通话或互动直播过程录制下来。
针对这些场景的录制需要，我们需要有一套通用的高可用的云端录制系统来实现。
以往常见的方法是，通过将音视频数据推到 CDN 进行录制。这种方案虽然比较方便，但是整个链路引入了较多环节和供应商，彼此耦合较深，无论是开发新特性或者是调查问题，都会相对麻烦。
在分析了多种解决方案的利弊以后，我们设计并且实现了一个能支持高并发、高可用的云录制系统，并且实现了与 TRTC 解耦，录制需求将在新系统单独设计与发布。
事实上，作为一个流媒体处理子系统，音视频文件录制只是其中的一个功能，在设计系统功能组件的时候，我们考虑到了后续可能会接入的其他功能需求，比如说音视频内容审核 、推流和反向拉流到 TRTC 等。作为一套流媒体通用子系统的解决方案，今天来给大家说说云端录制是怎么实现的。
TRTC云端录制系统
TRTC 云端录制系统是针对加入 TRTC 房间的直播流、通话流进行插件式录制的服务。录制用户作为一个单独的机器人用户加入到 TRTC 的房间中拉取实时流。客户可以通过简单的操作方法（调用RESTFUL API的方式）来实现录制。目前可以支持录制单流和录制合图（混流）模式。客户通过提供一个第三方的云存储账户来接收和管理录制文件（HLS协议格式，采用TS容器作为载体可在断电、断网等异常情况下将录制文件损失降到最低）。
- 助力用户打造简单易用的接口 -
TRTC 云端录制服务通过腾讯 API3.0 暴露出了四个 RESTFUL API 接口，可以方便的实现开启录制、查询录制、更新录制和停止录制。客户只需一台 HTTP 服务器，就可以进行集成、测试和部署。RESTFUL API可以实现一次录制的完整最小集功能，如果客户需要关心更多录制任务的状态，可以订阅相关的回调事件。
CreateCloudRecording 方法并设置房间号即可进入该房间进行录制，请求成功会返回对应的录制 task_id，该 id 是整个录制周期的唯一标识，将作为调用后续方法的请求参数。
DescribeCloudRecording 方法可以查看录制的状态，在返回的http 响应中可以获取录制的m3u8索引名称和上传的状态。
ModifyCloudRecording 方法可以更新录制任务，比如说更新合流的Layout布局，更新订阅流。
DeleteCloudRecording 方法可以停止录制任务，录制任务上传的状态可以通过回调获取。当房间内没有用户流并且超过最大等待时间后，后台录制任务也会自动退出。
- 更多丰富的功能应用 -
- 支持 TRTC 房间内的音视频录制，录制模式有单流和合图模式可供选择；
- 支持订阅全局媒体流的类型，音频、视频和音视频流，也支持订阅单个用户的音视频媒体流类型；
- 支持订阅房间内用户的音频流、视频流的黑白名单；
- 合图模式下支持用户设置自定义视频转码参数（宽、高、帧率、码率和关键帧间隔）以及音频转码参数模板（音频采样率、声道和比特率）；
- 合图模式下支持用户设置画面布局，三种布局模板（悬浮布局、垂直布局以及自适应布局），自定义布局模式（用户自定义画面位置）；
- 支持录制上传到第三方云存储，可实时播放；
- 强大的高可用机制，支持断网、断电等异常状况下的录制文件高可用，不丢录客户文件；
- 支持录制文件缓存备份，第三方云存储故障会自动备份到内部缓存系统，保证录制文件不丢失。
- 分布式高可用可扩展架构 -
衡量一个实时流媒体子系统的好坏，不仅要考虑是否能够实现该有的功能，更要看设计的架构是否能够支撑高并发，高可用，可水平扩展。
在这里我们重点看一下高可用的设计。
所有的事情和人都不是100%可靠的，在这个前提下，引入高可用这个概念，使得系统具有更高的风险控制能力。要做到高可用的设计我们可以从以下几个方面着手：
- 减少服务之间的依赖，低耦合高内聚的模块设计；
- 避免部署单点服务，这里单点也包括同区域内核心服务集中部署；
- 故障限流策略，当服务出现故障时，及时限流避免造成更大的故障；
- 分散隔离的模块设计以及部署方式，将不同类型的服务拆分成多个分布式的集群比集中在某个核心模块要有更好的容错性。
在云端录制系统设计中，各个模块都是多区域对等部署，无单点故障的风险。云端录制平台的高可用提供了全方位的服务保障能力，最大程度上保证了客户的录制任务不受异常风险影响。
本地高可用保障，提供了录制服务进程在本地服务器或者云上容器内的故障恢复能力。在录制业务服务器上通常会运行很多支撑服务，本地的业务进程在不断演进后业务抽象难度大、管理复杂，甚至有可能混布一些其他业务（云上容器同一pod内不同container），这个时候本机的服务稳定性可能会收到一些扰动，当然业务进程自身也可能因为一些异常处理发生故障，这里我们在本机引入了一个代理任务进程，托管各个业务服务进程，在进程异常的时候迅速拉起服务，这个过程是毫秒级的，而且业务进程的恢复不用去读写共享内存，耦合操作系统的资源。另外通过这个代理任务进程可以做到不重启业务，进行服务变更发布。
录制文件高可用保障，接入到第三方的云存储后，我们担心网络抖动或者第三方云储存故障导致客户的录制文件丢失。应对这一情况，我们会将录制文件转存到内部的大账号，之后会有离线转存服务再次上传到客户的存储中。
信令通道高可用保障，各个服务是分布式幂等部署的，各个服务通过名字服务注册到服务中心，上游信令服务通过服务发现来路由转发消息，如果下游信令接收服务故障，名字服务中心将会自动摘除节点，保证信令通道的畅通。
全局高可用保障，主要是应对机器断网、重启，云容器重建等服务不可用的场景。
录制集群的全局高可用设计如图：
我们简单描述一下断电断网下录制高可用的流程。
假设我们有一个录制任务落到了录制服务器A上，那么这个任务会注册到不同区域的三台任务管理服务上（这里我们分别是北京、上海和广州三地），并且会周期性的同步任务的心跳，当我们的录制服务A所在网络发生断网或者录制服务器A断电，那么心跳将会发生超时，这个时候假设北京所在的任务管理服务率先感知到（主观下线），那么此节点将会等待上海和广州节点的反馈结果（客观下线），收集到足够的裁决信息后，将会发起选举，进行服务恢复流程，迁移原有的录制任务到录制服务器B。这里选举的原因是，每个区域的管理节点都会有主观下线到客观下线的流程，为了防止拉起多路相同的录制服务，拉起的控制权给到选举选中的管理节点。整个拉起的过程对于客户来说是无感知的，保证了录制服务的高可用。
您可识别下方二维码或点击「阅读原文」提交云端录制需求信息，TRTC团队将于第一时间与您联系，助力用户快速体验产品服务。
TRTC 云端录制解决方案致力为用户提供可靠性和实时性、方便易用的高可用录制服务。
