发明内容
本发明的目的是提供一种适用于云计算***的资源数据读取方法,优化DAG算法,合并相同资源数据请求,采用两段式存储方案,防止重复的调用接口来获取同一份数据,以并发的方式处理资源数据,从而更充分利用云计算***的并发处理能力,整体提升资源数据读取速度。
本发明通过以下技术方案得以实现的:一种适用于云计算***的资源数据读取方法,包含如下步骤:
S01、依赖规则形成步骤;
在该步骤中,将本地数据库中的资源依赖关系和云平台上的资源依赖关系进行整合,形成最终依赖关系;
S02、依赖表格确定及入库步骤;
将最终依赖关系形成依赖表格并保存入本地数据库,所述依赖表格包含依赖关系内容和任务属性内容,所述任务属性内容显示任务为同步云平台任务或入库任务,所述依赖关系内容反映资源之间的依赖关系;
S03、同步云平台任务执行步骤;
管理客户端中存在生产者线程来生产和发布任务节点,存在消费者线程来消费和执行任务节点,生产者线程生产和发布任务节点的顺序按照依赖表格中的资源依赖关系顺序,所述消费者线程执行所述同步云平台任务,将资源数据内容从云端导入缓存;所述消费者线程为多个;
S04、计算步骤;
管理客户端针对缓存中的数据进行计算,触发该资源的入库任务,且触发该资源依赖关系中的下位资源的同步云平台任务;
S05、资源入库步骤;
所述消费者线程执行已经被触发的资源入库任务,将该资源的数据内容从缓存导入本地数据库;
S06、结束步骤;
当所有资源所对应的任务均已结束完毕,DAG算法遍历完成,结束入库。
作为本发明的优选,在S02中形成的所述依赖表格还包含云平台属性内容,所述云平台属性内容中记载的为平台的类型。
作为本发明的优选,设置的所述消费者线程的数量小于或等于所述依赖表格中反应的资源依赖DAG图中的路径总数量r。
作为本发明的优选,在S03步骤中,存在着第一次资源数据转换,所述管理客户端将资源数据从DTO对象格式转换成BO对象格式,资源数据以BO对象格式存入缓存。
作为本发明的优选,在S05步骤中,存在着第二次资源数据转换,所述管理客户端将资源数据从BO对象格式转换成PO对象格式,资源数据以PO对象格式存入本地数据库。
作为本发明的优选,设置的所述生产者线程的数量为一个。
作为本发明的优选,S01具体包含如下步骤:
S011、云平台资源依赖关系梳理步骤;***管理人员对云平台中,各个资源存在的依赖进行梳理;
S012、本地数据库资源依赖关系梳理步骤;***管理人员对本地数据库中,各个资源存在的依赖进行梳理;
S013、整合步骤;***管理人员对S011和S012的两份资源依赖关系进行整合,形成最终依赖关系。
作为本发明的优选,在S05步骤中,存在数据比对环节,每个资源都被分配一个唯一的标识UUID,所述管理客户端将需要入库的资源的UUID和本地数据库中的资源的UUID进行比对,若该UUID已经存在,则对比该资源的所有属性,若有变化则判定为更新操作,且输出对应的更新变化日志。
作为本发明的优选,在数据比对环节中,若某一UUID在数据库现有资源中存在,在需要入库的资源中不存在,则判定为删除操作,删除操作的优先级高于更新或新增操作的优先级。
作为本发明的优选,所述缓存为Caffeine缓存。
综上所述,本发明具备如下有益效果:
1.在本发明中,使用了二段式任务的处理方式,即同步云平台任务、入库任务的独立处理,分别将资源数据从云端拉入缓存,从缓存进入到数据库。二段式任务引入了缓存,这样的好处是,缓存被多次依赖的中间资源数据,防止重复的调用接口来获取同一份数据。在现有技术中,直接将云上的数据拉到数据库,各个消费者线程会重复拉取数据。而在本发明中,缓存是各个消费者线程共享的,其可以防止各个消费者线程重复调用接口以及防止重复处理获取到的接口数据。
2.在我方的技术方案中,是存在多个消费者线程并发操作,采用并发的方式请求数据,以充分利用云计算***的并发处理能力从而提升运行效率。
3.而本发明在同步云平台任务和入库任务这两个阶段都使用了DAG图算法,按顺序获取资源数据,合并相同资源数据请求,以较少对网络资源的占用。
4.本发明的DAG图算法,存在一个云和本地的整合过程,即对云上的资源依赖关系和本地的资源依赖关系进行了整合,形成了最终的资源依赖关系,使得资源在复制的过程中既保留了云上的数据依赖关系,又匹配了本地的资源依赖规则。
5.数据设计为三层模型,分别是SDK数据传输层(DTO对象)、应用业务层(BO对象)和数据库层(PO持久化对象)。这样的设计可以使数据层次更为分明,减少层与层之间的耦合,每层都有自己对应的数据格式,方便之后的维护扩展。
6.生产者线程只设定一个,生产者线程是一个同步非阻塞的线程,效率较高,无需设置多个来占用***资源。而消费者线程设置为多个,充分发挥云计算***的并发处理能力。
7.删除不存的资源,该步骤的优先级最高,删除不存在数据可以保证数据库的准确性,防止后续对资源进行***更新操作时产生异常。
8.数据入库阶段为批量入库,减少数据库的链接次数。在提升效率的同时,还做到了完整的日志输出,记录了资源每一个属性的变化情况,每一个资源的增删情况等。
9.数据入库阶段的删除操作的优先级最高,删除不存在数据可以保证数据库的准确性,防止后续对资源进行***更新操作时产生异常。
具体实施方式
本具体实施例仅仅是对本发明的解释,其并不是对本发明的限制,本领域技术人员在阅读完本说明书后可以根据需要对本实施例做出没有创造性贡献的修改,但只要在本发明的权利要求范围内都受到专利法的保护。
实施例1,一种适用于云计算***的资源数据读取方法,在***搭建逻辑方面,如图1所示。图1中最右侧的为云计算***,可以为openstack云计算***,也可以为eloud云计算***,本技术方案平台类型没有具体限制,但是需要说明的是,要求这些平台能提供相应的API或者SDK能够获取到资源数据。在本实施例中,使用了openstack云计算***,其包含有API用于通信。API为Application Programming Interface,应用程序接口。
左侧的框图中,为本实施例的管理客户端,该客户端为程序,可由软件设计人员通过现有技术中的JAVA语言编程并实现本文所列举的功能。其包含前端的管理页面。管理客户端的主要作用是触发资源同步动作,可以针对某一个单独的管理域进行操作。管理客户端还可以对管理域进行管理,增加或者删除一些额外的云资源。
左侧的框图中需要做重点说明的是数据缓存和数据存储这两个部分。数据存储的实现形式为本地数据库,如mariadb数据。本实施例所说的资源数据获取方法,其最终的实现形式就是从图1右侧的云计算***中,将资源同步到图1左侧最下方的数据存储中。
但和现有技术不同的是,在本发明中,还存在数据缓存。数据缓存,在本实施例中的具体缓存形式是采用了Caffeine缓存。数据是先从云端到数据缓存后,再通过计算,最终进入本地mariadb数据库,具体流程下文详细论述。
首先,步骤S01,依赖规则形成步骤。在这一步骤中,形成的是各个资源之间的依赖关系。资源是指数据资源,并不是某一条具体数据的数据内容被称为一个数据资源,而是某一项数据类别,数据类型,被定义为一个数据资源。例如虚拟机(Virtual Machine)、数据卷(Volume)、安全组(Security Group)这些就是数据资源。
而在这个步骤中,具体分为三个步骤。
S011、云平台资源依赖关系梳理步骤。在这个步骤中,***管理人员对云平台中,各个资源存在的依赖进行梳理。依赖关系可视为数据逻辑的先后顺序,例如虚拟机(Virtual Machine)依赖数据卷(Volume)、安全组(Security Group)等资源。因此必须在同步完数据卷和安全组之后才能同步虚拟机,这样他们之间的关联关系才能被正确的维护。
这个依赖关系的梳理可以为***管理人员手动梳理,也可以通过编程,机器自学习,来实现自动化。
S012、本地数据库资源依赖关系梳理步骤。
这一步骤与S011的原理和操作方式一致,区别为在本步骤中,梳理的不是云平台中的资源依赖关系,而是本地的数据库依赖关系。
S011和S012的资源依赖结果,可以以DAG图来表示。
S013、整合步骤。
由于在实际操作中,本地数据库的资源类型、数量,与云平台的资源类型和数量也会有差别,自然规则会有不一致的地方。在本步骤中,将两份依赖关系进行整合。如,在S011中,云平台的数据资源依赖关系中,存在>Subnet->port,Router->port,DataCenter->Host->port。这就表示port依赖于Subnet、Router和Host。然而在S012中,本地数据库的资源依赖关系中,发现port 依赖 subnet、依赖 router、依赖 network。所以,在最后确认的依赖关系中,整合出的最终依赖关系,port不仅依赖于subnet,router,host,还依赖于network。
步骤S02,依赖表格确定及入库步骤。
在该步骤中,生成了依赖表格。在该表格中,至少包含如下三项内容:任务属性内容,依赖关系内容,云平台属性内容(从权)。如在本实施例中,具体表现为下方表格:
在该种表格内,name为任务属性内容。在本技术方案中,只存在两种任务属性,分别是sync和persistence。Sync表示为是同步云平台任务,其数据流向是从云平台进入缓存,persistence表示为是入库任务,其数据流向是从缓存进入到本地数据库。
而source和destination用于描述DAG中的一个依赖关系,可以看做是DAG图中的一个箭头,destination依赖于source。如图中,port依赖于subnet,这在DAG图中,就类似存在subnet节点和port节点,两个节点之间画有一个指向port节点的箭头。
Type为云平台属性内容,用于区分云平台的类型,不同云平台的资源可能会有所不同,加以区分会增加***计算顺畅度。如在上方的表格中,云平台的类型为openstack。
至此,数据读取、数据迁徙的准备工作,已经完成。
在本实施例中,步骤S02结束之后还存在一个云平台权限认证的步骤,从而来加强数据操作的安全性。以openstack平台为例,使用的是openstack4j的SDK,通过配置的账号密码进行认证,并保存认证客户端Client。由于openstack的Client不能在多线程中使用,因此需要保证线程的私有性,使用ThreadLocal保存。其它云平台可以按照SDK或者API的特性做具体处理,若支持多线程共享,则应该只认证一次。
步骤S03,同步云平台任务执行步骤。这一步骤的任务是将资源数据从云计算***复制、同步到缓存中。这里需要说明的是,资源数据复制的顺序要严格按照步骤S03中确定的资源依赖关系。如图3所示,图3是图2左上方位置的放大图,图3中可以看到,port资源依赖于subnet资源,若subnet资源没有同步完毕,则port不允许同步,资源数据的同步严格遵循依赖规则。具体的规则逻辑编程方式下文会进行详述。
此外需要说明的是,诚如上文所述,在步骤S03中,建立且保存了依赖表格。“资源”不等于“任务”,如图3中的subnet,它是一个资源的名称,它存在两个任务,分别是subnet的sync任务和subnet的persistence任务。在本步骤中,执行的是sync任务。
此外,在该步骤中,还存在着数据转换。
数据格式转换在整个技术方案中,实质进行了两次转换,在该步骤中,实现第一次转换,本发明中的资源数据可分为三层:SDK数据传输层(DTO对象)、应用业务层(BO对象)和数据库层(PO持久化对象)。云端的数据为DTO对象,而要同步到缓存中的则为BO对象。此时,模型转换模块(依靠JAVA编程实现),首先将SDK同步到的资源数据转换成业务层BO对象,相比于同步到的DTO对象,BO对象保存了额外的业务逻辑和资源之间的关联信息等。
步骤S04,计算步骤。本步骤中,计算的主体是上文提到的管理客户端,计算的具体功能实现是通过软件设计人员依靠JAVA语言编写得到,具体的执行代码为现有技术内容,本发明不做赘述,这里具体解释该步骤中的计算内容。
在该步骤中,最主要的是两个计算任务,分别是资源数据入库任务触发和下位资源数据的同步任务触发。
其中,资源数据入库任务触发,依旧以图3中的subnet举例,诚如上文所述,它是一个资源的名称,它存在两个任务,分别是subnet的sync任务和subnet的persistence任务。在本步骤中,触发的是subnet入数据库的任务,即persistence任务。
而下位资源的同步任务触发是指,如图3所示,此时,port的sync任务也被触发了。Port资源之后也要经历上文所述的同步到缓存、数据格式转换、触发其下位资源sync的操作,与上文一样,这里不再赘述。
步骤S05,资源入库步骤。
如上文所述,subnet的入库任务已经被触发,即persistence任务已经被触发,此时就要执行subnet的persistence任务。
在入库之前,模型转换模块又会进行第二次转换操作。将BO对象转换成可以存入数据库的PO持久化对象,PO对象的属性对应了数据库表的各个字段同时也保存了BO对象额外的业务层信息。
在本发明中,数据设计为三层模型,分别是SDK数据传输层(DTO对象)、应用业务层(BO对象)和数据库层(PO持久化对象)。这样的设计可以使数据层次更为分明,减少层与层之间的耦合,每层都有自己对应的数据格式,方便之后的维护扩展。
步骤S06,结束步骤。
当所有资源对应的任务都执行完毕,即所有资源的DAG图已经遍历完成,则所有资源入库结束。
需要说明的是,在上文提及的S02到S05步骤中,并不是把所有资源的sync任务完成后,再去统一一起去做所有资源的persistence任务,并非是“批量执行”,而是“逐个进行”。即一个上位资源,如图3中的subnet做好了sync任务,并不是等所有的资源都做执行了sync任务后,subnet才能做persistence任务,而是subnet先完成自己的persistence任务,同时触发了其下位资源,port的sync任务。
诚如上文所述,不管是sync任务还是persistence任务,都要遵循各个资源的依赖关系,即使用到DAG技术。下文对本发明中具体的DAG操作方式进行说明。步骤S03到步骤S05中,都会使用到该DAG技术。在本发明中,DAG具体操作方式如下:
本实施例使用producer和consumer产生和消费DAG节点,producer为生产者线程,consumer为消费者线程。
如图2所示,每一个DAG节点都有一个对应的函数来执行相应的同步操作。在本实施例中会有一个线程安全的集合(Collections.synchronizedSet)用来存储已经执行完成的节点。
producer的逻辑是根据已经执行完成的节点获取接下来可以执行的节点,数量可能是多个或者一个,之后将可以执行的节点存储到队列中,本实施例使用的是线程安全队列:LinkedBlockingQueue,可以保证队列数据在多线程模式下的准确性。但在本实施例中,producer数量设定为一个。
consumer是一个不断轮询的线程,它不断获取队列中可执行的任务,调用执行引擎执行对应的同步方法,之后consumer会将改节点置为执行完成,保存到已完成的节点集合中。当producer无法产生新的任务节点时,整个流程结束,此时producer会向队列中存放一个终结信号:TERMINAL_SINGLE,consumer拿到这个信号的时就会结束轮询,整个同步任务执行完成。
其中,节点的执行引擎逻辑是根据节点名称来查找相应的函数并执行,本实施例中的执行引擎使用的是反射调用的方式,需要项目内配置好节点和执行函数的映射,否者无法调用成功。详细步骤如下:
第一步,初始化各类任务集合,已完成任务集合设为S=∅;可执行任务集合V=∅;剩余任务集合U;任务关系集合R。任务记为
,对应DAG中的所有节点。集合R中存放的是节点间的依赖关系,两两成对,后面的任务依赖前面的,例如
,表示后者依赖于前者。程序刚开始时S和V集合为空,所有的任务都存在集合U中,即:
。
第二步,初始化消费线程集合
,这些线程负责从集合V中读取待执行的任务并执行。初始化生产线程P,生产者线程只需要一个,生产者线程P是一个同步非阻塞的线程,效率较高。
第三步,生产线程发布任务,当任意一个任务执行完成之后,生产者线程P会遍历已完成任务集合S以及任务依赖关系集合R,来查找可以执行的任务,之后将这些任务放入可执行集合V中。线程P判断任务
是否可执行逻辑:若对于
,都满足其中
,其中i≠j,那么任务
即是可执行的任务。
第四步,消费线程C通过读取可执行集合V来消费可执行的任务,当任务执行完成之后将任务放入集合S。
第五步,当剩余任务集合U为空,即满足:U=∅时,所有任务分发完成,状态为可执行、执行中或执行完成。此时生产者线程P会发送m个任务结束信号TERMINAL_SINGLE到可执行集合V中,消费者线程C通过读取结束信号终止轮询。当集合V=∅时,整个DAG算法执行完成。
注意这里的可执行集合V的实现为同步队列,只有当所有可执行任务被消费者线程消费之后,终止信号才会被消费,防止任务没执行完成,消费者线程提前结束。当任一消费线程执行任务异常时,消费者线程会通知生产线程P发起结束信号,提前终止整个算法流程。
以上内容,解释了本技术方案中,如何使用DAG算法来基于依赖关系去处理资源任务,需要说明的是,不管是sync任务还是persistence任务,都是使用了上文所述的相同的DAG算法逻辑。
此外,这里对生产者线程和消费者线程的数量设定进行解释。在本实施例中,生产者线程只设定一个,这是因为生产者线程是一个同步非阻塞的线程,效率较高,无需设置多个来占用***资源。
而消费者线程则不然,在本实施例中,设定为多个,m个,应该满足的取值1≤m≤r。r为DAG图中的路径总数量。如图4所示,图4的节点内容与图2一样,图4上面标示了路径明细。根据节点的依赖关系,图4中的路径总数量为18个。图5为图4的下部的局部放大图,图5中可以看到,从image-imagemember为一条路径,image-vmsnapshot是另一条路径,storage-volumetype-volume是另一条路径,storage-volumetype-cinderstorages是另一条路径,图4中一共存在18个路径。路径数量计算方式为DAG技术中的现有技术内容,此处不再赘述。
由于同时任务执行时间存在不确定性、任务之间存在各种复杂依赖关系以及消费者生产线程调度的随机性,使得没有公式能够求解m的理论最佳值。但是可以肯定的是m的最优解在[1, r]区间内,即本实施例的1-18的范围内,现实中可以针对不同云平台的DAG图,实验得到最佳的m值。
在本发明中,使用了二段式任务的处理方式,即同步云平台任务、入库任务的独立处理,分别将资源数据从云端拉入缓存,从缓存进入到数据库。二段式任务引入了缓存,这样的好处是,缓存被多次依赖的中间资源数据,防止重复的调用接口来获取同一份数据。在现有技术中,直接将云上的数据拉到数据库,各个消费者线程会重复拉取数据。而在本发明中,缓存是各个消费者线程共享的,其可以防止各个消费者线程重复调用接口以及防止重复处理获取到的接口数据。
进一步的,在我方的技术方案中,上文已经解释过,是存在多个消费者线程并发操作,采用并发的方式请求数据,以充分利用云计算***的并发处理能力从而提升运行效率。而使用Caffeine缓存组件缓存被多次依赖的中间资源数据,由于缓存是所有消费者程序共享的,消费者程序就不需要像现有技术中一样通过重复的调用云端的接口去获取同一份数据,进一步提升***使用效率。而本发明在同步云平台任务和入库任务这两个阶段都使用了DAG图算法,按顺序获取资源数据,合并相同资源数据请求,以较少对网络资源的占用。通过以上三个方面,综合实现效率的提升,尤其在大规模的云计算***的资源数据获取上,效果更好。
根据发明人的实践效果表明,在包含600+台主机、3000+台虚拟机、10000+个数据卷的云计算***上获取一次全量的资源数据,使用现有的方案的方法需要耗时4个小时,而使用本实施例中的方法时,所需要的时间可以减少到12分钟。
实施例2,在实施例1的基础上,增加了数据比对和批量操作的方式,该环节存在于步骤S05,资源入库步骤中。
由于资源入库往往是占用时间最长的一个步骤,本技术方案将数据持久化到Mariadb数据库,涉及数量众多的表格,为减少数据库的操作次数,数据入库操作支持批量操作。
云平台资源属性往往包含多个维度,数据同步包含创建和更新两块内容。
在本实施例中,每个资源都可以被分配一个唯一的标识,例如UUID。通过UUID的比对来区分创建或更新。
通过对比,如果资源在数据库中已存在,则对比资源的所有属性,判断资源是否有变化,有变化则需要更新同时还需要输出对应的变化日志。若资源是新增的,则先缓存一定数量的资源,达到一定数量的时候才会进行真正的入库操作,这个入库的阈值也是可变的,配置在数据库中,目前本实施例中使用的是100。
实施例3,在实施例2的基础上,还增加了数据删除操作。
删除的方法为:对比数据库现有资源和云平台同步到的资源,使用资源唯一的UUID来区分数据,若某一UUID在数据库现有资源中存在,在云平台同步到的资源中不存在,则判定为删除操作。
删除不存的资源,该步骤的优先级最高,删除不存在数据可以保证数据库的准确性,防止后续对资源进行***更新操作时产生异常。
至此,数据入库阶段为批量入库,减少数据库的链接次数。在提升效率的同时,还做到了完整的日志输出,记录了资源每一个属性的变化情况,每一个资源的增删情况等。