本文从个人公众号开始。 TechFlow，原创很难。 请要求关注
今天是分布式专题的第11篇文章。 谈谈分布式集群资源管理。
在开始文章之前，先问个问题吧。为什么是国际上是亚马逊，国内是阿里这两家公司云计算搞得最好呢这两家公司之间有很大的共同点。 它们都是电商公司电器公司特点明显，流量不固定，往往受到大促、节日的影响。 像国内的双十一和美国的黑色星期五这样的东西是典型的大促进。 剧烈时的流量是平时的10倍以上。 这么大的流量需要更多的机器来应对。 但问题是，即使去买这么多机器，如果流量突然下降，那些机器就不能使用了，显然是浪费了。
怎样才能变成避免浪费？ 组成大集群，管理所有的机器和计算资源，大的时候用来应对大流量，平时可以进行大数据运算，或者租给其他公司或者个人，形成一定的经济利益。 总是不让这些机器闲着，以免浪费
本质上，亚马逊和阿里在云计算、云服务器背后的核心驱动因素之一就是为了解决这个问题。
集群资源管理集群资源管理是分布式非常普遍的应用场景，可以说无论公司大小都必然存在着接触。 像AlibabaCloud (阿里巴巴云)和亚马逊云一样高，但底层离不开这个。
这个问题的背景非常简单，大小公司往往都不止一套系统但是公司资源有限，固定，但是我们需要机器的场景很灵活。 例如，今天新系统上线，需要占用几台服务器。 明天这个系统无效，所以撤去，清除这些服务器。 最初没有动态管理的集群系统，在运维上手动操作，所以在当时的运维中练习了单手拔网线的优秀手臂和强健的手部肌肉。
在大数据时代到来之前，设备的更换基本上大多是系统在线和离线，这还是件好事。 一般公司的系统变化不是特别频繁，但是大数据时代来了之后，临时任务的数量大幅增加。 今天需要去取用户的这个数据。 明天需要汇总报告，计算往返的临时需求。 而且，这些需求对很多机器(大数据啊。 机器少了也做不完)。 反正也不能用运输人肉处理吧。 也不能期待每次开发都能磨练运输技巧，这既浪费时间又不现实。 所以很自然地，人们想到开发一套系统就做了这件事。
于是集群资源管理系统应运而生。 就像我们经常听到的Yarn，Mesos，Corona等，做这个。
了解了系统架构资源管理系统在做什么之后，我们来看看架构吧。
那个架构本身并不复杂，本质上这个系统只做了两件事。 一个是分配，另一个是回收。 对功能有很好的理解，我们需要把任务分发给机器。 任务执行后，必须先回收资源再分配其他任务。 但是，从逻辑上讲，实现这两点并不容易。
首先，我们需要需要知道当前所有任务的情况例如，需要多少机器，运行的状态是否还没有开始、已经开始或者已经结束？ 如果结束，则需要回收设备。 如果尚未开始，则需要分配设备资源。 其他还需要知道资源的情况可以分配哪些资源被哪些任务占用，哪些可用。 为此，必须保证系统与所有机器的通信。 此外，还需要一个为执行分配策略尚未执行的任务分配资源的程序。 整理一下这些内容，就可以画出系统架构图。
简单地说上图，上面的部分是我们的资源管理系统，下面的部分当然是机器。 因为一台物理机功能非常强大，所以将多个容器放在其上，而不是一般我们不会直接接入系统。 这相当于多个虚拟机。 也就是说，将一台机器设为多台并加入集群。 这个过程称为虚拟化。 以前很多C工程师都专门针对这一点，但现在docker的兴起，据说很多都在转变为docker。 好处是，如果有单个或多个容器悬挂，而整个物理机都是活着的，那么可以随时重启另一个原因是，一般没有大到要吃掉整个物理机的资源的任务，而且也节约了资源。 除了容器外，还需要节点管理器负责与整个管理系统进行通信。
资源收集器收集这些容器的当前状态，并将它们添加到资源池(如果有)。 也就是说现在可以使用的意思。 计划效应器发现新计算机可用后，它会检查任务队列并将某些任务分配给可用的容器。 工作队列中的任务有很多类型，例如spark、MapReduce等。
可以看出，其中调度策略执行器是整个管理系统的核心，其他所有模块都为其提供了服务。 详细的分配策略有很多细节和逻辑，所以将具体的策略内容放在下一篇文章中。 我们需要大的东西
概的认识，知道它是负责调度任务和分配执行的即可。 集群管理的优缺点虽然我们已经有了管理系统，看起来好像牛哄哄的。但是这方面目前仍然处于摸索状态，还远远没有成熟。这些系统之间多有不同，但是原理都是类似的，本质上都是在我们的硬件资源之上抽象出一个管理系统，就好像雇佣了一个工作飞快永远不会累的管家。我们只需要告诉他，我们当前需要做什么，需要多少资源。至于怎么分配，怎么完成，统统交给他，我们再也不用操心。
这么做和之前人肉分配相比，进步了非常多，有非常明显的优点。我们随便就可以列举出好几条。
优点比如我们的机器利用率变高了，因为之前人工分配了资源之后资源就固定了。比如分配给A任务一台机器，但问题是A任务并不是一直满负荷的。可能白天流量大，消耗高，但是到了晚上流量就小了，占用的资源就少了。而B任务可能相反，白天不需要运作，到了晚上开始发力，需要大量计算（比如现在很多机器学习的大型job都是凌晨跑的）。如果是人工分配的话，我们可能需要两台机器分别执行A和B，但显然这是不合理的，因为我们完全可以把它们合并，让它们互相互补。但是每天都依靠人力来做这件事情是不现实的，万一运维哪天忘了不是完蛋了。而有了管理系统，会有个系统替我们做这件事，它会把所有资源都安排妥当，自然利用率就高了。
其次，某种程度上来说也减少了数据存储的消耗。比如之前的用户数据在许多系统当中用到，不同的系统需要单独存储一份。不然不同的team用同一份数据很容易出现责任划分不清楚扯皮的问题，有了分布式管理系统之后，我们只需要在分布式系统当中存储一份数据找专人维护即可，避免了重复劳动。
最后，支持多种计算框架。比如像是Yarn，mesos等集群支持众多计算框架，无论是MapReduce也好，还是spark也罢，或者是hive等等都可以用一套系统来管理，非常灵活方便。甚至还可以支持多版本，也不会影响。
不足凡事有好有坏，没有事情的完美的。既然有优点必然有不足，关于调度策略产生的问题，我们今天先不谈，今天主要讲讲调度系统本身的问题。
第一点也是最重要的一条就是风险，表面上看我们使用集群调度系统降低了集群的风险，因为单个的节点挂了并不会影响整个集群的运行。我们只需要找到单个节点挂掉的原因进行修复，或者等待系统自动重启就好了。系统宕机的风险被均摊了，但问题是均摊风险其实本身就是很危险的事情，它也意味着风险的聚集。
比如说有没有想过如果集群管理系统本身宕机了呢？
如果连负责任务调度的系统都挂了，显然整个集群也就完蛋了。这种事情看似发生的概率非常小，但是一旦发生，对于企业带来的影响和损失是巨大的。据说之前阿里云宕机了一个下午，中国大半个互联网的网站受此影响无法访问。这也是阿里这几年一直在搞异地多活，各种容灾备案的原因。
第二个不足是系统目前还不够智能，比如说如果集群规定了每个任务最多占用的资源总量，突然我们扩容了机器，或者是临时有一个大任务需要超额。这些情况都需要人工干预，再比如对于系统开发的时候能够预料的一些问题有很好的解决措施，比如节点挂了，资源吃满了等等。但是对于没有预料到的问题则完全解决不了，比如某个节点卡死了，没有挂一直占着资源。
再比如一些集群里被人为安置了一些非法的脚本，比如黑客的入侵脚本，或者是挖矿脚本等等。前阵子比较火的某度员工在公司机器上挖矿了好几个月才被抓，为什么没能及时发现？因为资源都是系统调度的，人工很少干预，也没人会去整天看系统里到底都在跑些什么任务。
当然，有问题就有前进的方向，这些问题其实也反应了我们目前这一块还有很长的路要走，目前的方案还比较原始。以后应该会有更好用的集群管理的设计理念也会有更好的系统，当然万丈高楼平地起，未来的方案也是基于当下一点一点改进得到的。我们学习的目的和意义也正在于此。
今天的文章就是这些，如果觉得有所收获，请顺手点个关注或者转发吧，你们的举手之劳对我来说很重要。