一种生成配置逆向文本化的方法及装置与流程

本发明涉及网络通信技术领域，尤其涉及一种生成配置逆向文本化的方法及装置。

背景技术：

为了方便用户直观查看网络设备的当前运行状态，网络设备提供将当前生效的配置逆向转化为用户可以直观看到的文本的功能(即配置逆向文本化功能)，这个功能可以称为buildrun。

目前网络设备上的很多功能都依赖于buildrun，例如：

1、配置差异记录：需要对比每一次操作后buildrun的配置变化并上报给监控中心。

2、生成配置快照，供用户回滚等。

buildrun依赖的数据组织分为两大类：模板和普通的命令。buildrun通过特定的符号(如“#”)区分段落，通过缩进表示配置的层次关系。buildrun内部的组织以模板根节点(英文：root)作为整个buildrun的根节点，下面根据优先级排列着插件注册的回调或者子模板的信息。优先级用来控制buildrun内容的生成顺序，保证对于同样的运行配置buildrun的结果是一样的。

builrun生成的时候，从模板root开始，根据优先级，依次调用回调(英文：callback)。使用深度优先的方式，调用各个插件(英文：plugin)注册的回调，各个plugin的回调从系统中(一般是内存数据库(英文：databaseinmemory，简称dbm))获取运行数据，根据自身的逻辑生成文本信息输出。

目前，buildrun的生成流程如下：用户/其他应用程序发送buildrun请求给主dbm；主dbm收到请求后，派生(英文：fork)出一个dbm的拷贝，调用上述的buildrun生成流程进行结果返回给用户。

其中，使用fork是为了不影响主dbm，使得主dbm可以继续处理db的获取/设置(英文get/set)请求。dbm的拷贝在buildrun生成时访问数据库，访问的为本进程内数据库的拷贝。生成buildrun后，该dbm的拷贝就会退出。

然而，目前生成buildrun的实现方案中，主dbm每一次接收到buildrun请求时，均需要fork出一个dbm的拷贝，该dbm的拷贝会在生成buildrun后退出(即被删除)，当频繁接收到buildrun请求时，反复的fork和dbm的拷贝的退出会降低buildrun生成的效率。

技术实现要素：

有鉴于此，本发明提供一种生成配置逆向文本化的方法及装置，以解决现有技术中生成配置逆向文本化的方案中反复的fork和dbm的拷贝的退出会降低buildrun生成效率的问题。

根据本发明的第一方面，提供一种生成配置逆向文本化的方法，包括：

当主内存数据库dbm接收到配置逆向文本化buildrun请求时，确定是否存在用于生成buildrun的目标dbm；

若存在，则所述主dbm将所述buildrun请求发送给所述目标dbm，由所述目标dbm根据所述buildrun请求生成buildrun，并刷新所述目标dbm的存活时间；

若不存在，则所述主dbm生成所述目标dbm，设置所述目标dbm的存活时间，并将所述buildrun请求发送给所述目标dbm，由所述目标dbm根据所述buildrun请求生成buildrun。

根据本发明的第二方面，提供一种生成配置逆向文本化的装置，包括：主dbm和目标dbm；其中：

所述主dbm，用于当接收到buildrun请求时，确定是否存在用于生成buildrun的目标dbm；

所述主dbm，还用于若存在，则将所述buildrun请求发送给所述目标dbm，由所述目标dbm根据所述buildrun请求生成buildrun，并刷新所述目标dbm的存活时间；

所述主dbm，还用于若不存在，则生成所述目标dbm，设置所述目标dbm的存活时间，并将所述buildrun请求发送给所述目标dbm，由所述目标dbm根据所述buildrun请求生成buildrun。

应用本发明公开的技术方案，当主dbm接收到buildrun请求时，确定是否存在用于生成buildrun的目标dbm；若存在，则主dbm将buildrun请求发送给目标dbm，由目标dbm根据buildrun请求生成buildrun，并刷新目标dbm的存活时间；若不存在，则主dbm生成目标dbm，设置目标dbm的存活时间，并将buildrun请求发送给目标dbm，由目标dbm根据buildrun请求生成buildrun，利用获取buildrun的需求在时间上的连续时，主dbm生成的用于生成buildrun的目标dbm，并不会完成buildrun生成后就退出，而是存在一个存活时间，避免了目标dbm的频繁生成和退出，提高了buildrun生成的效率。

附图说明

图1是本发明实施例提供的一种生成配置逆向文本化的方法的流程示意图；

图2是本发明实施例提供的一种buildrun输出的示意图；

图3a是本发明实施例提供的一种buildrun的组织结构示意图；

图3b是本发明实施例提供的一种基础buildrun的增量更新架构示意图；

图3c是本发明实施例提供的一种基础buildrun的增量更新逻辑的示意图；

图3d是本发明实施例提供的一种增加虚拟节点后的基础buildrun的结构示意图；

图3e是本发明实施例提供的一种基础buildrun的初始化的示意图；

图3f是本发明实施例提供的一种基础配置对象节点的初始化的流程示意图；

图3g是本发明实施例提供的一种模板实例对象节点的初始化的流程示意图；

图3h是本发明实施例提供的一种增量更新的流程示意图；

图3i是本发明实施例提供的一种bdr数据汇总后的基础buildrun的结构示意图；

图4是本发明实施例提供的一种生成配置逆向文本化的装置的结构示意图；

图5是本发明实施例提供的一种生成配置逆向文本化的装置的硬件结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明实施例中的技术方案，并使本发明实施例的上述目的、特征和优点能够更加明显易懂，下面结合附图对本发明实施例中技术方案作进一步详细的说明。

请参见图1，为本发明实施例提供的一种生成配置逆向文本化的方法的流程示意图，如图1所示，该生成配置逆向文本化的方法可以包括以下步骤：

步骤101、当主dbm接收到buildrun请求时，确定是否存在用于生成buildrun的目标dbm。若是，则转至步骤102；否则，转至步骤103。

本发明实施例中，考虑到获取buildrun的需求存在时间的连续性，即在一个时间段内，可能会比较频繁地存在获取buildrun的需求。

基于buildrun获取的这一特性，fork出的dbm的拷贝(即用于生成buildrun的dbm，本文中称为目标dbm)并不会在生成buildrun之后就退出，而是可以存在一个存活时间，当目标dbm未接收到buildrun请求的持续时间达到该存活时间时，目标dbm才退出；否则，buildrun请求均可以发送给该目标dbm进行处理，以避免目标dbm的频繁fork和退出，提高生成buildrun的效率。

相应地，在本发明实施例中，当主dbm接收到buildrun请求时，主dbm可以确定是否存在目标dbm。

步骤102、主dbm将buildrun请求发送给目标dbm，由dbm根据该buildrun请求生成buildrun，并刷新dbm的存活时间。

本发明实施例中，若主dbm确定存在目标dbm，即目标dbm仍处于存活状态，则主dbm可以可以将该buildrun请求发送给该目标dbm，而不需要重新生成目标dbm(即不需要fork新的目标dbm)。

目标dbm接收到buildrun请求时，一方面，可以基于自身的数据库生成buidlrun，并将生成的buildrun返回给请求方。

示例性的，目标dbm根据自身的数据库生成buildrun的具体实现可以参见现有生成buildrun的实现方案中的相关实现，本发明实施例在此不做赘述。

另一方面，目标dbm可以刷新自身的存活时间。

例如，假设目标dbm的存活时间为15分钟，则当目标dbm接收到buildrun请求时，目标dbm可以将存活时间由当前剩余时间(如5分钟)重新设置为15分钟，即目标dbm至少在接下来的15分钟为存活状态。

步骤103、主dbm生成目标dbm，设置dbm的存活时间，并将buildrun请求发送给该目标dbm，由目标dbm根据该buildrun请求生成buildrun。

本发明实施例中，若主dbm确定不存在目标dbm，则主dbm可以生成目标dbm，即fork一个dbm的拷贝，并设置该目标dbm的存活时间(该存活时间可以根据需求预先配置)。

主dbm生成目标dbm之后，可以将接收到的buildrun请求发送给目标dbm，由目标dbm根据该buildrun请求生成buildrun。

可见，在图1所示方法流程中，通过为生成的目标dbm设置存活时间，以使目标dbm在存活时间内不退出，进而，若在目标dbm存活时接收到buildrun请求，则可以将buildrun请求发送给该目标dbm，而不需要重新生成目标dbm，避免了目标dbm的频繁生成和退出，提高了生成buildrun的效率。

可选地，在本发明其中一个实施例中，上述主dbm生成目标dbm之后，还可以包括：

目标dbm根据自身数据库中的数据构建基础buildrun；其中，该基础buildrun为树形结构；

上述目标dbm根据buildrun请求生成buildrun，可以包括：

目标dbm根据基础buildrun生成buidrun。

在该实施例中，考虑到在目标dbm存活时，主dbm接收到的buildrun请求均会被发送给该目标dbm，由该目标dbm生成buildrun，当某一时间内频繁存在获取buildrun的需求时，该目标dbm会频繁生成buildrun。为了避免目标dbm每一次均按照现有生成buildrun的实现方案中描述的方式进行buildrun生成。主dbm生成目标dbm之后，目标dbm可以根据自身数据库中的数据，构建一个基础buildrun，该基础buildrun中可以包括生成buildrun是需要的数据(可以称为buildrun数据)。后续流程中，当目标dbm需要生成buildrun时，可以基于该基础buildrun生成buildrun。

示例性的，目标dbm生成基础buildrun的方式可以与现有生成buildrun的实现方案中生成buildrun的实现相同。

需要说明的是，当目标dbm生成基础buildrun之后，若目标dbm自身的数据库中的数据未发生变化(即主dbm的数据库中的数据未发生变化)，则基础buildrun中包括的buildrun数据与目标dbm生成的buildrun中包括的buildrun数据相同。

进一步地，考虑到配置改变导致配置信息发生变化时，通常仅会影响buildrun的一小部分，因此，当数据库的数据发生变化时，目标dbm可以基于发生变化的数据，对基础buildrun受影响部分进行更新，进而，基于更新后的基础buildrun生成最新的buildrun。

相应地，目标dbm生成的基础buildrun可以为树形结构，以便数据库中的数据发生变化时，目标dbm可以定位到受影响的节点，并对受影响的结点进行更新，实现增量更新。

可选地，在一个示例中，上述目标dbm根据自身数据库中的数据构建基础buildrun，包括：

目标dbm根据注册的buildrun等级依次调用各回调函数；

当调用模板注册的实例获取回调函数时，生成模板实例对象节点，该模板实例对象节点包括用于标识模板实例对象节点的实例名，以及模板实例对象节点的buildrun数据；

当调用普通命令的回调函数时，生成普通配置对象节点，该普通配置对象节点包括用于标识该普通配置对象节点的回调函数(可以称为bdr回调)、该普通配置对象节点的buildrun数据，以及该普通配置对象节点的buildrun等级。

在该示例中，主dbm生成目标dbm之后，目标dbm可以根据注册的buildrun等级(level)(也可以称为buildrun优先级，下文中简称为优先级)依次调用各回调函数(callback)，即按照优先级从高到低(buildrun等级的数值越大，优先级越低)以及深度优先的方式，依次调用回调函数。

其中，buildrun依赖的数据组织可以包括两大类：模板和普通命令。

在该实施例中，对于模板，目标dbm调用模板注册的实例获取回调函数，获取相关实例，生成模板实例对象节点，该模板实例对象节点可以包括用于标识该模板实例对象节点的实例名，以及该模板实例对象节点的buildrun数据。

对于普通命令，目标dbm调用该普通命令的回调函数，生成普通配置对象节点，该普通配置对象节点可以包括用于标识该普通配置节点的回调函数、普通配置对象节点的buildrun数据，以及普通配置对象节点的buildrun等级。

进一步地，在该示例中，考虑到同一模板实例化得到的不同模板实例的优先级相同，为了方便同一模板实例化得到的不同模板实例之间的排序，可以引入虚拟节点(virtualnode)。

可选地，在一个示例中，上述生成模板实例对象节点，可以包括：

对于模板，创建虚拟节点，并将该模板实例化得到的模板实例对象节点作为该虚拟节点的子节点；

其中，对于同一模板实例化得到的多个模板实例对象节点，采用预设排序函数进行排序。

在该示例中，在构建基础buildrun的过程中，对于任一模板，目标dbm可以创建对应该模板的虚拟节点(该虚拟节点的优先级与该模板的优先级一致)，该模板实例化得到的模板实例对象节点均作为该虚拟节点的子节点，且该模板实例化得到的多个模板实例对象节点之间可以采用预设排序函数进行排序。

可选地，在一个示例中，上述创建虚拟节点，将该模板实例化得到的模板实例对象节点作为该虚拟节点的子节点，可以包括：

创建对应该模板的虚拟节点；

按照buildrun等级循环调用注册在该模板下的子模板初始化函数；

若子模板初始化函数返回了模板实例对象节点，则将该模板实例对象节点加入该虚拟节点的子节点列表；

当注册在该模板下的子模板初始化函数均被调用过时，若该虚拟节点存在子节点，则返回该虚拟节点；

否则，删除该虚拟节点。

可选地，在一个示例中，生成普通配置对象节点，可以包括：

调用该普通命令的回调函数；

当存在该普通命令对应的配置信息输出到指定存储空间时，生成该普通命令对应的普通配置对象节点。

其中，上述生成模板实例对象节点以及生成普通配置对象节点的具体实现可以在下文中结合具体实例进行说明，本发明实施例在此不做赘述。

可选地，在本发明其中一个实施例中，上述目标dbm根据自身数据库中的数据构建基础buildrun之后，还可以包括：

当主dbm的数据库发生数据变化事件时，向目标dbm发送变化通知；

目标dbm根据变化通知确定发生变化的数据，并根据发生变化的数据更新自身的数据库；

以及，根据发生变化的数据确定所述基础buildrun中需要更新的目标节点，并对目标节点进行更新。

在该实施例中，考虑到当配置改变导致配置信息变化(数据库中数据发生变化)时，通常仅会影响buildrun的一小部分，若每次数据库中数据发生变化，均重新生成一次完整的buildrun，会导致buildrun的生成效率较差，因此，为了提高buildrun的生成效率，当数据库中数据发生变化时，可以通过增强更新的方式进行buildrun的更新。

相应地，在该实施例中，当主dbm的数据库发生数据变化事件时，向主dbm发送变化通知。

目标dbm接收到主dbm发送的变化通知时，根据该变化通知确定发生变化的数据，此时，目标dbm一方面可以根据发生变化的数据更新自身的数据库，以保证自身的数据库与主dbm的数据库中的数据一致；一方面，可以根据发生变化的数据确定基础buildrun中需要更新的节点(本文中称为目标节点)，并对目标节点进行更新。

可选地，在一个示例中，上述根据发生变化的数据确定基础buildrun中需要更新的目标节点，并对目标节点进行更新，包括：

根据发生变化的数据确定对应的数据库变化处理回调函数，并调用数据库变化处理回调函数；

若该数据库变化处理回调函数对应的为普通命令，则定位变化的普通配置对象节点；若该普通配置对象节点存在，则调用该普通配置对象节点的回调函数，进行节点删除或修改；若该普通配置对象节点不存在，则调用该普通命令的回调函数，生成对应的普通配置对象节点；

若该数据库变化处理回调函数对应的为模板，则定位变化的模板实例对象节点；若为创建模板实例，则生成新的模板实例对象节点；若为删除模板实例，则删除该模板实例对象节点及其子节点。

在该示例中，为了支持增量更新，需要建立数据库数据、更新函数(也可以称为数据库变化处理回调函数)以及buildrun结果三者间的联系，进而，可以根据数据库中发生变化的数据，确定对应的数据库变化处理回调函数，进而，定位基础buildrun中需要更新的节点(即上述目标节点)，并对目标节点进行更新，其具体实现将在下文中结合具体实例进行说明，本发明实施例在此不做赘述。

为了使本领域技术人员更好地理解本发明实施例提供的技术方案，下面结合具体实例对本发明实施例提供的技术方案进行说明。

以图2所示buildrun输出为例，如图2所示，通过特定的符号(图2中以“#”为例)区分段落，通过缩进表示配置的层次关系。

buildrun内部的组织结构可以如图3a所示，其如图3a所示，模板root(根节点)作为整个buildrun的根节点，下面根据优先级排列着插件注册的回调或者子模板的信息。优先级用来控制buildrun内容的生成顺序，保证对于同样的运行配置buildrun的结果是一样的。

builrun生成的时候，从模板root开始，根据优先级，依次调用回调函数。使用深度优先的方式，调用各个插件注册的回调函数或子模板的信息，各个插件注册的回调函数从系统中(以dbm为例)获取运行数据，根据自身的逻辑生成文本信息输出。

在该实施例中，考虑到buildrun的两个特点：

特点1：获取buildrun的需求存在时间的连续性，即在一个时间段内，会比较频繁的获取buildrun信息。

特点2：每次配置的改变导致配置信息变化(即数据库中的数据发生变化)时，通常只影响buildrun的一小部分内容。

为了利用buildrun的上述两个特点，同时避免对dbm性能的影响，收到buildrun请求后，主dbm可以确定是否存在用于生成buildrun的dbm(即上述目标dbm，该实施例中称为dbm4b)。

若不存在，则主dbm可以fork一个dbm的拷贝，作为dbm4b，设置该dbm4b的存活时间(以15分钟为例)，并将buildrun请求发送给该dbm4b，由dbm4b根据自身数据库生成buildrun。

若存在，则主dbm将buildrun请求发送给dbm4b，由dbm4b根据自身数据库生成buildrun。

在该实施例中，主dbm生成dbm4b后，dbm4b可以根据自身数据库中的数据构建一个基础buildrun，并加入到dbm的实时备份通道；后续对主dbm的数据修改通过实时备份通道，实时备份给dbm4b；dbm4b一方面更新自身数据中的数据，另一方面，对基础buildrun受影响的部分进行快速更新，从而保证基于基础buildrun生成的buildrun与自身数据库中的数据保持一致。

在该实施例中，请参见图3b，为了实现增量更新，可以对dbm4b生成的基础buildrun进行结构化(以树形结构为例)。

当dbm4b的数据库发生数据变化时，可以将数据变化通知给插件；插件解析出发生变化的数据，并通过基础buildrun提供的接口(包括添加/删除/修改接口)，定位dbm4b中需要更新(包括添加/删除/修改)的节点(即上述目标节点)。

在该实施例中，请参见图3c，为了实现增量更新，可以注册数据库变化处理回调函数，并将该数据库(简称为db)变化处理回调函数与回调函数进行关联。当db实例中数据发生变化时，可以将数据变化通知给db变化处理回调函数，由db变化处理回调函数定位需要更新的节点(图3c中以模板实例对象节点为例)，进而，调用对应的回调函数进行增量更新。

其中，db实例和db变化处理回调函数是多对多的关系。一个db变化处理回调函数可以关注多个db实例的数据变化。一个db实例的数据变化可以被多个db变化处理回调函数关注。

db变化处理回调函数和回调函数是一对一的关系。

在该实施例中，基础buildrun的核心数据包括：模板实例对象节点和普通配置对象节点；其中：

模板实例对象节点包括两个核心数据：

1、实例名，用于标识模板实例对象节点；

2、buildrun数据，调用该模板实例的回调输出的数据，用于加速buildrun的输出。

普通配置对象节点包括三个核心数据：

1、回调函数，用来更新buildrun数据，并标识普通配置对象节点；

2、buildrun数据，调用该回调函数输出的数据，用于加速buildrun的输出；

3、buildrunlevel(即优先级)，用于同层节点之间进行排序。

由于同一模板实例化出的模板实例对象的优先级相同，需要插件参与排序，为了方便模板实例对象的排序，可以引入virtualnode，该模板实例化出的模板实例对象节点均作为该virtualnode的子节点，同一virtualnode下的各模板实例对象节点使用插件提供的排序函数排序。virtualnode和其他同层节点(virtualnode或普通配置对象节点)按照优先级排序，其示意图可以如图3d所示。

基于上述树形结构的基础buildrun(也可以称为cfgtree(配置树))，当dbm4b接收到buildrun请求时，通过深度优先遍历对各节点进行遍历，遍历各节点的buildrun数据，并将各节点的buildrun数据以二进制方式输出，避免了字符串拼装，且无需无用的遍历(即不存在buildrun数据的模板实例或普通命令不会生成对应的节点，其具体实现将在下文中进行说明)，提高了buildrun生成的效率。

为了使本领域技术人员更好地理解本发明实施例中描述的树形结构的基础buildrun，下面对基础buildrun的初始化构建过程进行说明。

在该实施例中，主dbm生成dbm4b之后，dbm4b根据注册的buildrunlevel依次调用回调函数。

在构建基础buildrun的过程中，当调用模板注册的实例获取回调函数时，生成模板实例对象节点；当调用普通命令的回调函数时，生成普通配置对象节点。

其中，模板实例化后，递归重复上述流程，其示意图可以如图3e所示。

在该实施例中，对于普通配置对象节点，其初始化逻辑示意图可以如图3f所示，对于普通命令，dbm4b可以调用该普通命令的回调函数，并检测是否存在该普通命令的配置信息输出到指定存储空间。由于配置信息通常以文本信息的形式输出到指定存储空间，因此，可以检测是否有文本信息输出到指定存储空间。

若有文本信息输出到指定存储空间，则生成普通配置对象节点，该普通配置对象节点以该普通命令的回调函数为key，以调用该普通命令的回调函数输出的文本内容为buildrun数据，并以该普通命令的buildrunlevel作为buildrunlevel。

若没有文本信息输出到指定存储空间，则不生成普通配置对象节点，即返回空(null)。

在该实施例中，对于模板实例对象节点，其初始化逻辑示意图可以如图3g所示，对于模板，dbm4b可以创建对应该模板的virtualnode，并按照优先级循环调用注册在该模板下的子模板初始化函数。

若该初始化函数返回了模板实例对象节点，则将该模板实例节点加入到virtualnode的子节点列表中；

若该初始化函数未返回模板实例对象节点，则调用下一个子模板初始化函数。

当全部子模板初始化函数均被调用时，dbm4b可以检测该virtualnode下是否存在子节点。

若存在，则返回该virtualnode；

否则，删除该virtualnode，返回null。

在该实施例中，基于上述树形结构的基础buildrun，可以实现增量更新，即当数据库中数据变化时，针对受该数据变化影响的节点进行更新，而不影响其他节点。

示例性的，基础buildrun中的模板实例对象节点和普通配置对象节点均可以注册db的数据变化事件，如数据添加/删除/修改。

当检测到db的数据变化事件时，可以使用db变化处理回调函数定位到受影响的节点，并通过调用该节点的回调函数进行节点更新。

模板实例更新

对于模板实例，基础buildrun提供如下操作：

1、创建实例(addnewinstance)：

addnewinstance(inchar*pcmode，inchar*pcbdr)。

其中，pcbdr是buildrun数据，pcmode是实际要传给模板下其他buildrun的数据。

基础buildrun通过上下文将数据转化成新生成的实例。

2、删除实例(removeinstance)：

removeinstance(inchar*pcpath)。

在该实施例中，使用路径的方式标记需要删除的数据。

以图2所示buildrun输出为例，若ipvpn-instance模块响应到ipvpn-instance2删除，则至少存在两种方式作为参数调用removeinstance()，通知基础buildrun删除实例。

a)、使用绝对路径“|root|ipvpn-instance2”，即从根节点开始的完整路径；

b)、使用相对路径“.|ipvpn-instance2”，即从当前模板所在位置开始的相对路径。

