mesos master的故障恢复机制

接下来说一下mesos master的故障恢复机制。

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

mesos的生态圈有哪些框架

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

说起mesos可能很多同学觉得使用了marathon 提供了容器任务的管理能力，可能就需要跟
kubernetes系统进行比较一下。

本身来讲，mesos和kubernetes是两个东西，mesos是一个分布式的资源管理框架，被称为分布式系统的内核。假如你有很多物理资源，你想把它整合成一个逻辑资源层面的物理资源池，那么你用mesos是最合适不过的了。

mesos解决问题的核心是如何把资源整合成一个大型的物理资源池，它上面运行什么，怎么跑它并不关注。

kubernetes主要是一个自动化的容器操作平台，操作主要包括部署、调度还有节点集群间的扩容等等。

kubernetes解决问题的核心主要是围绕容器来做的，这两个系统本身没有可比性。因为mesos
支持很多framework，比如marathon可以实现容器的调度，所以大家就会把这两个平台进行比较。

如果你想搭建这样一个容器管理平台或者调度平台，从我个人来讲第一点从任务上来讲，marathon只支持长任务型的，kubernetes支持的比较广，比如支持长时间任务(long running job)，节点后台支撑型（node-daemon）等等各种各样的任务。
说一下稳定性方面，kubernetes是谷歌官方推出的，它的更新比较频繁，更新频繁可能带来的就不是特别稳定，大家可能理解我可以多做一些线下测试，但是事实确实是这样的，kubernetes更新非常频繁。mesos一般每半年更新一次，一年发布两个版本，会经过充分测试。mesos产品设计因为是开源的，是Apache基金会下面的顶级项目，会在社区跟大家进行投票与沟通，决定未来我们的产品怎么做，我们会增加哪些功能。

第三种主要是从功能上来讲，kubernetes是由谷歌做的，所以它的考虑会非常全面，它的生态非常全面，你想要的功能基本都有，包括网络kubernetes其实也是有的，其实kubernetes本身的网络做得不是特别好，很多用kubernetes都是用calico实现的。mesos 系统的设计思路则定义了任务调度和功能上整体依赖于调度器的设计，所以可以把 mesos 看成一个大乐高底层的基础板。
对于这两个框架，选择哪一个都没有对与错，只有适合与否，选择一个适合你们的工具才是最重要的。

mesos /container在360的一些应用

我说一下mesos /container在360的一些应用。

我们从2015年开始，就对分布式的调度系统或者容器调度平台进行了调研，最后选择使用mesos，因为我们想构建一个大型的物理资源池。在2016年业务正式上线，包括之后说的一些服务的容器化，2016年我们也使用了chronos，可以运行一些物理机上运行的crontab 任务，长时间支持服务在线运行。2017年我们已经实现了两个机房各部署了一个大型的资源池，节点达到了单集群最大1000个以上，任务达到5000个以上，10个以上的自定义framework。

解决的问题

部署

现在部署可能你只需要在marathon上改变你的镜像(image)地址，或者只需要把instance数改大就可以扩容。

故障恢复

故障恢复，如果有一台mesos-slave宕掉了，会自动在其他的节点上启动。

服务降级

关于服务降级，我们的资源池服务器是有限的，1000台服务器如果资源快用满了，有些业务就需要做服务降级，不是所有业务都有动态扩缩容。我们主要处理广告业务，广告业务实时日志流比较多，在资源不够的时候，会让某些业务降级。平时每秒处理20万条，降级时让它每秒处理10万条或者5万条，有一定数据延迟也没有关系，因为数据不会丢只会慢慢处理完。

服务发现

关于服务发现，现在有了mesos-dns和marathon-lb我们可以做到实时的服务发现，因为是动态资源划分，我们的任务就可能实时变化。

storm集群的容器化

