技术干货|又拍云直播转码系统架构与实践

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

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

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

     2. 请求路由。新的资源加入、故障资源脱离、并发负载等，能够及时调度；

     3. 微服务化。解耦直播处理与分发的关系，适应定制开发，以及服务更新时不被影响。

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

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》

原文来自:又拍云

声明：所有来源为“聚合数据”的内容信息，未经本网许可，不得转载！如对内容有异议或投诉，请与我们联系。邮箱：marketing@think-land.com