对于普通命令，基础buildrun提供如下操作：

1、标记变化节点(markupdate)：

markupdate(char*pcpath)。

对于修改/删除/添加数据都可以使用该接口。

插件无需关注所属模板实例化，框架自动调用创建相关对象。

以图2所示buildrun输出为例，若txnpolicy模块检测到db变化事件，则通知框架“|root|ipvpn-instance2|addressfamilyipv4”需要更新，无需显示指明buildrun的回调函数。通过上下文dbm4b可以确定需要更新的是txnpolicy的回调函数，框架负责定位到“txnpolicytx1”并更新。

在该实施例中，基于上述基础buildrun的增量更新逻辑可以如图3h所示，当检测db数据变化事件时，可以通过db变化处理回调函数定位受影响的节点，并调用该节点对应的回调函数。

对于普通命令，定位变化的普通配置对象节点。若该普通配置对象节点存在，则调用该普通配置对象节点的回调函数，进行节点删除或修改；若该普通配置对象节点不存在，则调用该普通命令的回调函数，生成对应的普通配置对象节点。

对于模板，定位变化的模板实例对象节点；若为创建模板实例，则按照上述方式初始化新的模板实例；若为删除模板实例，则删除该模板实例对象节点及其子节点。

在该实施例中，为了进一步提高buildrun生成的效率，对于模板实例，可以提前收集该模板实例的子节点的buildrun数据，并将其添加至该模板实例的buildrun数据中，其示意图可以如图3i所示，进而，在基于基础buildrun生成buildrun时，对于模板实例对象节点，可以直接使用该模板实例对象节点记录的buildrun数据进行输出，而不需要进一步遍历该模板实例对象的子节点。

