CN111061817A - 自适应业务构建系统、方法及计算机可读介质 - Google Patents

Abstract

本发明揭示了自适应业务构建系统、方法及其计算机可读介质，该自适应业务构建方法，以自机器提取的业务数据为输入，采用面向资源和/或业务的自然语言构建业务数据模型，对所述业务数据模型进行解析以确定其所包含的元模型，元模型由类模型、关系模型及属性模型组成；将元模型映射至数据层以构建存储模型，当业务数据发生变化时，新建或修改业务数据模型，以重新构建所述元模型。通过本发明，不仅实现了对云平台中各种资源的高效配置与管理，显著地降低了基于CMDB模型构建资源和/或组件的技术难度，满足了云平台中统一的校验逻辑和业务处理逻辑的需求，提高了CMDB模型的可扩展性，能够更好地适应复杂的业务数据模型。

Description

自适应业务构建系统、方法及计算机可读介质

技术领域

本发明涉及计算机资源配置管理技术领域，尤其涉及一种自适应业务构建系统、方法及其一种计算机可读介质。

背景技术

随着云计算技术的发展，传统的依靠人工对资源的配置管理已经变得无能为力。有基于此，面向资源的CMDB(配置管理系统)应运而生。CMDB通过识别、控制、维护，检查企业的IT资源，从而高效控制与管理不断变化的IT基础架构与IT服务，并为其它流程，例如事故管理、问题管理、变更管理、发布管理等流程提供准确的配置信息。

目前CMDB实现的平台资源及其关系的自动发现和自动化管理主要是基于简单网络管理协议(Simple Network Management Protocol，SNMP)的自动发现方式。然而，由于SNMP服务的轮询查询机制具有造成网络通信堵塞等风险，因此对网络安全环境要求严格的网段中的设备大多都关闭SNMP服务。基于SNMP协议的自动发现方式对于未开通SNMP服务的网络环境而言，就显得无能无力。

同时，申请人指出现有技术中基于CMDB对资源和/或服务的配置效果不甚理想。此种缺陷通常由于CMDB模型可扩展性较差、资源与模型之间不匹配、模型设计细腻度不够或者模型设计过粗等诸多原因所导致的。同时，现有的CMDB无法支持自然语言，从对运维人员资源和/或服务进行弹性配置提出了更高的技术要求，并由此导致基于CMDB模型构建资源和/或组件过程中存在一定难度。

有鉴于此，有必要对现有技术中的基于CMDB模型对云平台中的资源和/或服务进行配置与管理的技术予以改进，以解决上述问题。

发明内容

本发明的目的在于揭示一种自适应业务构建方法、系统及计算机可读介质，用以克服现有技术中基于CMDB模型对云平台中的资源和/或服务的合理配置，提高软件开发效率，降低软件开发成本与后期的维护成本。

为实现上述第一个目的，本发明提供了一种自适应业务构建方法，包括以下步骤：

S1、以自机器提取的业务数据为输入，采用面向资源和/或业务的自然语言构建业务数据模型，对所述业务数据模型进行解析以确定其所包含的元模型，所述元模型由类模型、关系模型及属性模型组成；

S2、将元模型映射至数据层以构建存储模型，当业务数据发生变化时，新建或修改业务数据模型，以重新构建所述元模型。

作为本发明的进一步改进，所述业务数据发生变化包括业务数据的修改或创建；

当业务数据发生变化并重新构建所述元模型之后还包括：通过重新构建的元模型将发生变化的业务数据对数据层中的存储模型执行更新操作。

作为本发明的进一步改进，所述步骤S1中自然语言为自机器的交互式界面中输入的用以描述业务数据的描述符，所述描述符由文字、符号或者语音文件中的一种或者几种的组合共同描述。

作为本发明的进一步改进，

所述类模型由以下字段组成：唯一标识字段、父类型标识字段、存储设备列表、存储字段名称以及业务描述字段；

所述关系模型由以下字段组成：唯一标识字段、源类型标识字段、目标类型标识字段、存储字段名称、关系类型字段以及业务描述字段；

所述属性模型由以下字段组成：唯一标识字段、类型定义字段、存储字段名称、类型字段、是否唯一字段、是否主键字段、是否必须字段、长度字段、属性值下界字段、属性值上限字段以及业务描述字段。

作为本发明的进一步改进，所述自然语言构建业务数据模型具体为：

以自然语言输入至最终软件库和/或最终硬件库中的描述符为输入，保存至配置管理数据库；

其中，所述配置管理数据库由业务层、模型服务层及数据层组成。

作为本发明的进一步改进，对所述业务数据模型进行解析具体为：

采用最终软件库和/或最终硬件库对所述业务数据模型进行序列化处理，以确定业务数据模型中所包含的类模型，并将基于业务数据模型所确定的类模型映射至元模型。

作为本发明的进一步改进，还包括：

将元模型保存至存储模型映射库的操作。

作为本发明的进一步改进，在将元模型保存至存储模型映射库之后还包括：

将保存至存储模型映射库中的元模型基于元模型分离出元信息与业务信息，并将所述元信息与业务信息分别保存至数据层所配置的元信息数据库与业务信息数据库。

作为本发明的进一步改进，业务数据发生变化为自机器提取的业务数据所发生的新建实例、删除实例、修改实例、迁移实例或者备份实例中的一种或者几种组成。

作为本发明的进一步改进，还包括：

