Hadoop体系里面,有个非常让其拥趸津津乐道的概念,混合部署。其基本含义就是将多个应用和组件部署在一个集群,共享一套资源,以获取资源的高效利用。物理机环境没有弹性的能力,这个混合部署概念弥补了部分弹性的需求。
先来看下产生的历史,Hadoop 1.0时代只有MapReduce/hdfs/zookeeper三大件,1.0时代只有MapReduce一种服务,没有共享的必要。Hadoop 2.0 YARN横空出世,主要概念来源于伯克利的mesos的思路,期望用同一个资源管理器管理所有资源共享给所有服务。YARN最主要作用就是将物理机环境的所有资源全部管理起来;各种该服务的资源由YARN统一分配和管理。随着资源管理器的发展的同时,2.0时代应用繁荣起来MapReduce/Hive/Spark/Hue/HBase,中间为了解决长期运行资源服务管理问题,还有一个专门的slider组件。Mesos出来也更早,相当长一段时间mesos和yarn还竞争了一把;最后mesos拗不过社区的力量改道搞应用部署,又去和K8S PK上了。
总的来说,在物理机环境中,这个思路还是非常先进的,但是今天演进到云环境是否还适用值得商榷一下,为什么这么说:
- 云时代,资源都是云平台统一管理。首先分配的粒度本身就很细,可以支持到0.5个cpu。需要多少,向云平台申请,用多少付费多少,非常弹性;可以如果还是老思路,提前固定申请一批,再分配给各个应用。完全没有享受云弹性的能力。
- 其次可以根据不同的应用需求,还可以灵活申请不同的规格,更好的匹配应用特点和充分利用资源。比如有些应用需要cpu多,有些应用需要IO强;YARN只能统一管理同规格服务器,很难照顾到每个应用的不同需求,非常容易申请过多,造成资源浪费。
- YARN概念非常先进,但是实际上管的好还是MapReduce,YARN一直没有很好的解决应用之间的资源争抢问题,尤其是不同特点的应用。例如HBase这种常驻型服务,机制上为了保证实时性,会尽量去占用所有的内存,HBase跑的好,其他服务就跑不好;其他服务跑好了,HBase基本也跑不好。类似问题spark,storm等都有。
所以云上最合理的是每个服务跟进自己的特点和需求,单独申请资源,自行管理。是时候丢掉在物理机时髦的混合部署的概念了。要充分去利用云平台本身的弹性能力。当能大部分公司,最简单的方法就是直接申请对应的云服务,将这些复杂的资源管理和运维的工作让云服务厂商负责,从而专注自己的业务。