lingsen.zeng

又拍云直播转码系统架构与实践

直播转码系统,作为为直播提供服务的转码系统,必须满足直播低时延、高并发的需求,同时也面临转码单请求资源消耗大的问题,如何满足这些需求,提供稳定的、高可用的服务,是直播转码系统设计需要考虑的。

通过对又拍云直播云用户行为进行深入分析,我们把需求转变成三个技术问题:

问题一:自动扩容。怎样方便地提升服务的处理能力,当并发量突增时能快速调度资源响应,保证直播低时延;

问题二:请求路由。新的资源加入、故障资源脱离、并发负载等,能够及时调度;

问题三:微服务化。解耦直播处理与分发的关系,适应定制开发,以及服务更新时不被影响。

这个三个问题,在我们这几年在做的云处理平台解决的问题之中。于是,我们决定把直播转码微服务化,融入云处理平台,利用这个平台的高性能去保障它的运转。

So,云处理平台是怎么解决这三个问题的呢?

云处理平台简图

△ 云处理平台架构简图

自动扩容

又拍云处理平台采用 Mesos+Docker+Marathon 做基础架设。其中,Mesos 负责服务器(物理机)资源管理,Docker 在 Mesos 上建立一个个容器,为 App(应用) 提供隔离的运行环境,保证各个应用独立运行,互不干扰。Marathon 作为服务管理,监控 App 的运行情况,并在 App 异常时,进行操作,保证 App 永不掉线。

Mesos 是 Master/Agent 架构,它分为 Mesos-Master、Mesos-Agent 和 Scheduler (调度器)三个部分。它们之间的运行流程如下:

每台服务器上部署一个 Mesos-Agent,负责将机器情况汇报给 Mesos-Master。Scheduler 作资源调度,比如收到申请资源请求时,向 Mesos-Master 请求机器情况,Mesos-Master 把所有可用的机器资源反馈给 Scheduler,Scheduler 根据规则决定在哪台服务器上建立容器。

△ Mesos内部机制

如果容器的资源使用达到预设警戒线时,就会触发扩容机制。Marathon 向 Mesos 申请新的资源,并从 Docker 镜像仓库中获取 App 的镜像,完成自动扩容。

请求路由

当一个新的容器产生时,通过 Registator(服务注册)注册到 Consul(服务发现)。Consul 收到服务更新信息后,将信息同步到 Slardar。Slardar 是在云处理平台的入口,它负责判断请求需要的 App,结合负载均衡策略,把请求分发到对应的容器。

当一个容器负载达到一定程度时,Slardar 将不再往该容器分发请求,而将该请求发往其他容器。如果该 App 的所有可用容器负载都高时,触发自动扩容。

当一个容器发生故障时,Marathon 将信息同步给 Slardar 和 Consul,Slardar、Consul 收到信息后,把容器状态变更为不可用,后续 Slardar 不再分发请求到该容器。

微服务

受直播特性的影响,直播转码等要求服务尽可能小、快,并且部分用户,存在定制化操作,需要服务灵活。在这种情况下,我们把直播转码微服务化,并且分成通用转码微服务和定制转码微服务。用户的请求过来,先判断是通用转码还是定制转码,如果是通用转码请求,分发到通用转码微服务上,如果是定制用户的转码请求,分发到对应定制转码微服务上。

另外,根据不同服务特性的差异,我们也进行了相应的优化。比如,直播转码用 GPU 处理比 CPU 快得多,把直播转码部署在高性能 GPU 服务器上。比如,直播截图用 CPU 处理比 GPU 快,把直播截图部署在高性能 CPU 服务器上。

在又拍云,除了直播转码系统在使用云处理平台外,图片处理,音频处理,视频处理,压缩处理,解压缩处理等服务也在使用,包括准确率高达 99.7% 的内容审核(智能鉴黄)服务。

以上是基于又拍云处理平台的直播转码系统的介绍。更多详细内容可参阅:

《又拍云叶靖:基于ngx_lua的动态服务路由方案》

《又拍云叶靖:基于Docker的云处理服务平台》

《又拍云莫红波:开源组件搭配Docker、MESOS、MARATHON》

如果您的团队或公司需要私有化容器云平台,可以与我们联系

发表评论

电子邮件地址不会被公开。 必填项已用*标注