上图是原来通过物理级部署的，所有的supervisor节点都是一台台物理机还要单独部署一个ninmbus，如果nimbus节点宕掉非常麻烦，比如有些同学说我可能会用keepalived做高可用，这确实是一种方案，但是如果你的集群需要频繁的扩容或者缩容就会非常麻烦，你要是不对资源进行动态管理的话，势必带来的就是资源的浪费，因为不可能一天24小时都满负荷运行。
把服务容器化之后，所有的supervisor都运行在container(mesos-slave)中，supervisor节点会通过 mesos-DNS发现ninmbus(master)的IP。现在集群资源都是动态利用的。

图片服务的容器化

重点说一下图片服务的容器化。

图片服务主要用的PHP7来做的，我们也会面临像阿里一样在双十一的时候，因为广告展示与投放量非常大，每秒达到上百万次，因为给用户进行展示与投放的图片会根据用户的习惯去动态的缩放与拼接。如果我放着很多机器专门用来做图片服务，可能也可以达到你的需求，但是在空闲时间段比如夜里资源浪费得非常多，对资源的利用率不是非常好。

我们就制定了这样一套方案，首先把PHP服务容器化，之后我们根据亚马逊AWS的策略，做了自己的方案，跑一个long running job，根据marathon的API获取你的图片服务具体是哪台机器，由于所有机器上的监控都用了二次开发，通过API接口能获取负载、CPU，内存等等信息。当图片服务器的负载上升了肯定是压力最大的时候，这样我们只需要设定一个阈值。

比如系统负载大于10超过10次，就进行一次扩容，扩容的倍数是1.5倍，原来我有10台机器，现在要扩容到15台。大家可能会问你这个最大能扩到多少？我一定要设定一个最大值不能无限的扩。比如我们设定一个36，最大扩到36台，在5分钟内可能判断10次，如果这个负载水平一直很高，就不进行缩容。

我肯定还会设定一个最低值，比如最低值是6台，可能到了夜里直接减为6台，每次都需要通过marathon的API实时发现后端所有机器计算出一个平均值。服务的监控，我们对每台mesos slave都有监控，具体的container我们做了异步，通过异步把日志写到graylog中，监控日志传输通过UDP协议。如果发生网络中断的情况也不会有太大影响，因为UDP是可丢的不可靠的。

其他

我们还有其他服务的一些容器化，有Web service相关的，aerospike服务，通过组播实现集群之间的通信部署起来比较方便，marathon-lb也是完全的Docker化的，毕竟是代理层像lvs一样，可能会有服务瓶颈。kafka mirrormaker我们用来进行多机房之间的数据传输，原来直接部署在物理机上，这样虽然不会有太大问题，如果宕掉之后数据不能在多个集群当中进行同步，对实时性不能要求那么高。如果做了容器化之后是可调度的，都是可高可用的，我们会保证服务的可靠性。redis也有做容器化，支持数据的落地和持久化，因为我们有cephfs还有更多的一些无状态的服务也运行在mesos之上。

最后我要说一下我们的服务ci/cd是怎么做的，ci/cd主要是通过GitLab runner。我们会定义一个Gitlab-CI，可以直接把你提交的代码进行Docker build，把镜像自动提交到对应的仓库，通过API修改marathon上面对应的地址，最后实现上线自动化。

未来计划

未来我们想做的，因为cephfs的量不是很大，cephfs之后想上一些写入量比较大的业务，看看效果如何。我们不是做公有云的对于calico的需求不是那么急切，之前一直没有上这个服务。之后我们可能会做一些calico相关的，比如一些爬虫的应用，如果用公司的Nat代理的话，可能遇到一些IP被封，导致整个代理IP都不能访问对应的网站就有一些问题了。
还有一些实时的机器学习，现在机器学习主要都基于离线业务来做，实时学习比较少，marathon和mesos本身是支持的。

本文转载自公众号360云计算（ID：hulktalk）。

原文链接：

https://mp.weixin.qq.com/s/GX4rJRJs7TP5lpEjqBEDqA

创作场景

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