去哪儿网基于Mesos和Docker构建私有云服务的实践

该平台目前已实现了如下多项功能：

目前为止，这个数据平台可以说是公司整个流数据的主要出入口，包括私有的Elasticsearch Cloud和监控报警之类的数据。那么为什么选择Docker/Mesos？

选择Docker有两大原因。第一个是打包：对于运维来讲，业务打完包之后，每天面对的是用脚本分发到机器上时所出现的各种问题。业务包是一个比较上层的话题，这里不做深入的讨论，这里讲的“打包”指软件的Runtime层。如果用Docker的打包机制，把最容易出现问题的Runtime包装成镜像并放在registry里，需要的时候拿出来，那么整个平台最多只执行一个远程脚本就可以了，这是团队最看好的一个特性。第二个是运维：Docker取消了依赖限制，只要构建一个虚拟环境或一个Runtime的镜像，就可以直接拉取到服务器上并启动相应的程序。此外Docker在清理上也较为简单，不需要考虑环境卸载不干净等问题。

以常见的计算框架来说，它们本质上仍然属于运行在其上的Job的Runtime。综合上述情况，团队选择针对Runtime去打包。

选择Mesos是因为它足够简单和稳定，而且拥有较成熟的调度框架。Mesos的简单体现在，与Kubernetes相比其所有功能都处于劣势，甚至会发现它本身都是不支持服务的，用户需要进行二次开发来满足实际要求，包括网络层。不过，这也恰好是它的强项。Mesos本身提供了很多SDN接口，或者是有模块加载机制，可以做自定义修改，平台定制功能比较强。所以用Mesos的方案，需要考虑团队是否可以Hold住整个开发过程。

从框架层面来看，Marathon可以支撑一部分长期运行的服务，Chronos则侧重于定时任务/批处理。

数据平台的最终目标架构如下图3所示：

组件的容器化分为JVM容器化和Mesos容器化。JVM容器化需要注意以下几方面：

-Xloggc会记录GC的信息到制定的文件中。现在很少有直接用XLoggc配置的了（已经用MXBean方式替代了）。如果有比较老的程序是通过-Xloggc打印GC日志的话，那么要额外挂载volume到容器内。

时区与编码

时区是另一个注意点。上面所列的三种不同的方法都可以达到目的，其中第一/三个可以写在Dockerfile里，也可以在docker run时通过–env传入。第二种只在docker run时通过volume方式挂载。另外，第三种额外设置了字符集编码，推荐使用此方式。

主动设置heap

这是Docker内部实现的问题。即使给Docker设置内存，容器内通过free命令看到的内存和宿主机的内存是一样的。而JVM为了使用方便，会默认设置一个人机功能会根据当前机器的内存计算一个堆大小，如果我们不主动设置JVM堆内存的话，很有可能计算出一个超过　Memory Cgroup限制的内存，启动就宕掉，所以需要注意在启动时就把内存设置好。

CMS收集器要调整并行度

CMS是常见的收集器，它设置并行度的时候是取机器的核数来计算的。如果给容器分配2个CPU，JVM仍然按照宿主机的核数初始化这些线程数量，GC的回收效率会降低。想规避这个问题有两点，第一点是挂载假的Proc文件系统，比如Lxcfs。第二种是使用类似Hyper的基于Hypervisor的容器。

Mesos容器化要求关注两类参数：配置参数和run参数。

Mesos是配置参数最多的。在物理机上，Mesos默认使用系统的Systemd管理任务，如果把Mesos通过Docker run的方式启动起来，用户就要关systemd_Enable_support，防止Mesos Slave拉取容器运行时数据造成混乱。

第二个是Docker_Mesos_Image，这个配置告诉Mesos Slave，当前是运行在容器内的。在物理机环境下，Mesos Slave进程宕掉重启，、就会根据executor进程/容器的名字做recovery动作。但是在容器内，宕机后executor全部回收了，重启容器，Slave认为是一个新环境，跳过覆盖动作并自动下发任务，所以任务有可能会发重。

Docker_Socket会告诉Mesos，Docker指定的远端地址或本地文件，是默认挂到Mesos容器里的。用户如果直接执行文件，会导致文件错误，消息调取失败。这个时候推荐一个简单的办法：把当前物理机的目录挂到容器中并单独命名，相当于在容器内直接访问整个物理机的路径，再重新指定它的地址，这样每次一有变动Mesos就能够发现，做自己的指令。

后面两个是Mesos Logging配置，调整生成logging文件的一些行为。

启动Slave容器的时候最好不加Pid Namespace，因为容器内Pid=1的进程一般都是你的应用程序，易导致子进程都无法回收，或者采用tini一类的进程启动应用达到相同的目的。–privileged和root user主要是针对Mesos的持久化卷功能，否则无法mount到容器内，–net=host是出于网络效率的考虑，毕竟源生的bridge模式效率比较低。

上图4就是去哪儿数据平台部署的流程图。

