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 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，大家可能会考虑，它的网络性能会怎么样，我们其实也做过一些调研。我们主要用的是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？

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

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

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 master的故障恢复机制。

因为mesos master只有一个软体状态，只会列出它之上的framework以及mesos-slave的信息，在mesos master需要进行切换的时候，通过zookeeper进行leader的重新选取，选取好新的leader后，只需要所有的framework和mesos-slave节点重新注册到新的mesos master之上，时间就10秒钟左右。如有你有上万台机器，可能会同时连mesos master会不会造成大量的链接导致master服务不可用，官方有这样的设置可以设定链接的比例来进行控制。

marthon framework

·运行长任务 。从应用框架字面的意思，任务就像跑长跑一样，这个框架其实就是运行长任务(long running job )的。

·服务发现 。marathon还可以实现服务发现，有比较好的API接口，比如我有一个APP id对应具体机器的IP是什么。
·健康检测&事件通知机制。 marathon支持对你所启动的任务进行健康检测，比如端口或者你自定义命令都可以，有事件通知机制，正因为有了事件通知机制才可以在马拉松之上建立一些实时的服务发现，知道哪些服务宕掉了，在哪些新节点启动了，可以保证我们的实时发现服务，重新指向新的服务器。

·WebUI。 marathon有自己的web UI，可以通过界面直接操作，非常方便。

·限定条件。 你可以设定一大堆的限定条件，比如我之前说的像你选飞机的舱位一样，你设定了网卡必须是万兆的，marathon会根据你设定的限定条件，帮你选择对应资源。

·Labels。 labels标签也是我们常用的，随着资源利用率越来越大，可能有各种应用，大家可以加上各种的标签，方便的查询。

·数据持久化 。数据持久化也是支持的，可以支持挂载本地卷。

·服务的预热。 这个功能用得不是特别多，比如你在服务启动的时候会需要启动时间，这个时间健康检测是失败的，你可能需要设定一个预热时间，保证服务启动之后正常的健康检测才生效。

·优雅退出。 优雅退出这个问题，大家可能都会遇到，比如像C++不涉及内存自动回收可能需要程序上设计优雅退出的问题，你可以通过marathon设置一个退出时间，保证你的服务正常退出之后，才把以前的服务都退掉，新的服务启动。

·支持自定义的containerizer和GPU资源的调度。

Marathon-lb

marathon-lb是我们用的一个实时发现的服务，marathon-lb是基于haproxy和marathon eventbus机制设计的。其实除了mrathon-lb还有一些其他的服务实时发现，但是都是基于marathon的事件通知机制设计的。因为marathon有事件总线的实时更新，可以实时的改变服务后端的IP。如果有宕机或者有服务自动扩缩容的话，marathon-lb可以实时改变haproxy的配置，marathon-lb主要是通过第四层IP加端口的方式进行服务代理，marathon-lb支持TCP或者HTTP的代理方式。

Mesos-DNS

我们还使用了mesos官方的mesos-DNS服务，用于一些对实时性要求不高的服务，比如我们把STORM容器化以后nimbus和 supervisor之间的通信可能就不是那么频繁，如果有nimbus宕机的情况，只需要通过mesos-dns就可以重新发现appid对应的新的nimbus IP。你可以使用mesos-DNS发现appid对应的所有后端节点的IP，可以保证你的服务节点随时都可以访问到你想访问到的IP。mesos-DNS有一定的延迟性，我们测试大概有十几秒。

Mesos VS YARN

我说一下在我们做技术选型的时候，我们也做过mesos和yarn方面的调研。

mesos主要是能调度各种样的资源，有CPU，内存、端口、硬盘； yarn主要是CPU和内存。

两者都是两极调度 策略但是又有不同。

mesos本身只做资源的调度，不负责具体任务的调度，把任务调度交给 framework调度。

yarn全都是yarn本身进行资源调度，一个程序提交给它一个任务都由yarn来 决定是否接受或者拒绝这个资源，而mesos却不同。

mesos因为是对物理资源进行管理与调度 的，yarn主要基于hadoop来做。

根据需要，我们最后还是选择了mesos来作我们的分布资源 管理框架。

Mesos VS Kubernetes