又拍云直播转码系统架构与实践
直播转码系统，作为为直播提供服务的转码系统，必须满足直播低时延、高并发的需求，同时也面临转码单请求资源消耗大的问题，如何满足这些需求，提供稳定的、高可用的服务，是直播转码系统设计需要考虑的。
通过对又拍云直播云用户行为进行深入分析，我们把需求转变成三个技术问题：
问题一：自动扩容。怎样方便地提升服务的处理能力，当并发量突增时能快速调度资源响应，保证直播低时延；
问题二：请求路由。新的资源加入、故障资源脱离、并发负载等，能够及时调度；
问题三：微服务化。解耦直播处理与分发的关系，适应定制开发，以及服务更新时不被影响。
这个三个问题，在我们这几年在做的云处理平台解决的问题之中。于是，我们决定把直播转码微服务化，融入云处理平台，利用这个平台的高性能去保障它的运转。
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% 的内容审核（智能鉴黄）服务。
以上是基于又拍云处理平台的直播转码系统的介绍。更多详细内容可参阅：
《又拍云莫红波：开源组件搭配Docker、MESOS、MARATHON》
如果您的团队或公司需要私有化容器云平台，可以与我们联系。