Mesos container 在 360 广告系统的应用（上）

背景简介

大家好！今天我给大家分享的是 mesos container 在 360 商业广告部门的应用。

我是一名 SRE 工程师，我们负责管理与维护 360 商业广告平台，说起 SRE 工程师大家可能会想到谷歌公司，因为 SRE 毕竟是谷歌提出的概念。

作为 SRE 工程师我想说一下我们的自我修养。我们的主要工作是减少琐事，不断的扩大服务规模，同时我们还要保证整个系统的高可靠性和可维护性，不能随着业务规模的不断增大，招揽越来越多的人来维护业务是不合理的。

我们广告通过 360 搜索或者 360 手机端的应用进行展示，比如在 360 搜索输入“鲜花”会有广告展示，每天有数百亿次的投放与展示，手机端主要通过 360 的手机安全卫士，手机助手等等的一些应用进行广告的投放与展示。

Why container?

说一下为什么要使用容器解决我们的问题，还有演讲的主题为什么不写 Why Docker？

说到容器大家第一时间会想到 Docker，它实现了一个容器引擎（Docker engine）。除了 Docker，在容器生态圈还有一些公司他们实现了自己的容器引擎，比如 CoreOS 的 RKT，比如我们使用的 Mesos 的容器引擎（Mesos containerizer），这些引擎不依赖于 Docker 本身，可以解决稳定性和扩展性的问题。

业务痛点

我先不说我们为什么用容器解决这些问题，说一下业务上我们有哪些痛点，并且这些问题可能大家都会碰到。

1、数据中心迁移

这个问题大家多数都会遇到，在迁移过程中要把之前的业务熟悉一遍，需要重新部署，测试还会遇到一些环境配置不一致的问题。

2、故障恢复

服务器宕机之后，传统业务都部署在物理服务器上，这样也需要重新部署，这样会带来很多麻烦。

3、操作系统不一致

现在我们很多不同的操作系统，比如 centos5、6、7 都在用，迁移的时候很麻烦，还有一些系统内核的 Bug 需要去解决。

4、生产环境配置不一致

生产环境有一些服务器工程师都可以登录，如果改了一些配置导致线上出现问题的情况也是可能发生的。

5、测试环境不一致

可能每个人申请一台虚拟机专门做测试，导致测试结果也不一致。

6、服务的扩展性较低

传统业务扩容一般需要一台中控机或者有一套部署环境，每一次都需要重新添加一批服务器进行扩容。

7、服务器资源利用率问题

使用物理机部署服务，每一天都有服务的高峰低谷，由于采用静态资源划分的方式，资源利用率非常低会给公司造成很多资源上的浪费。

下面我来说一下我们为什么要用 Docker 来解决我们的问题。

Docker 有一个隐喻叫“集装箱”。其实 Docker 的英文翻译是“码头工人”，这个隐喻给使用者很多暗示，告诉大家快来使用 docker 吧，使用 Docker 就像使用集装箱一样，能够随时随地的，无拘无束的启动你的应用。像 Docker 官方的口号一样 build、ship、and Run Any APP Anywhere，Docker 为什么可以解决我们遇到的这些业务痛点呢？因为集装箱是有固定的标准，它的大小一致，这样货物在公路、铁路、海洋运输就不用考虑货物的尺寸等问题了，并且依赖大型机械化进行转运，等于是实现了一套标准的运输体系，可以给整个世界带来很大的商业潜力。

Docker 的标准化怎么实现？

正如我上面说到的，Docker 的实质化就是标准，Docker 的标准化是怎么实现的呢？

首先，Docker 有自己标准化的文档管理方式，它的标准化文档方式就是有自己的 Docker file，可以定义一系列的软件系统版本。

第二点，Docker 有对应用的统一操作方法，在物理环境不同的应用有不同的启动方法，如果你用 Docker 启动程序，可以通过 docker run 的方式来启动。在服务迁移过程中只要使用 Docker run 命令来启动你的程序就可以了。

第三点，为了维护生产环境的一致性和配置变更的幂等性，docker 创造性的使用了类似 git 管理代码的方式对环境镜像进行管理。每次都需要 docker pull 下载镜像，Docker container 本身只有 container layer 这一层可写，你每次重新部署的时候这一层是会被删掉的，这样可以保证 Docker 实际环境每次都是幂等的。

在服务容器化过程中可能遇到的问题

在服务容器化过程当中，我们可能会遇到哪些问题？当大家使用物理机的时候，为了 ssh 登陆服务器，每台服务器都会开通 SSH 服务并且添加对应的账号。如果你使用 Docker 服务还要开通 SSH 服务的 22 端口，你需要考虑一下你的服务是否真的需要登录到容器中，或者你容器化的方式是否正确或者它是否适合你的业务。还有一些人这样使用 Docker：在容器中开放 rsync 服务端口，甚至还有在 Docker container 里面部署 puppet agent 同步工具，这样做我觉得是完全没有必要的。我们都是不支持 SSH 或者类似的服务连接到 Docker 内部的。

如果你不让我登录到物理机上，不让我连到 Docker 内部，我怎么看我的日志呢？

我们有一套日志系统，后端对接的服务是 elasticsearch，会使用 Docker 的 syslog 模块通过 UDP 的方式写入 Graylog 里，graylog 或者 grafana 都可以进行展示、查询，这样我们就可以及时的发现线上的问题。

Docker 的网络性能

使用了 Docker，大家可能会考虑，它的网络性能会怎么样，我们其实也做过一些调研。我们主要用的是 Hostonly 和 Bridge 这两种模式，如果用 Hostonly 基本和直接在物理服务器上运行程序的性能是差不多的，现在我们也有团队专门做 calico 服务方面的研究，比如你有一些爬虫服务，可能希望有一些独立的外网 IP，可以考虑使用 Calico 为一个 container 单独分配外网 IP。