记录自机器提取的业务数据所对应的业务数据模型以形成历史业务数据模型库的步骤，并将后续对自机器提取的业务数据所对应的业务数据模型与历史业务数据模型库中所留存的业务数据模型进行比对的步骤，

当业务数据模型不发生变化时，仅记录描述业务数据的描述符的值；

当业务数据模型发生变化时，遍历执行步骤S1与步骤S2。

基于相同发明思想，本申请还揭示了一种自适应业务构建系统，运行如上述任一项发明创造所揭示的自适应业务构建方法，

所述自适应业务构建系统包括：

业务层，模型服务层及数据层；

所述业务层包括自机器提取业务数据的业务模型设计单元，

所述模型服务层采用面向资源和/或业务的自然语言构建业务数据模型，对所述业务数据模型进行解析以确定其所包含的元模型，所述元模型由类模型、关系模型及属性模型组成；

所述数据层接收并构建由元模型映射形成的存储模型，当业务数据发生变化时，新建或修改业务数据模型，以重新构建所述元模型。

作为本发明的进一步改进，所述业务数据发生变化包括业务数据的修改或创建；

当业务数据发生变化并重新构建所述元模型之后还包括：通过重新构建的元模型将发生变化的业务数据对数据层中的存储模型执行更新操作。

作为本发明的进一步改进，所述模型服务层配置对业务数据模型进行解析的模型解析模块，对构成元模型进行解析以形成类模型的类模型建模模块，对构成元模型进行解析以形成属性模型的关系模型建模模块，对构成元模型进行解析以形成属性模型的属性模型建模模块，以及，执行将元模型保存至存储模型映射库的操作的存储模型映射库。

作为本发明的进一步改进，所述业务层还包括业务数据操作库；

所述业务数据操作库记录自机器提取的业务数据所对应的业务数据模型以形成历史业务数据模型库，并将后续对自机器提取的业务数据所对应的业务数据模型与历史业务数据模型库中所留存的业务数据模型进行比对，以确定是否触发采用面向资源和/或业务的自然语言构建业务数据模型的事件。

作为本发明的进一步改进，所述数据层包括元信息数据库与业务信息数据库；其中，

所述元信息数据库保存基于元模型分离出的元信息；

所述业务信息数据库保存基于元模型分离出的业务信息。

最后，本申请还揭示了一种计算机可读介质，所述计算机可读介质中存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行如上述任一项发明创造所揭示的自适应业务构建方法中的步骤。

与现有技术相比，本发明的有益效果如下：

首先，由于采用面向资源和/或业务的自然语言构建业务数据模型，能够便于用户和/或管理员能够更加简便的修改、升级或者创建CMDB模型，实现了对云平台中各种资源的高效配置与管理，尤其能够降低用户和/或管理员的技术要求，显著地降低了基于CMDB模型构建资源和/或组件的技术难度；

其次，在本发明中当当业务数据发生变化时，可通过既有的元模型将类模型、关系模型与属性模型之间所具有的关联关系，对重新构建的元模型将发生变化的业务数据对数据层中的存储模型执行更新操作，由于整个关联及更新操作过程位于数据层中发生，不仅支持全局的基于CMDB模型对资源和/或组件的升级配置需求，且对用户无感知，显著地提高了用户体验，且对云平台中的其他和/或组件不会造成干扰，满足了云平台中统一的校验逻辑和业务处理逻辑的需求，提高了CMDB模型的可扩展性，能够更好地适应复杂的业务数据模型；

最后，本申请所揭示的自适应业务构建方法及自适应业务构建系统，使得在云平台中CMDB模型构建资源和/或组件具有统一的模型规范，从而有效地避免了云平台中基于CMDB模型构建资源和/或组件由于元模型在最初设计时缺乏足够的细粒度或者细粒度过大，而导致的无法适应实际场景中的业务数据模型或者管理业务数据模型过于复杂等诸多缺陷。

附图说明

图1为本发明一种自适应业务构建方法的整体流程图；

图2为本发明一种自适应业务构建方法中所涉及的元模型的数据结构示意图；

图3为图2所揭示的元模型中所包含的类模型的数据结构示意图；

图4为图2所揭示的元模型中所包含的关系模型的数据结构示意图；

图5为图2所揭示的元模型中所包含的属性模型的数据结构示意图；

图6为关系类型字段为1的实例中以标识一对一关系模型的数据结构示意图；

图7为关系类型字段为2的实例中以标识多对多关系模型的数据结构示意图；

图8为在数据层中所构建出的存储模型的实例；

图9为运行本发明一种自适应业务构建方法的一种自适应业务构建系统的拓扑图；

图10为本发明所揭示的一种计算机可读介质的拓扑图。

具体实施方式

下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。

在详细阐述本发明各个实施例之前，对本发明的核心发明思想予以概述，并通过下述若干实施例予以详细阐述。

本发明基于CMDB对云平台或者配置运行用于响应用户发起的访问请求的服务的数据中心等场景中，对资源和/或服务进行配置，从而高效地控制与管理不断变化的IT基础架构与IT服务。本发明通过自然语言构建业务数据模型，当业务数据模型发生变化时，基于之前已经建立的元模型中相互关联的类模型、关系模型与属性模型，对CMDB模型构建的资源和/或组件进行平滑升级为维护，以支持全局业务模型的自适应建模需求。