通过以上描述可以看出，在本发明实施例提供的技术方案中，当主dbm接收到buildrun请求时，确定是否存在用于生成buildrun的目标dbm；若存在，则主dbm将buildrun请求发送给目标dbm，由目标dbm根据buildrun请求生成buildrun，并刷新目标dbm的存活时间；若不存在，则主dbm生成目标dbm，设置目标dbm的存活时间，并将buildrun请求发送给目标dbm，由目标dbm根据buildrun请求生成buildrun，利用获取buildrun的需求在时间上的连续时，主dbm生成的用于生成buildrun的目标dbm，并不会完成buildrun生成后就退出，而是存在一个存活时间，避免了目标dbm的频繁生成和退出，提高了buildrun生成的效率。

请参见图4，为本发明实施例提供一种生成配置逆向文本化的装置的结构示意图，其中，该生成配置逆向文本化的装置可以应用于上述方法实施例，如图4所示，该生成配置逆向文本化的装置可以包括：主dbm410和目标dbm420；其中：

所述主dbm410，用于当接收到buildrun请求时，确定是否存在用于生成buildrun的目标dbm；

所述主dbm410，还用于若存在，则将所述buildrun请求发送给所述目标dbm，由所述目标dbm根据所述buildrun请求生成buildrun，并刷新所述目标dbm的存活时间；