拿Spark on Mesos记录子，即使是基于Spark的Marathon调度，也需要用户开发一个Frameworks。上生产需要很多代码，团队之前代码加到将近一千，用来专门解决Spark运行在Master中的问题，但是其中一个软件经常跑到Master，对每一个框架写重复性代码，而且内部逻辑很难复用，所以团队考虑把上层的东西全都跑在一个统一框架里，例如后面的运维和扩容，都针对这一个框架做就可以了。团队最终选择了Marathon，把Spark作为Marathon的一个任务发下去，让Spark在Marathon里做分发。

除去提供维标准化和自动化外，基于Spark的Marathon还可以解决Mesos-Dispatcher的一些问题：

整个过程比较简单，如下图5所示：

不过还是有一些问题存在：

Checkpoint & Block

关于Checkpoint&Block，通过动态预留的功能可以把这个任务直接“钉死”在这台机器上，如果它挂的话可以直接在原机器上重启，并挂载volume继续工作。如果不用它预留的话，可能调度到其他机器上，找不到数据Block，造成数据的丢失或者重复处理。

持久化卷是Mesos提供的功能，需要考虑它的数据永存，Mesos提供了一种方案：把本地磁盘升级成一个目录，把这个转移到Docker里。每次写数据到本地时，能直接通过持久化卷来维护，免去手工维护的成本。但它目前有一个问题，如果任务已被回收，它持久化卷的数据是不会自己删掉的，需要写一个脚本定时轮巡并对应删掉。

临时文件

如果使用持久化卷，需要修改这两个配置，把这一些临时文件写进去，比如shuffle文件等。如果配置持久化卷的话，用户也可以写持久化卷的路径。

Coarse-Grained

上图6展示了基于Storm的Marathon调度，Flink也是如此。结合线上的运维和debug，需要注意以下几方面：

Filebeat + Kafka + ELK

大部分WebUI上看到的都是目前内部的数据处理情况，可以通过ELK查询信息。如果任务曾经运行在不同版本的Spark上，可以把多版本的日志都追踪起来，包括日常、问题监控等，直接拿来使用。

Metrics

上图7是ELK on Mesos结构图，也是团队的无奈之选。因为Mesos还暂时不支持multi-role framework功能，所以选择了这种折中的方式来做。在一个Marathon里，根据业务线设置好Quota后，用业务线重新发一个新的Marathon接入进去。对于多租户来讲，可以利用Kubernetes做后续的资源管控和资源申请。

这部分包括了Streaming监控指标与报警、容器监控指标与报警两方面。

Streaming监控指标与报警

拓扑监控包括数据源和整个拓扑流程，需要用户自己去整理和构建，更新的时候就能够知道这个东西依赖谁、是否依赖线上服务，如果中途停的话会造成机器故障。业务监控的话，第一个就是Topic Lag，Topic Lag每一个波动都是不一样的，用这种方式监控会频繁报警，90%的中位数都是落在80—100毫秒范围内，就可以监控到整个范围。

容器监控指标与报警

容器这一块比较简单，利用Docker并配合Mesos，再把Marathon的ID抓取出来就可以了。我们这边在实践的过程发现一个问题，因为Statsd Watcher容易出现问题，你直接用Docker的时候它会报一些错误出来，这个问题就是Statsd Watcher把路径给挂了的原因。目前我们平台就曾遇到过一次，社区里面也有人曝，不过复现率比较低。用的时候如果发现这个问题把Statsd Watcher直接停掉就好。指标的话，每台机器上放一个statsd再发一个后台的Worker，报警平台也是这个。

其实针对Docker监控的话，还是存在着一些问题：

首先主要是监控系统压力比较大。原来监控虚拟机时都是针对每一个虚拟机的，只要虚拟机不删的话是长期汇报，指标名固定，但在容器中这个东西一直在变，它在这套体系下用指标并在本地之外建一个目录存文件，所以在这种存储机制下去存容器的指标不合适。主要问题是数据膨胀比较厉害，可能一个容器会起名，起名多次之后，在Graphite那边对应了有十多个指标，像这种都是预生成的监控文件。比如说定义每一秒钟一个数据点，要保存一年，这个时候它就会根据每年有多少秒生成一个RRD文件放那儿。这部分指标如果按照现有标准的话，可能容器的生命周期仅有几天时间，不适用这种机制。测试相同的指标量，公司存储的方式相对来说比Graphite好一点。因为Graphite是基于文件系统来做的，第一个优化指标名，目录要转存到数据库里做一些索引加速和查询，但是因为容器这边相对通配符比较多，不能直接得知具体对应的ID，只能通配符查询做聚合。因为长期的通配符在字符串的索引上还是易于使用的，所以现在算是折中的做法，把一些常用的查询结果、目录放到里边。

另一个是容器的生命周期。可以做一些审计或者变更的版本，在Mesos层面基于Marathon去监控，发现这些状态后打上标记：当前是哪一个容器或者哪一个TASK出了问题，对应扩容和记录下来。还有Docker自己的问题，这样后面做整个记录时会有一份相对比较完整的TASK-ID。