在本申请中，术语“资源”与术语“服务”可独立包含向用户(User)发起的访问请求所配置的一种或者几种服务能力，包括但不限于数据、物理资源、虚拟资源、APP、下载地址、音频文件、视频文件、存储资源、操作系统等。

本申请中，术语“机器”包括但不限于能够用于键入指令的计算机、具有GUI(图形用户界面)的计算机、集群服务器、云计算平台(或简称“云平台”)、分布式计算系统或者数据中心等，其中，云平台可为公有云、私有云或者混合云。

在本申请中，术语“业务数据”包括但不限于用户对云平台下方的配置数据(例如创建云主机等请求)、云主机迁移请求、合同、虚拟资源的型号、id、版本号、物理设备的供应商名称等。

在本申请中，术语“业务数据模型”是指包含前述至少一种或者几种“业务数据”相互组合，以向用户和/或管理员作出响应，并具有内在逻辑的实例，通常表现为具有特定功能的软件和/或硬件及其组合所形成的一种资源或者服务，甚至还可以是一种应用。

申请人通过下文示出若干实施例，以对本发明所含具体技术方案予以详细阐述。

实施例一：

参图1至图8所示，本实施例揭示了一种自适应业务构建方法(以下简称“方法”)的一种具体实施方式。

在本实施例中，申请人以该方法对云计算平台(简称“云平台”)中基于CMDB架构对业务数据进行自适应配置的具体实现过程予以范例性阐述，本领域技术人员可以合理预测到，该方法所涵盖的技术方案还可合理地应用至配置有云计算服务或者大数据服务的数据中心(IDC)或者分布式计算集群等其他场景中。

在本实施例所揭示的方法包括以下步骤：

步骤S1、以自机器提取的业务数据为输入，采用面向资源和/或业务的自然语言构建业务数据模型，对所述业务数据模型进行解析以确定其所包含的元模型10。元模型10由类模型(Type Model)100、关系模型(RelationModel)200及属性模型(Definition Model)300组成，且类模型100与关系模型200及属性模型300相互关联，并作为一个整体从而共同描述该元模型10。需要说明的是，在实施例中，用户和/或管理员可以本地或者远程等方式登录云平台，以对构成某种应用的资源或者设置予以配置。此种操作通常会基于业务数据的变化而导致业务数据模型模型发生变化，由此间接导致元模型10的变化。