所述主dbm410，还用于若不存在，则生成所述目标dbm，设置所述目标dbm的存活时间，并将所述buildrun请求发送给所述目标dbm，由所述目标dbm根据所述buildrun请求生成buildrun。

在可选实施例中，所述目标dbm420，还用于所述目标dbm根据自身数据库中的数据构建基础buildrun；其中，所述基础buildrun为树形结构；

所述目标dbm420，具体用于根据所述基础buildrun生成buildrun。

在可选实施例中，所述目标dbm420，具体用于根据注册的buildrun等级依次调用各回调函数；当调用模板注册的实例获取回调函数时，生成模板实例对象节点，所述模板实例对象节点包括用于标识所述模板实例对象节点的实例名，以及所述模板实例对象节点的buildrun数据；当调用普通命令的回调函数时，生成普通配置对象节点，所述普通配置对象节点包括用于标识所述普通配置对象节点的回调函数、所述普通配置对象节点的buildrun数据，以及所述普通配置对象节点的buildrun等级。

在可选实施例中，所述目标dbm420，具体用于对于模板，创建虚拟节点，并将所述模板实例化得到的模板实例对象节点作为所述虚拟节点的子节点；

其中，对于同一模板实例化得到的多个模板实例对象节点，采用预设排序函数进行排序。

