背景简介

大家好！今天我给大家分享的是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给我们带来的是更高的资源利用率与可靠性。

创作场景

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