打造百亿级数据处理量的弹性调度容器平台

本次分享介绍七牛数据处理团队的容器技术实践经验，分享七牛如何通过自主研发的容器调度框架打造易扩展、易部署、高自由度、高可用、高性能的数据处理平台。

首先介绍一下七牛数据处理业务的背景。七牛云目前平台上有超过50万家企业客户，图片超过2000亿张，累积超过10亿小时的视频。 用户把这些图片和视频存储在七牛上后会有一些数据处理方面的需求，如缩放、裁剪、水印等。这些文件持续在线且数据种类多样，如果用户把这些文件在自己的基板上处理好后再上传到七牛，是非常不合算的事情。而七牛最先提供基于存储的数据处理功能方便用户去做数据处理，这些数据处理通常放在企业的客户端或服务器端来操作，对接上七牛云存储的数据处理接口后，即可对图片和音频进行丰富的实时转码功能，转码生成的新规格文件放在七牛提供的缓存层供App调用，不用占用存储空间，对企业来说不仅成本大大降低，还可提高开发效率。 下图为一个图片裁剪的数据处理示例：

七牛的文件处理程序简称FOP（File Operation），不同的文件处理操作使用不同的FOP。用户只需上传一个原文件就可以通过使用七牛的数据处理功能得到各种样式丰富的文件。下图为文件从上传存储到处理到分发的流程图：

七牛云的海量数据成就了Dora十分强大的数据处理能力，目前七牛的数据处理服务已经日处理数近百亿次。面对这样海量的数据处理请求，原有的数据处理平台也面临着新的挑战：

1. 日均请求量百亿级，CPU 密集型计算
   
   目前系统每天有近百亿的数据处理请求量，拥有近千台的计算集群，整个存量、增量都非常大。而数据处理集群中绝大部分的机器都是用来跑图片、音视频转码的，这些都是CPU密集型的计算，这意味着后台需要很多台机器，而且CPU的核数越多越好。在年底数据处理平台可能会在目前近千台的计算集群基础上翻好几倍，需要有快速物理扩展和高效智能管理的能力。

2. 服务器负载不均衡，资源利用率不高
   
   实时在线处理的业务处理时间短，但是量大，需要大量的实例来应对高并发的情况。而异步处理的业务处理时间长，也需要分配足够的资源来。当实时业务并不繁忙而异步处理业务增长时，并不能使用分配给实时业务的资源， 这种静态资源分配机制带来的分配不合理问题，导致服务器负载不均衡，资源利用率不高。

3. 突发流量不可测量， 大量冗余资源
   
   在新接入用户并不能完全正确的预测请求量，原来的模式是通过快速扩容机器并验证上线，需要一定的处理时间，对于这种非计划内的请求量需要准备大量的冗余资源来应对突发流量。

4. 集群负载过重，不能自动按需扩展
   
   个别用户突增数据处理请求时导致集群负载压力过大，CPU处理变慢， 请求时间变长，请求任务堆积，影响其他业务，并不能在现有的资源基础上进行快速扩展，也不能根据实际的业务压力进行按需自动扩展集群实例。

5. 用户自定义应用（UFOP）质量及规模未知
   
   七牛除了提供官方的数据处理服务，也支持客户将自定义数据处理模块部署到七牛云存储的就近计算环境，避免远程读写数据的性能开销和流量成本，满足用户多方位的数据处理需求。但是各种UFOP运行在同一个平台上就可能会存在部分UFOP的质量问题或请求量过大而分配的资源不足导致影响平台上其他服务的正常运行。

为了解决以上问题，七牛基于资源管理系统Mesos自主研发了一套容器调度框架（DoraFramework），通过容器技术打造了易扩展、易部署、高自由度的数据处理平台Dora。整体架构图如下所示：

各组件介绍：

Mesos：由ZooKeeper、Mesos Master、Mesos Agent构成了基础的Mesos数据中心操作系统，可以统一管理机房中的所有物理机，负责资源层面的调度，是二层调度系统最基础的运行环境 。

DoraFramework：业务层调度框架，通过DoraFramework使用Mesos管理所有的物理机资源，完成业务进程的调度与管理。

Consul：包含服务发现，健康检查和KV存储功能的一个开源集群管理系统，DoraFramework调度系统使用Consul的服务发现和健康检查机制提供基础的服务发现功能，使用KV存储功能来存储DoraFramework的metadata。

Prometheus：一个开源的监控系统，实现机器级别，容器级别及业务系统级别的监控。

Pandora： 七牛的内部的日志控制管理系统，负责生产环境所有日志的汇聚及处理。

在这个架构中，我们选择通过容器技术实现跨机器实现弹性的实时调度。调度框架可以根据具体的业务负载情况动态的调度容器的个数， 很好的解决了静态配置导致的资源利用率不高的问题 。而容器秒启的特性也解决了当有大量突发请示进入，可以快速启动服务的问题。在网络方面，由于UFOP是用户部署运行的服务，并不知道用户是否有开启其他的端口使用，所以使用的是Bridge模式，需要对外使用端口的都需要通过NAT进行暴露，这样服务内部使用了什么端口并不会对外界环境造成影响 ，对平台环境做了非常好的安全隔离。

数据处理平台的调度系统我们选择的是Mesos 自研容器调度框架（DoraFramework）。选择Mesos做为资源管理系统一个是因为Mesos的相对其他的容器调度系统更成熟，Kubernetes是2015 才发布可生产环境运行的版本，Docker Swarm则是2016年才发布，这两个产品的生产实践在调研时基本还没什么大型生产实践经验，而Mesos则已有七八年的历史，且资源管理方面已经在如苹果，Twitter等大型公司得到生产实践，稳定性比较好；第二个是因为Mesos支持调度成千上万的节点，以七牛目前已经达到近千台物理机的规模，且每年都在大幅度增长的情况，Meoso这种支持超大规模调度的资源管理框架更合适七牛的业务发展； 第三是因为Mesos的简单性，开放性及可扩展性，Mesos是一个开源的分布式弹性资源管理系统，整个Mesos系统采用了双层调度框架：第一层由Mesos收集整个数据中心的资源信息，再将资源分配给框架；第二层由框架自己的调度器将资源分配给自己内部的任务。Mesos自身只做资源层的管理，这种简单性带来的则是稳定性。而容器的调度框架则可以使用开源框架如Marathon/chronos或自主研发。Kubernetes虽然功能很丰富，但是也比较复杂，组件及概念都比较多，并且缺乏开放性和可扩展性，只能使用它提供的调度功能，而不能根据自身业务的情况定制调度框架，会造成对Kubernetes过于依赖的情况。

为什么不选择Mesos的核心框架Marathon 而选择自研，出于三方面的考虑：1. Marathon有些方面不支持我们期望的使用姿势，比如不太好无缝对接服务发现；2. Marathon采用Scala开发，出了问题不好排查，也不方便我们做二次开发；3. 如果选用Marathon的话，我们上面还是要再做一层对 Marathon的包装才能作为Dora的调度服务，这样模块就会变多，部署运维会复杂。

DoraFramework是七牛使用go语言自研的容器调度框架。DoraFramework实现了Mesos两层调度中业务进程的调度，是Dora调度系统中的核心组件，通过与Mesos和Consul组件之间的交互， 对外提供API接口。架构图如下：

（编辑：安卓应用网_ASP源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!