在可选实施例中，所述目标dbm420，具体用于创建对应该模板的虚拟节点；按照buildrun等级循环调用注册在该模板下的子模板初始化函数；若所述子模板初始化函数返回了模板实例对象节点，则将该模板实例对象节点加入该虚拟节点的子节点列表；当注册在该模板下的子模板初始化函数均被调用过时，若该虚拟节点存在子节点，则返回该虚拟节点；否则，删除该虚拟节点。

在可选实施例中，对于任一模板实例对象节点，该模板实例对象节点的buildrun数据包括该模板实例对象节点的全部子节点的buildrun数据。

在可选实施例中，所述目标dbm420，具体用于调用该普通命令的回调函数；当有存在该普通命令对应的配置信息输出到指定存储空间时，生成该普通命令对应的普通配置对象节点。

在可选实施例中，所述主dbm410，还用于当数据库发生数据变化事件时，向所述目标dbm发送变化通知；

所述目标dbm420，还用于根据所述变化通知确定发生变化的数据，并根据发生变化的数据更新自身的数据库；以及，根据发生变化的数据确定所述基础buildrun中需要更新的目标节点，并对所述目标节点进行更新。

在可选实施例中，所述目标dbm420，具体用于根据发生变化的数据确定对应的数据库变化处理回调函数，并调用所述数据库变化处理回调函数；若为所述数据库变化处理回调函数对应的普通命令，则定位变化的普通配置对象节点；若该普通配置对象节点存在，则调用该普通配置对象节点的回调函数，进行节点删除或修改；若该普通配置对象节点不存在，则调用该普通命令的回调函数，生成对应的普通配置对象节点；若所述数据库变化处理回调函数对应的为模板，则定位变化的模板实例对象节点；若为创建模板实例，则生成新的模板实例对象节点；若为删除模板实例，则删除该模板实例对象节点及其子节点。

