Marathon 0.7.0 中的新特性

by Iven Hsu — on  , 

cover-image

Marathon 是基于 Mesos 的分布式服务管理平台,功能相当于 Upstart/systemd 等 init 系统,只不过 Marathon 是用于集群的,用于建立 PaaS 十分方便。

Marathon 0.7.0 版本,带来了很多新特性,说是其诞生以来最大的改动也说不定。根据官方说明,主要有以下几点。

原生 Docker 支持

就如之前所说,Mesos 0.20 带来了原生的 Docker 支持,而不再使用不完善的 mesos-docker 或者 deimos 作为插件形式存在。

现在,Marathon 不再自行调用 docker 命令,也不再借助第三方的 deimos 来调用,而是在构建任务信息的时候,直接构建 container 信息,发送给 Mesos,由 Mesos 内部的 Docker containerizer 来进行操作。

这样无疑整合性更好,稳定性等方面都会有提升。

应用程序组

Marathon 现在支持将运行在其上的应用程序/服务分组,便于统一管理。

组依赖

分组之后,可以指定两个组的依赖关系,比如Web 后端组可以依赖于数据库组。这样在启动、关闭、删除等操作时,Marathon 会考虑依赖关系,按顺序启动和关闭。

组扩展

假如将应用程序 A、B、C 合并成 group1,那么如果对 group1 进行 Scale,比如增加 50% 的实例,那么 A、B、C 三个应用程序都会增加 50% 的实例。

这对 Auto Scaling 很有用,Web 后端和数据库等可以根据负载大小同时进行扩展。

滚动部署

这是一个期待已久的改进。之前应用程序升级的时候,就面临一个问题:必须重启所有实例,才能使新的代码生效,而如果同时重启所有实例,就意味着服务中断。如何保证服务质量的同时进行升级,就成为一个重要问题。

Marathon 0.7.0 为此问题提供了一个解决方案:你可以为应用程序指定一个 minimumHealthCapacity 参数,比如设置为 0.6,那就表示 Marathon 会在整个升级过程中保证 60% 的实例是正常服务的。

为什么不设置成 100% 呢?这要从升级的步骤说起,假设是 60%,那么 Marathon 会:

  • 将旧实例 Scale 到 60%。
  • 启动 60% 的新实例。
  • 销毁所有旧实例。
  • 启动剩下 40% 的新实例。

也就是说,设置成 60% 的时候,最多会占用 120% 的集群资源(第二步)。那么如果设置成 100%,峰值就会达到 200%,需要保证集群有足够资源才行。

Artifact Store

新版 Marathon 的一个可选功能,主要是用于非 Docker 环境下,作为一个存储缓存来用。

在不使用 Docker 的时候,往往是使用一个源码/二进制压缩包来部署应用程序,这时 Marathon 可以自动将这些压缩包下载,然后缓存到 HDFS 等存储上,来达到减少下载服务器压力、提高部署速度等目的。

Docker 由于有自己的 Docker Repository,所以在使用 Docker 的时候不需要这个功能。

健康检查

Marathon 现在支持 Mesos 的 Executor 健康检查功能,可以通过 HTTP、TCP 等方式,检查 Executor 是否处于健康状态。

这对于应用程序的升级、监控等很有用处。如果使用 nginx 等做负载均衡的话,也可以据此判断是否需要分配负载到不健康的 Executor 上。

总结

Marathon 现在越来越成熟了,从 0.5.1 像玩具一样的功能,慢慢成长为一个完整成熟的系统了,滚动部署、健康检查等功能的加入,说明 Marathon 已经越来越考虑生产环境下对容错、稳定性等的需求。

再加上 Mesos 对 Docker 支持的完善(Mesos 0.20.1 已经发布了,修复了很多 Docker 支持相关的问题),基于两者建成一个功能强大的 PaaS 系统,看来不是问题。

评论