【编者的话】这篇文章是在一个微信群里和人聊天,然后整理出来的文字。当时Hulu推出了基于Yarn的Docker调度引擎。我正好那段时间也实现了一个类似的,经过交流,发现最后的实现基本是一致的。然而业界用的较多的是Mesos,这篇文章就是为了解释为什么选择用Yarn而不是Mesos来做。
Mesos其实我不是非常熟悉,所以有些内容可能会有失偏颇,带有个人喜好。大家也还是需要有自己的鉴别能力。
Mesos和Yarn都非常棒,都是可编程的框架。一个硬件,不能编程,就是死的,一旦可以编程就活了,就可以各种折腾,有各种奇思妙想可以实现,同样的,一个软件,只要是可编程的,基本也就活了,容易形成生态。
我先说说在做容器调度引擎的时候,为什么选择Yarn而不是Mesos。
先说明下,这里探讨的是Yarn或者Mesos集群的部署,不涉其上的应用。Yarn除了依赖JDK,对操作系统没有任何依赖,基本上放上去就能跑。Mesos因为是C/C++开发的,安装部署可能会有库依赖。 这点我不知道大家是否看的重,反正我是看的相当重的。软件就应该是下下来就可以Run。所以12年的时候我就自己开发了一套Java服务框架,开发完之后运行个main方法就行。让应用包含容器,而不是要把应用丢到Tomcat这些容器,太复杂,不符合直觉。
Yarn 对Java/Scala工程师而言,只是个Jar包,类似索引开发包Lucene,你可以把它引入项目,做任何你想要的包装。 这是其一。
其二,Yarn提供了非常多的扩展接口,很多实现都是可插拔。可替换的,在XML配置下,可以很方便的用你的实现替换掉原来的实现,没有太大的侵入性,所以就算是未来Yarn升级,也不会有太大问题。
相比较而言,Mesos更像是一个已经做好的产品,部署了可以直接用,但是对二次开发并不友好。
Yarn 诞生于Hadoop这个大数据的“始作俑者”项目,所以在大数据领域具有先天优势。
谈及长任务(long running services)的支持,其实大可不必担心,譬如现在基于其上的Spark Streaming就是7x24小时运行的。一般而言,要支持长任务,需要考虑如下几个点:
大家感兴趣可以先参考 Jira 。我看这个Jira 13年就开始了。说明这事很早就被重视起来了。
日志收集在2.6版本已经是边运行边收集了。
资源隔离的话,Yarn做的不好,目前有效的是内存,对其他方面一直想做支持,但一直有限。这估计也是很多人最后选择Mesos的缘由。但是现在这点优势Mesos其实已经荡然无存,因为Docker容器在资源隔离上已经做的足够好。Yarn和Docker一整合,就互补了。
Mesos 和 Yarn 都是非常优秀的调度框架,各有其优缺点,弹性调度,统一的资源管理是未来平台的一个趋势,类似的这种资源管理调度框架必定会大行其道。
脱胎于Hadoop,继承了他的光环和生态,然而这也会给其带来一定的困惑,首先就是光环一直被Hadoop给盖住了,而且由于固有的惯性,大家会理所当然的认为Yarn只是Hadoop里的一个组件,有人会想过把Yarn拿出来单独用么?
然而,就像我在之前的一篇课程里,反复强调,Hadoop是一个软件集合,包含分布式存储,资源管理调度,计算框架三个部分。他们之间没有必然的关系,是可以独立开来的。而Yarn 就是一个资源管理调度引擎,其一开始的设计目标就是为了通用,不仅仅是跑MR。现在基于Yarn之上的服务已经非常多,典型的比如Spark。
这里还有另外一个误区,MR目前基本算是离线批量的代名词,这回让人误以为Yarn也只是适合批量离线任务的调度。其实不然,我在上面已经给出了分析,Yarn 是完全可以保证长任务的稳定可靠的运行的。
作者: 祝威廉