网站制作资源抽象层

发布：2018-12-26 20:10:20 浏览：4601

资源抽象层主要是将下层的物理硬件资源统一进行抽象，抽象成和单个物理硬件无关的资源集合，上层无须关心物理机器的型号，只需专注于具体的资源即可。

资源抽象层需要重点做好以下三件事。第一，收集和管理具体物理资源；

第二，重新封装抽象的硬件资源属性，使之成为上层可以使用的一个实体，既可以是容器也可以是虚拟机或者资源集合；

第三，数据存储问题。做业务少不了要在本机存储数据，这样机器就成为“有状态”的，不利于全局调度资源。为了能够全局调度，需要解决三个场景下的问题:是数据不需要永久本地存储但是会实时写到本地的，如应用的日志；二是需要永久存储的如DB数据；三是分布式存储场景中，要做到存储与计算分离。

资源的收集和管理

资源的收集就是收集物理机的资源，例如当前型号的机器有多少可用的CPU、内存、磁盘等信息，它可以分为四个方面的内容。

第一，资源的信息管理。有多少，用了多少，还有多少；

第二，大量物理机器的集群管理。除了通常几十万台的机器管理功能外，还有一部分的任务管理，如负责接收Master创建容器的任务等。

第三，资源的合理分配策略和算法。上层的资源请求最终会在每台物理机上进行分配，那么如何能?这里有根合理的分配策略和算法支撑。

第四，资源的信息管理就是要实现一个CMDB，能管理物理机和vhostI的关联关系，必须能管理上万台甚至十几万台规模的机器集群。这样的机器集群管理框架目前可选的比较少，我们选择的是Mesos，主要基于以下两方面的考虑。一是Mesos目前相对比较成熟，主流的大公司使用较多，在实际场景中的使用规模已达5万台左右；二是Mesos扩展性比较好，本身是轻量级的，可以灵活定制各种Framework满足业务需要。

我们分析一下为什么Msos能管理这么大的集群，它的资源分配策略以及它是如何灵活创建各种容器和配置网络的。Mesos的集群架构。

Mesos的模块化设计使得它的集群管理本身可做的事情并不多:Master仅仅把从Save收集的资源数据汇报给Framework；Master和Slave通过消息交互消息，不需要一直保持长连接。随着Slave规模的扩大，Master的压力并不会显著增长。Master本身的高可用是通过ZK(Zookeeper)来保证的，整个集群的架构设计非常清晰。

当集群规模很大时，资源的管理和分配策略就会非常重要。分配策略对于最大化充分利用物理资源非常关键，所以要自己定制Framework以便更精细化地分配资源。目前我们设计了4个分配策略。

(1)最大内存剩余优先分配策略。即集群中内存剩余最多的优先分配，目的是充

(2)最大CPU剩余优先分配策略。类似于内存分配，根据剩余的CPU数优先分配给对CPU资源需求大的任务；

3)最大最小资源公平分配策略。这种分配是根据当前任务申请的资源，要查看当前集群中的每台机器、每种资源的使用量是否饱和，优先把任务分配给当前最空闲的机器；

(4)根据资源分配指定分配策略。这种方式比较灵活，就是可以根据用户的需要把任务分配到指定的机器上执行，例如可以给一些机器打上标签，让某类任务在这些带有标签的机器上执行。

从上面的介绍可以知道网站制作Framework的修改需要比较灵活的支持，而当前 Mesos的 Framework的更新还比较麻烦。如果要更新 Framework的代码，就需要重启每个Slave的 execute，进而可能要停止 Slave上的任务，这在生产环境中是很难接受的。有鉴于此，我们对 Framework进行了无状态设计，在代码实现上，改用动态语言如Groovy来编写需要经常修改的逻辑，这样Govy实现的代码就可以动态加载而不需重启任务，对 Framework的功能进行调整就非常方便了。