请参见图5，为本发明实施例提供的一种生成配置逆向文本化的装置的硬件结构示意图。该生成配置逆向文本化的装置可以包括处理器501、存储有机器可执行指令的机器可读存储介质502。处理器501与机器可读存储介质502可经由系统总线503通信。并且，通过读取并执行机器可读存储介质502中与生成配置逆向文本化的逻辑对应的机器可执行指令，处理器501可执行上文描述的生成配置逆向文本化的方法。

本文中提到的机器可读存储介质502可以是任何电子、磁性、光学或其它物理存储装置，可以包含或存储信息，如可执行指令、数据，等等。例如，机器可读存储介质可以是易失存储器、非易失性存储器或者类似的存储介质。具体地，机器可读存储介质502可以是ram(radomaccessmemory，随机存取存储器)、闪存、存储驱动器(如硬盘驱动器)、固态硬盘、任何类型的存储盘(如光盘、dvd等)，或者类似的存储介质，或者它们的组合。

本发明实施例还提供了一种包括机器可执行指令的机器可读存储介质，例如图5中的机器可读存储介质502，所述机器可执行指令可由生成配置逆向文本化的装置中的处理器501执行以实现以上描述的生成配置逆向文本化的方法。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本发明方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

由上述实施例可见，当主dbm接收到buildrun请求时，确定是否存在用于生成buildrun的目标dbm；若存在，则主dbm将buildrun请求发送给目标dbm，由目标dbm根据buildrun请求生成buildrun，并刷新目标dbm的存活时间；若不存在，则主dbm生成目标dbm，设置目标dbm的存活时间，并将buildrun请求发送给目标dbm，由目标dbm根据buildrun请求生成buildrun，利用获取buildrun的需求在时间上的连续时，主dbm生成的用于生成buildrun的目标dbm，并不会完成buildrun生成后就退出，而是存在一个存活时间，避免了目标dbm的频繁生成和退出，提高了buildrun生成的效率。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求指出。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。