或者有网络隔离的需求的话，也可以使用 calico 服务。由于我们主要针对是私有云，直接用 hostonly 模式多一些。

存储镜像

关于 Docker 仓库，大家可能会问服务容器化之后，主要用什么仓库存储镜像呢？哪种镜像仓库比较好？之前我们搭建过 Docker 官方的仓库，只有单节点不是高可用的，数据可靠性也不是非常好，我们是用的无认证模式。

现在我们使用了 Harbor，用这个系统做了二次开发，后端存储用的 S3 存储系统，数据可靠性是非常高的，多机房之间可以进行数据同步，支持用户认证，大家根据自己的用户密码进行登录上传镜像等操作。之后我们还会做一个 Docker 仓库的 CDN 化，多机房直接访问 CDN 服务下载镜像。

怎样把数据写到本地

大家使用 Docker 可能会考虑数据怎么写到本地，我们使用 mesos+Docker 之后，是不是所有服务都要需要无状态的呢？我们推荐无状态服务运行在 mesos+Docker 之上。但是如果你有把日志落到本地的需求，我们现在也是可以支持的。

我列出的这些产品，比如 cephfs，mysql，kafka，HDFS，aerospike，redis 都是数据持久化的一种方式，比如流式数据一般用 kafka 多一些，数据直接通过 kafka 消费出来，通过一些计算模型后再重新写入 kafka，或者如果想数据落到本地的需求直接在 Container 中挂载 cephfs 也是可以的。

服务的注册和发现

关于服务的注册和发现，大家可能会有一些问题。比如我用了 mesos+Docker 之后，我们的一些服务是在 mesos-slave 节点之间飘逸的，有可能因为一台物理机宕机了，你的服务会在另外一台 mesos-slave 节点上启动，我怎么知道我的服务启动到具体哪台 IP 或者具体哪台机器上呢？

我们服务发现主要用的是 mesos-dns 还有 marathon，底层数据依赖于 zookeeper。还有一些公司可能用 etcd 或者 consul，我们也有在用不过比较少。

关于使用了 Docker，服务如何进行调度？还有 Docker 服务如果对于本地数据有依赖的话需要如何加载？希望大家可以带着问题思考一下，一会儿我会详细说明。

Why Mesos?

为什么要用 mesos？

当前遇到的一个背景就是在当前互联网环境下，越来越多的分布式计算系统产生。

如果说维护一个大型业务团队需要部署的框架或者分布式系统非常多，但是市面上又没有一种系统能够把所有的应用框架都部署到一个集群里，这样就会导致我之前说的比如资源利用率会很低，可维护性很低。因为不同的集群有不同的配置，所以我们就想把这些多个应用布到一个大型的资源池里，这样可以更好的共享硬件资源。因为我们的服务都是支持动态扩缩容的，这样也可以简化一些部署上的逻辑，并且最大化的利用资源，最终实现服务可调度，数据可以共享。

使用 mesos 的优点

1、资源利用率非常高

因为之前大家用物理服务器的时候，是静态资源划分的方式，这种方式资源浪费得比较多。因为服务每天都有高峰和低谷时段，如果你用 mesos 的话，使用了动态服务扩缩容，比如白天广告展示的量会非常大，最高的时候每秒已经超过一百万，但是在晚上访问量非常低，你就可以把这批机器资源释放出来，供一些离线业务运行，比如 hadoop。可以达到最大化的资源利用率。

2、便捷性

mesos 本身支持对所有资源打标签，大家可以打固定的标签。这样在提交资源的时候，可以根据你想要的资源提出申请。比如你想要一个 GPU 的资源，比如你要 1 核的我就会分配给你一核的，像乘坐飞机一样，你想坐头等舱只要有资源就可以分配给你，mesos 也是这样，我们支持端口，CPU，内存、硬盘等等的划分。

3、可扩展性非常好

因为它本身的设计原理是两极调度框架，这样带来的好处是它非常的简单。因为 mesos 本身只负责资源调度，把任务调度交给了运行在它之上的具体框架进行调度。所以如果你要横向扩展 mesos 的话，非常方便。

4、模块化

因为 mesos 支持在 mesos API 之上定义各种各样的 framework，大家可以自由添加 framework，我们主要用的 marathon，flink 等官方与自定义 framework，具体使用哪种框架，大家可以根据需要去设计。

mesos 的目标

mesos 的目标，其实主要就是给我们带来资源的高利用率，支持多种多样的自定义框架，包括当前支持的还有以后新产生的分布式计算框架等，都可以建立在 mesos 之上。

可扩展性。现在全球节点最大的是 twitter 有 45000 个 mesos-slave。

可靠性。因为 mesos 采用的是热备的方式，存在一个 master 节点，如果遇到主从节点切换的时候非常快，大概 10 秒钟就能完成。

mesos 的架构

mesos 的主要组成是由 zookeeper 实现 master 的高可用，还可以保证数据的一致性，保存所有的 mesos sleve 节点和信息。mesos master 主要用于接收 agent 上报给 mesos master 的资源，mesos master 会分配 offer 给具体给它之上运行的 framework。

Framework 是基于 mesos API 定义的调度器，会根据调度需求分配具体的 offer。

最底层是 mesos agent，用来接受和执行 mesos master 发给它的命令，通过 mesos agent 之上的 executor 启动 task

mesos 的实现

mesos 是用的两万行的 c++代码编写而成，故障恢复使用的是 zookeeper，框架都是可拓展的、可以自定义的，并且是模块化的。是 Apache 顶级的孵化项目，同时还是开源的，项目成立于 2009 年。

mesos 的结果

mesos 给我们带来的是更高的资源利用率与可靠性。