具体而言，该步骤S1中自然语言为自机器的交互式界面中输入的用以描述业务数据的描述符；具体而言，描述业务数据的描述符由文字、符号或者语音文件中的一种或者几种的组合共同描述，例如，文字可为中文、英文、日文或者其他能够被人或者机器知悉其含义的字符。符号可被理解为被现有计算机系统或者编程软件采用，并能够形成描述资源和/或服务发生变化实例的各种可识别字符，例如“～”、“(”、“$”、“{”、“}”等。语音文件可被理解为通过语音采集设备(例如麦克风)通过语音识别软件或者语音识别系统或者机器自身内置的具有语音识别软件或者语音识别系统功能的程序，以转化为可被机器所识别并执行的可识别字符。

在本实施例中，所谓的业务数据发生变化包括业务数据的修改或创建。同时，当业务数据发生变化并重新构建之前已经建立的元模型10之后还包括：通过重新构建的元模型10，并将发生变化的业务数据对数据层40中的存储模型执行更新操作。更新后元模型10重新通过存储模型映射库35保存至数据层40中，并进一步具体为基于元模型分离出元信息与业务信息，并将所述元信息与业务信息分别保存至数据层40所配置的元信息数据库41与业务信息数据库集42中的指定的业务信息数据库(如业务信息数据库421)。数据层40中保存的各个状态的元信息与业务信息，并可被业务数据操作库22所调用，并最终被业务模型设计单元21所调用，以为后续基于业务数据发生变化所导致的对业务数据模型的解析操作提供模板，从而避免了整个CMDB由于业务数据的不固定所导致的需要重复解析并封装出不同元模型10的操作难度。因此，通过上述技术方案，不仅简化了元模型10的设计难度，还提高了元模型10对不同业务数据的适应性，极大地提高了元模型10的可扩展性。

参图2所示，本实施例中所揭示的类模型100由以下字段组成：唯一标识字段(即id)、父类型标识字段(即base_type_id)，存储设备列表(即name)、存储字段名称(即s_name)以及业务描述字段(即description)。类模型100的作用主要为将基于自然语言为自机器的交互式界面中输入的用以描述业务数据的描述符所刻画的业务数据模型映射至如图8所示出的存储模型中。

具体而言，类模型100所含的唯一标识字段(即id)通常为CMDB自增id主键，用来唯一标识一个类模型100。类模型100所含的父类型标识字段(即base_type_id)用以描述数据关系表的属性，其中，base_type_id取值为0时，则表示该数据关系表为主表；base_type_id取值大于0时，则表示该数据关系表为隶属于其他数据关系的字表。类模型100所含的存储设备列表(即name)用以标识业务数据模型的名称。类模型100所含的存储字段名称(即s_name)用以标识业务数据模型在存储模型中的刻画，通常以字母t为开头，并加上阿拉伯数字，例如，t1、t2，用以区分两个不同的类模型100。类模型100所含的业务描述字段(即description)，用以描述该类模型100的作用及业务数据的含义。

参图3所示，本实施例所揭示的关系模型200由以下字段组成：唯一标识字段(即id)、源类型标识字段(即source_type_id)、目标类型标识字段(即target_type_id)、存储字段名称(即name)、关系类型字段(即type)以及业务描述字段(即description)。关系模型200主要用于描述逻辑上位于同一个CMDB中的多个类模型100之间所存在的一对一的映射关系和一对多的映射关系，由此可通过该关系模型200将一个或者多个类模型100进行关联，并在后续的通过自然语言刻画的业务数据对业务数据模型进行创建或者修改时，能够对整个元模型10进行平滑的新建、修改或者升级。

具体而言，关系模型200所含的唯一标识字段(即id)，用来唯一标识一个关系模型200。关系模型200所含的源类型标识字段(即source_type_id)，用以标识主表的唯一标识符，通常为主表的主键id字段，用以标识左关系表(参7所示)。关系模型200所含的目标类型标识字段(即target_type_id)，用以标识子表的唯一标识符，通常为子表的主键id字段，用以标识右关系表(参7所示)。关系模型200所含的存储字段名称(即name)，用以通过自然语言描述主表与子表之间的关系，通常可以“主表名称”+“—”+“子表名称”的逻辑予以描述。例如，“存储—磁盘”，其中，“存储”即主表名称，“磁盘”即子表名称，并以“存储—磁盘”作为识别指定磁盘是存储所包含的一个子类型。关系模型200所含的关系类型字段(即type)，用以标识关系模型之间的关系类型；关系类型字段默认字段为0，表示为一对一的映射关系；关系类型字段为1时，表示为一对多的映射关系(参图6所示)；关系类型字段为2时，表示为多对多的映射关系(参图7所示)。关系模型200所含的业务描述字段(即description)，用以描述主表与子表之间的关联逻辑。

尤其需要说明的是，在本实施例中，主表和子表都是用于描述业务模型的二维关系表；用于表述业务的某一特定分类或子集。其中存在主键的表可以称之为主表，当表中(例如表B)存在外键，并关联了另一张表(例如表A)的主键,则可以称表B示表A的一张子表。因为主表和子表都是用于描述业务模型的属性的二维表，所以并不是某张表只能是主表或者子表，一张表存在主键则可以称之为所表示的这个业务类的主表，当其存在外键，则也可以称其为外键关联的另一张表的子表。

在实际业务模型描述中一般将用于描述业务主体的表称之为主表，因为实际业务模型会比较复杂，用一张无法完全描述业务模型，或用一张表描述全部业务从存储空间，插入更新及查询等特征的性能和空间需求下，会将业务主体之外的用子表进行描述，由此存在主表子表之说。通常一个复杂的业务模型在转换成存储模型设计时，考虑要满足存储空间，更新检索等时间空间性能需求上，将业务模型转换成多张主表和子表进行关联进行描述是较为合理有效的做法。而将业务模型通过多张主表和子表进行关联进行描述后，因业务数据的特性不同，主表和子表之间的关联关系也不同，由此存在一对一的映射关系(如一个账号配一个密码)，一对多的映射关系(如一个老师教多个学生)，多对多关联的关系(如一个老师可以有多个学生，一个学生也可以有多个老师)，为了便于梳理和更好的描述这种关联关系，通常需要关联表进行描述，参图6与图7所示。

在图6中，可通过主表与子表及属性模型300进行关联，以在一对一的映射关系时，以通过主表中的id主键关联子表中的id主键，从而找到子表中对应的字段。

同理所述，在图7中，通过关系模型200将主表和子表进行关联，关系模型200可以更清楚的表示主表和子表的关联关系。当主表或子表中不能通过唯一字段(即id主键)来唯一标识某一个字段(例如base_type_id)时，存在需要多个字段唯一组合标识一个字段时，使用关系模型200作为关联表，则能够快速地关联至子表(备注：该子表实质上属于类模型100)与主表(备注：该主表实质上属于类模型100)。需要说明的是，在图7中，主表与子表的类型相同，且均是基于业务数据输入至业务层20后所对应的业务数据模型。

在本实施例中，通过多张主表、子表及关联表，可以有效的描述并存储某个特定领域的业务模型及其自机器通过自然语言刻画的业务数据。尤其的，在本实施例中，不需要事先知道具体的业务模型，并为其提前建立好主表、子表和关联表。因此，当业务需求变更时，可实现即时且平滑的升级操作。同时，由于在本实施例中，多个业务模型不需要提前建立多套主表、子表和关联表，因此使得基于之前所配置的元模型10对后续业务模型具有更好的适应性。

在本实施例中，将业务模型中的属性独立成一张属性表，通过类模型100，关系模型200和属性模型300可以对多业务模型基于CMDB进行建模。同时本发明的再次将这四种模型提炼为元模型，使得其可以自适应建模，而无需事先了解业务模型的前提下为其事先建模，通过本发明提炼的元模型可以自适应通用建模，从而在业务多态，变化频繁等常见下可以快速自适应建模和平滑升级。

需要说明的是，本实施例所指平滑升级是指新增的或者修订的业务数据模型对已经存在的业务数据模型以及基于之前已经存储在数据层40中的元信息及业务信息互不影响，且后续新增的业务数据及业务数据模型可以直接存储至数据层40中。

在通用性方面本发明另一技术优势在于支持用户使用自然语言建模。如用户熟悉中文方式的自然语言刻画方式，则可以用中文描述其业务模型。通过本发明的元模型10解析映射到位于底层的数据层40中的存储模型是符合其业务模型的存储模型，而在用户层则依然展示的是用户熟悉的中文描述的业务模型，用户可以方便的用中文对其业务模型及业务数据进行描述和检索更新，并由数据层40向用户予以响应。当用户熟悉自然语言为英文的场景时，也可以用英文去描述其业务模型，并通过本发明转换映射后得到的是其所熟悉的自然语言可检索更新的业务模型，而底层存储模型是通过元模型10转换的符合数据库规范的存储模型。

参图4所示，本实施例中所揭示的属性模型300由以下字段组成：唯一标识字段(即id)、类型定义字段(即type_def_id)、存储字段名称(即name)、类型字段(即type)、是否唯一字段(即is_unique)、是否主键字段(即is_key)、是否必须字段(即required)、长度字段(即length)、属性值下界字段(即value_min)、属性值上限字段(即valve_max)以及业务描述字段(即description)。属性模型300用以对类模型100所具有的多个属性列表的刻画，以快速地适应业务数据的迭代变化，并支持修订业务模式平滑地同步修订CMDB模型。

具体而言，属性模型300所含的唯一标识字段(即id)，通常为CMDB自增id主键，用来唯一标识一个属性模型300。属性模型300所含的类型定义字段(即type_def_id)，通常为隶属于该属性模型的主键id字段，用于标识该类型定义字段所属的属性模型300。属性模型300所含的存储字段名称(即name)，用于标识业务数据的名称，并具体为用户自机器端所输入的业务数据所属的业务数据字段。属性模型300所含的类型字段(即type)，用以描述用户使用自然语言刻画的业务属性字段，并具体包括如下一种或者几种字段类型：STRING字段，BOOL字段，DOUBLE字段，DATETIME字段，UINT8字段，UINT16字段，UINT32字段，UINT64字段，INT8字段，INT16字段，INT32字段或者INT64字段等字段类型。属性模型300所含的是否唯一字段(即is_unique)，并具体为布尔型数据，用以标识该属性字段是否为唯一，若设置为true，则生成唯一的索引；若设置为false，则不生成唯一的索引。在本实施例中，否唯一字段(即is_unique)的默认设置为false。属性模型300所含的是否主键字段(即is_key)，并具体为布尔型数据，用以标识该识别字段是否为主键，若多个字段均设置为true时，则表示为联合主键。属性模型300所含的是否必须字段(即required)，并具体为布尔型数据，用以标识该字段是否可以为空；若设置为true，则表示该字段必须填写具体的键值；若设置为false，则表示该字段不强制填写具体的键值。在本实施例中，是否必须字段(即required)的默认设置为false。属性模型300所含的长度字段(即length)，用以描述该属性字段的数据类型长度。

在本实施例中，长度字段(即length)的默认设置为零长度。属性模型300所含的属性值下界字段(即value_min)，用以描述该属性字段的最小值应大于设置的下限，在本实施例中，属性值下界字段的默认设置为无。属性模型300所含的属性值上限字段(即valve_max)，用以描述该属性字段的最大值应大于设置的上限，在本实施例中，属性值上界字段的默认设置为无。

需要说明的是，在本实施例中，若用户没有填写属性值下界字段(即value_min)和属性值上限字段(即valve_max)，或者均为“无”时，元模型10在转换到存储模型时，将取这个属性字段的数据类型的上下界为和value_max和value_min的值，自动为用户填充。当用户实际键入或者导入的业务数据录入超过上界(value_max)或下界(value_min)后，将会提示数据大小不符合业务正常数据范畴并且位于底层的数据层40中不保存该条业务数据，以防止用户实际键入或者导入的业务数据无法满足业务数据模型构建事件的发生。

通过上述技术方案，不仅满足了CMDB对业务数据的容错性与兼容性的需求，使得基于CMDB的自适应业务构建系统/方法在调整资源或者对象的过程中，还保证了业务数据的健壮性、可扩展性与可维护性。属性模型300所含的业务描述字段(即description)，用以描述属性字段的业务逻辑，并通过该业务逻辑对图8所示出的存储模型予以描述。

在本实施例中，步骤S1中对所述业务数据模型进行解析具体为：

采用最终软件库和/或最终硬件库对所述业务数据模型进行序列化处理，以确定业务数据模型中所包含的类模型100，并将基于业务数据模型所确定的类模型100映射至元模型10。同时，在本实施例中，该自然语言构建业务数据模型具体为：以自然语言输入至最终软件库(DSL)和/或最终硬件库(DHS)中的描述符为输入，保存至配置管理数据库；其中，所述配置管理数据库由业务层20、模型服务层30及数据层40组成(具体参图9所示)。

具体而言，对所述业务数据模型进行序列化处理的操作对应图9中业务层20中的业务模型设计单元21指向模型服务层30中的模型解析单元31所示出箭头的过程。最终软件库(Definitive Software Library，DSL)，其记录了运行该CMDB的云平台或者数据中心中所有经过授权与测试的软件信息。同时，最终硬件库(Definitive Hardware Library，DHS)中包含了硬件的备件和库存。这些备用组件和配件得到与它们在实际运作环境中的对应组件相同级别的维护。最终硬件库(DHS)中的硬件可用来替换或修复IT基础架构中相似的配置。有关这些配置构成的详细信息应该被记录在CMDB中。在本实施例中，通过对业务数据模型进行序列化处理的操作，从而确保业务数据发生新建或者修改事件时，能够将业务数据关联至当前状态中的元模型10中，从而确保整个CMDB系统的实时性、稳定性及可靠性。

然后，执行步骤S2、将元模型10映射至数据层40以构建存储模型，当业务数据发生变化时，新建或修改业务数据模型，以重新构建所述元模型10。

在本实施例所示出的场景中，业务数据发生变化，直接导致业务数据模型发生变化，并最终导致元模型10发生变化，但从本质上而言，在CMDB配置之初，只要设置数量极少的元模型10即可满足后续的因业务数据发生变化所导致的元模型10的自适应修改，从而完成对IT资源或者服务的自动升级配置。

同时，在重新构建该元模型10的过程中，重新自动构建该元模型10，并通过重建后元模型10将业务数据模型关联更新其对应的底层数据存储模型。由于整个关联更新过程是支持自动平滑升级更新的，对业务数据和/或用户无感知。其中，本实施例所指的“业务数据 发生变化”为自机器提取的业务数据所发生的新建实例、删除实例、修改实例、迁移实例或者备份实例中的一种或者几种组成。

结合图9所示，该方法还包括：将元模型10保存至存储模型映射库35的操作。优选的，在将元模型10保存至存储模型映射库35之后还包括：将保存至存储模型映射库35中的元模型10基于元模型分离出元信息与业务信息，并将所述元信息与业务信息分别保存至数据层40所配置的元信息数据库41与业务信息数据库集42中的指定的业务信息数据库(如业务信息数据库421)。结合图9所示，独立地分别存储元信息与业务信息的好处在于，使得通过该CMDB对云平台中的资源和/或服务进行创建、修改、升级操作事件所对应的资源/服务发生变化时所对应的业务数据模型能够实现自适应的扩展修订并保存修订记录。

用户和/或管理员能够通过访问数据层40中的元信息数据库41快速索引至对应的某个业务信息数据库(例如业务信息数据库421)，以封装出当前状态的元模型10，并进一步确定元模型10中相互关联的类模型100、关系模型200及属性模型300。

元数据信息库41用于记录业务数据模型的建模属性和元数据，当创建、更新、读取、删除业务数据时，需要在元数据信息库41中先根据之前记录的对应的业务数据模型所对应的元模型10解析出其映射在底层数据库存储端的业务信息数据库(例如业务信息数据库421)的位置和业务信息数据库421中的表关联关系，然后再执行对应的创建、更新、读取及删除操作。

元数据信息库41是用来记录业务数据模型与数据层40中业务数据信息库集42中指定的业务数据信息库(例如业务数据信息库421)之间的关联关系，以及映射的属性字段对应关系(例如业务字段定义为“姓名”)映射到业务信息数据库中的表示字段即为“name”。业务信息数据库集42中所包含的多个业务信息数据库用于保存对应的业务数据模型以及业务数据模型中用户和/或管理员所实际定义或者键入的数据/键值。

在本实施例中，该自适应业务构建方法还包括：记录自机器提取的业务数据所对应的业务数据模型以形成历史业务数据模型库的步骤，并将后续对自机器提取的业务数据所对应的业务数据模型与历史业务数据模型库中所留存的业务数据模型进行比对的步骤。

当业务数据模型不发生变化时，仅记录描述业务数据的描述符的值，例如：仅变更某个磁盘的购买时间，那么于此场景中，“购买时间”就是作为业务数据的“磁盘”的描述符的值；当业务数据模型发生变化时，遍历执行前述步骤S1与步骤S2，从而完成对整个CMDB模型的自适应且平滑的升级。

实施例二：

结合实施例一所揭示的一种自适应业务构建方法，本实施例揭示了一种自适应业务构建系统(以下简称“系统”)的一种具体实施方式。本实施例所揭示的系统运行于云平台的CMDB中，而CMDB被配置并运行于云平台的分布式存储后端。同时，在云平台中使用golang编译环境。

结合图9所示，在本实施例中，该系统运行如实施例一所揭示的所述的自适应业务构建方法。具体而言，本实施例所揭示的系统包括：业务层20，模型服务层30及数据层40，并且在云平台的拓扑架构上，上述业务层20，模型服务层30及数据层40自上而下进行部署。例如，数据层40在基于OpenStack架构的云平台中部署于基础架构层中。

结合图9所示，在本实施例中，业务层20包括自机器提取业务数据的业务模型设计单元21，并最优先为配置业务数据操作库22。业务模型设计单元21以描述业务数据的描述符作为输入，以创建、修改或者升级业务数据，并解析出业务数据模型。

模型服务层30采用面向资源和/或业务的自然语言构建业务数据模型，对所述业务数据模型进行解析以确定其所包含的元模型10，所述元模型10由类模型100、关系模型200及属性模型300组成。

其中，面向资源和/或业务的含义是：该自适应业务构建系统接收用户和/或管理员所输入的自然语言，对整个云平台中所包含的各种资源(例如虚拟资源、网络资源、虚拟计算资源、内网网段、物理资源等)和/或各种业务(例如创建虚拟机的请求、迁移虚拟机的请求、杀死虚拟机的请求、增加虚拟机配置的请求、API设置、业务关联、在线支付等)，以为实际生产环境或者消费环境中的服务和资源组件数据予以维护，为其他运维管理系统提供基础数据。

模型服务层30配置对业务数据模型进行解析的模型解析模块31，对构成元模型进行解析以形成类模型的类模型建模模块32，对构成元模型进行解析以形成属性模型的关系模型建模模块33，对构成元模型进行解析以形成属性模型的属性模型建模模块34，以及，执行将元模型保存至存储模型映射库的操作的存储模型映射库35。类模型建模模块32与关系模型建模模块33及属性模型建模模块34共同构建出元模型10，并且能够根据后续的因业务数据发生变化所导致的元模型10所发生的变化，对既有的元模型10进行修改或者升级，以生成与当前状态的业务数据模型所适配的元模型10。

数据层40接收并构建由元模型映射形成的存储模型，当业务数据发生变化时，新建或修改业务数据模型，以重新构建所述元模型10。

尤其的，本实施例中所指“业务数据发生变化”包括业务数据的修改或创建，并进一步包括基于用户和/或管理员所执行的以下事件之一或者几种的事件的集合：(1)修改既有业务数据事件；(2)创建新的业务数据事件；(3)同时创建或者修改业务数据事件。

当业务数据发生变化并重新构建所述元模型10之后还包括：通过重新构建的元模型将发生变化的业务数据对数据层40中的存储模型执行更新操作。

更新后元模型10重新通过存储模型映射库35保存至数据层40中，并进一步具体为基于元模型分离出元信息与业务信息，并将所述元信息与业务信息分别保存至数据层40所配置的元信息数据库41与业务信息数据库集42中的指定的业务信息数据库(如业务信息数据库421)。数据层40中保存的各个状态的元信息与业务信息，并可被业务数据操作库22所调用，并最终被业务模型设计单元21所调用，以为后续基于业务数据发生变化所导致的对业务数据模型的解析操作提供模板，从而避免了整个CMDB由于业务数据的不固定所导致的需要重复解析并封装出不同元模型10的操作难度。因此，通过上述技术方案，不仅简化了元模型10的设计难度，还提高了元模型10对不同业务数据的适应性，极大地提高了元模型10的可扩展性。

业务数据操作库记22录自机器提取的业务数据所对应的业务数据模型以形成历史业务数据模型库，并将后续对自机器提取的业务数据所对应的业务数据模型与历史业务数据模型库中所留存的业务数据模型进行比对，以确定是否触发采用面向资源和/或业务的自然语言构建业务数据模型的事件。

数据层40包括元信息数据库41与业务信息数据库集42。具体而言，业务信息数据库集42由业务信息数据库421至业务信息数据库42n组成，其中，参数“n”取大于或者等于2的正整数。业务信息数据库集42中所包含的每一个业务信息数据库保存基于元模型10分离出的业务信息，元信息数据库41保存基于元模型分离出的元信息。业务信息数据库保存基于元模型分离出的业务信息，该分离出的业务信息与元模型10中所包含的当前状态中的元信息相关联。通过上述技术方案，使得通过该系统对云平台中的资源和/或服务进行创建、修改、升级操作事件所对应的资源/服务发生变化时所对应的业务数据模型能够实现自适应的扩展修订并保存修订记录。用户和/或管理员能够通过访问数据层40中的元信息数据库41快速索引至对应的某个业务信息数据库，以封装出当前状态的元模型10，并进一步确定元模型10中相互关联的类模型100、关系模型200及属性模型300。

通过本实施例所揭示的系统，不仅实现了对云平台中各种资源的高效配置与管理，显著地降低了基于CMDB模型构建资源和/或组件的技术难度，满足了云平台中统一的校验逻辑和业务处理逻辑的需求，提高了CMDB模型的可扩展性，能够更好地适应复杂的业务数据模型。

本实施例所揭示的一种自适应业务构建系统与实施例一所揭示的一种自适应业务构建方法中相同部分的技术方案，请参实施例一所述，在此不再赘述。

实施例三：

结合图10所示，本实施例揭示了一种计算机可读介质700的一种具体实施方式。该计算机可读介质700可整体或者部分配置于物理形态的计算机、服务器、集群服务器或者数据中心中。

在本实施例中，一种计算机可读介质700，该计算机可读介质700中存储有计算机程序指令701，计算机程序指令701被一处理器读702读取并运行时，执行如实施例一所揭示的自适应业务构建方法中的步骤。

可选地，计算机可读介质700可配置为服务器，且该服务器运行于构建私有云、混合云或者公有云的物理设备上。同时，该计算机可读介质700还可被配置为随机存取存储器(Random Access Memory，RAM)，只读存储器(Read Only Memory，ROM)，可编程只读存储器(Programmable Read-Only Memory，PROM)，可擦除只读存储器(Erasable ProgrammableRead-Only Memory，EPROM)，电可擦除只读存储器(Electric Erasable ProgrammableRead-Only Memory，EEPROM)等。

该计算机可读介质700用于存储程序，所述处理器702在接收到执行指令后，以执行实施例一所揭示的自适应业务构建方法。

同时，本实施例所揭示的处理器702可能是一种集成电路芯片，具有信号的处理能力。该处理器702可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital SignalProcessor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规处理器。

本实施例所揭示的一种计算机可读介质中与实施例一和/或实施例二中相同部分的技术方案，请参实施例一和/或实施例二所述，在此不再赘述。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

Claims (16)

1.一种自适应业务构建方法，其特征在于，包括以下步骤：

S1、以自机器提取的业务数据为输入，采用面向资源和/或业务的自然语言构建业务数据模型，对所述业务数据模型进行解析以确定其所包含的元模型，所述元模型由类模型、关系模型及属性模型组成；

S2、将元模型映射至数据层以构建存储模型，当业务数据发生变化时，新建或修改业务数据模型，以重新构建所述元模型。

2.根据权利要求1所述的自适应业务构建方法，其特征在于，所述业务数据发生变化包括业务数据的修改或创建；

当业务数据发生变化并重新构建所述元模型之后还包括：通过重新构建的元模型将发生变化的业务数据对数据层中的存储模型执行更新操作。

3.根据权利要求1所述的自适应业务构建方法，其特征在于，所述步骤S1中自然语言为自机器的交互式界面中输入的用以描述业务数据的描述符，所述描述符由文字、符号或者语音文件中的一种或者几种的组合共同描述。

4.根据权利要求1所述的自适应业务构建方法，其特征在于，

所述类模型由以下字段组成：唯一标识字段、父类型标识字段、存储设备列表、存储字段名称以及业务描述字段；

所述关系模型由以下字段组成：唯一标识字段、源类型标识字段、目标类型标识字段、存储字段名称、关系类型字段以及业务描述字段；

所述属性模型由以下字段组成：唯一标识字段、类型定义字段、存储字段名称、类型字段、是否唯一字段、是否主键字段、是否必须字段、长度字段、属性值下界字段、属性值上限字段以及业务描述字段。

5.根据权利要求4所述的自适应业务构建方法，其特征在于，所述自然语言构建业务数据模型具体为：

以自然语言输入至最终软件库和/或最终硬件库中的描述符为输入，保存至配置管理数据库；

其中，所述配置管理数据库由业务层、模型服务层及数据层组成。

6.根据权利要求5所述的自适应业务构建方法，其特征在于，对所述业务数据模型进行解析具体为：

采用最终软件库和/或最终硬件库对所述业务数据模型进行序列化处理，以确定业务数据模型中所包含的类模型，并将基于业务数据模型所确定的类模型映射至元模型。

7.根据权利要求6所述的自适应业务构建方法，其特征在于，还包括：

将元模型保存至存储模型映射库的操作。

8.根据权利要求7所述的自适应业务构建方法，其特征在于，在将元模型保存至存储模型映射库之后还包括：

将保存至存储模型映射库中的元模型基于元模型分离出元信息与业务信息，并将所述元信息与业务信息分别保存至数据层所配置的元信息数据库与业务信息数据库。

9.根据权利要求5所述的自适应业务构建方法，其特征在于，业务数据发生变化为自机器提取的业务数据所发生的新建实例、删除实例、修改实例、迁移实例或者备份实例中的一种或者几种组成。

10.根据权利要求5至9中任一项所述的自适应业务构建方法，其特征在于，还包括：

记录自机器提取的业务数据所对应的业务数据模型以形成历史业务数据模型库的步骤，并将后续对自机器提取的业务数据所对应的业务数据模型与历史业务数据模型库中所留存的业务数据模型进行比对的步骤，

当业务数据模型不发生变化时，仅记录描述业务数据的描述符的值；

当业务数据模型发生变化时，遍历执行步骤S1与步骤S2。

11.一种自适应业务构建系统，运行如权利要求1至10中任一项所述的自适应业务构建方法，其特征在于，

所述自适应业务构建系统包括：

业务层，模型服务层及数据层；

所述业务层包括自机器提取业务数据的业务模型设计单元，

所述模型服务层采用面向资源和/或业务的自然语言构建业务数据模型，对所述业务数据模型进行解析以确定其所包含的元模型，所述元模型由类模型、关系模型及属性模型组成；

所述数据层接收并构建由元模型映射形成的存储模型，当业务数据发生变化时，新建或修改业务数据模型，以重新构建所述元模型。

12.根据权利要求11所述的自适应业务构建系统，其特征在于，所述业务数据发生变化包括业务数据的修改或创建；

当业务数据发生变化并重新构建所述元模型之后还包括：通过重新构建的元模型将发生变化的业务数据对数据层中的存储模型执行更新操作。

13.根据权利要求11所述的自适应业务构建系统，所述模型服务层配置对业务数据模型进行解析的模型解析模块，对构成元模型进行解析以形成类模型的类模型建模模块，对构成元模型进行解析以形成属性模型的关系模型建模模块，对构成元模型进行解析以形成属性模型的属性模型建模模块，以及，执行将元模型保存至存储模型映射库的操作的存储模型映射库。

14.根据权利要求11所述的自适应业务构建系统，其特征在于，所述业务层还包括业务数据操作库；

所述业务数据操作库记录自机器提取的业务数据所对应的业务数据模型以形成历史业务数据模型库，并将后续对自机器提取的业务数据所对应的业务数据模型与历史业务数据模型库中所留存的业务数据模型进行比对，以确定是否触发采用面向资源和/或业务的自然语言构建业务数据模型的事件。

15.根据权利要求11所述的自适应业务构建系统，其特征在于，所述数据层包括元信息数据库与业务信息数据库；其中，

所述元信息数据库保存基于元模型分离出的元信息；

所述业务信息数据库保存基于元模型分离出的业务信息。

16.一种计算机可读介质，其特征在于，所述计算机可读介质中存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行如权利要求1-10中任一项所述自适应业务构建方法中的步骤。

Images