基于关系模型的统一配置与恢复方法及可读存储介质与流程

1.本发明涉及配置管理技术领域，具体为一种基于关系模型的统一配置与恢复方法及可读存储介质。


背景技术：

2.随着sdn(软件定义网络)网络架构的发展，管理面和控制面逐渐由硬件层剥离并转化为软件定义实现，hmi(人机界面或人机接口)的多参数可配置、灵活化配置等需求逐渐明显。基于rest(表述性状态转移)风格的一次性配置将逐步取代传统的、多命令分时分步下发的配置方式，这将导致配置参数的耦合度提高、依赖性增加。
3.现有网络设备的配置保存方法大多通过加载用户下发的命令行，或者调用操作日志的方式进行配置参数的恢复，其配置存在以下问题：
4.1、配置下发方面，配置无法判断参数的依赖，需要交给下级的控制面完成，每个控制面模块需要在代码层面单独维护参数依赖；
5.2、配置恢复方面，当配置参数发生变更时，原有的操作配置记录将失效；
6.3、当系统被其他非用户触发条件更新系统配置时，会导致用户配置状态与系统配置状态不一致。


技术实现要素：

7.本发明的目的之一在于提供一种基于关系模型的统一配置与恢复方法，以解决现有设备配置下发和保存中存在配置参数维护困难、用户配置与系统配置状态不一致的技术问题。
8.本发明提供的基础方案一：基于关系模型的统一配置与恢复方法，包括以下内容：
9.模型生成步骤：获取schema定义，解析生成关系模型；
10.配置下发步骤：根据关系模型对配置参数进行规则校验和依赖性校验，在校验通过后，根据数据库触发器分发配置参数；
11.配置保存步骤：根据分发的配置参数进行配置，在配置成功后，将配置参数临时保存在内存中；当触发保存配置时，将配置参数保存在硬盘中。
12.进一步，模型生成步骤，具体包括以下内容：获取schema定义，分析是否存在不合法的数据定义或不完整的字段定义，并解析数据结构生成独立表单，根据独立表单生成关系模型。
13.进一步，规则校验，具体包括以下内容：对配置参数的类型、大小、正则、枚举进行校验，或调用预设的自定义规则，对配置参数进行规则校验。
14.进一步，表单包括系统配置表，系统配置表包括用户配置表，预设有增、删、改操作对应的分发方法，数据库触发器根据对表单的操作触发不同的分发方法分发配置参数。
15.进一步，当接收到用户下发的保存配置指令时，或者当触发其他自定义保存配置条件时，触发保存配置。
16.进一步，还包括以下内容：配置恢复步骤：进程启动后，对配置参数的数据结构进行版本检查，根据版本检查结果加载生成配置列表，按顺序根据配置列表执行配置下发步骤。
17.进一步，根据版本检查结果加载生成配置列表，具体包括以下内容：当版本不一致时，将原来配置表中的数据扩展成新的数据结构形成新的配置表，新增字段填充默认值，若无默认值，则填充为null。
18.进一步，根据版本检查结果加载生成配置列表，具体包括以下内容：当版本一致时，判断配置表是否为空，若配置表为空，则判断schema是否存在default字段，若存在，则调用default字段作为配置参数加载生成配置列表；若配置表不为空，则查询硬盘，根据配置参数加载生成配置列表。
19.有益效果：
20.采用本方案，在管理面和控制面之间增加统一配置的关系模型，通过该关系模块对配置参数进行范围、类型的约束，以及配置参数之间的依赖约束。同时通过版本检查发现配置表的差异，根据差异进行扩展以生成新的配置表，从而兼容旧配置表，避免原有的操作配置记录失效。采用本方案，开发者只需关注业务处理之间关系，无需考虑模块间配置依赖关系，实现对配置依赖的无感知，提高开发效率。
21.本发明的目的之二在于提供一种基于关系模型的统一配置与恢复方法的可读存储介质。
22.本发明提供基础方案二：基于关系模型的统一配置与恢复方法的可读存储介质，所述可读存储介质存储有计算机指令，所述计算机指令运行时执行上述的基于关系模型的统一配置与恢复方法。
附图说明
23.图1为本发明基于关系模型的统一配置与恢复方法实施例配置下发步骤的示意图；
24.图2为本发明基于关系模型的统一配置与恢复方法实施例配置保存步骤的示意图；
25.图3为本发明基于关系模型的统一配置与恢复方法实施例配置恢复步骤的示意图；
26.图4为本发明基于关系模型的统一配置与恢复方法及可读存储介质实施例的基于http的设备配置下发流程示意图。
具体实施方式
27.下面通过具体实施方式进一步详细说明：
28.实施例
29.基于关系模型的统一配置与恢复方法，其特征在于，包括以下内容：
30.模型生成步骤：获取schema定义，解析生成关系模型。
31.配置下发步骤：根据关系模型对配置参数进行规则校验和依赖性校验，在校验通过后，根据数据库触发器分发配置参数。
32.配置保存步骤：根据分发的配置参数进行配置，在配置成功后，将配置参数临时保存在内存中；当触发保存配置时，将配置参数保存在硬盘中。
33.配置恢复步骤：进程启动后，对配置参数的数据结构进行版本检查，根据版本检查结果加载生成配置列表，按顺序根据配置列表执行配置下发步骤。
34.模型生成步骤，具体包括以下内容：
35.获取schema定义，分析是否存在不合法的数据定义或不完整的字段定义，并解析数据结构生成独立表单，根据独立表单生成关系模型。
36.配置下发步骤，如附图1所示，具体包括以下内容：
37.配置下发主要包括rule_check模块、db_constraint模块和db_trigger模块。
38.通过rule_check模块对配置参数进行规则校验，具体为：对配置参数的类型、大小、正则、枚举进行校验，或调用预设的自定义规则，对配置参数进行规则校验。代码逻辑级别的数据约束，根据schema配置文件的约束，对配置参数的类型、大小、正则、枚举等进行校验，在其他实施例中，设置自定义规则self_define()，根据自定义规则进行限定，使得配置参数的规则校验更贴合实际应用场景。
39.表单包括系统配置表，系统配置表包括用户配置表，通过db_constraint模块对配置参数进行依赖性校验，具体为，对配置表中不同表字段之间依赖进行校验。关系模型的数据约束，根据schema配置文件的约束，对配置表的配置键依赖、唯一性依赖等进校验。
40.在规则校验和依赖性校验均校验通过后，通过数据库触发器(即db_trigger模块)分发配置参数。当任一校验未通过时，返回异常并停止下发。
41.预设有对配置表进行增、删、改操作对应的分发方法，当配置表发生变化时，数据库触发器根据对表单的操作触发不同的分发方法，路由分发配置参数至不同的app。当对配置表进行查询时，不触发分发方法，只根据请求查询对应的系统配置表或用户配置表。
42.配置保存步骤，如附图2所示，具体包括以下内容：
43.配置保存主要包括db_storage模块，db_storage模块包括db mem模块(数据内存)和db disk模块(数据硬盘)。
44.通过db_trigger模块分发配置参数，在配置成功后，通过db_storage模块将配置参数临时保存在db mem模块中，当接收到用户下发的保存配置指令时，或者当触发其他自定义保存配置条件时，触发保存配置，此时将配置参数保存在db disk模块中，实现对配置参数的持久化保存。当配置失败时，返回异常。
45.配置恢复步骤，如附图3所示，具体包括以下内容：
46.配置恢复主要包括ver_check模块、default_config模块和recovery模块。
47.进程启动后，自动进入配置恢复步骤，通过ver_check模块对配置参数进行版本检查，具体的：动态检测用户配置参数的数据结构是否发生变化，发生变化时，即版本不一致，反之，则版本一致。
48.根据版本检查结果加载生成配置列表，具体包括以下内容：
49.当版本不一致时，进行数据迁移，将原来配置表中的数据扩展成新的数据结构形成新的配置表，新增字段填充默认值，若无默认值，则填充为null。
50.当版本一致时，判断配置表是否为空，若配置表为空，则通过default_config模块判断schema是否存在default字段，若存在，则调用default字段的值作为配置参数加载生
成配置列表；若配置表不为空，则查询硬盘，根据配置参数加载生成配置列表。
51.生成配置列表后，执行配置下发步骤，按顺序根据配置列表分发配置参数。
52.本方案各流程之间严格遵循管道过滤器的设计风格，即任何一环的失败将导致下一流程无法执行，每个流程之间全局依赖于关系模型。
53.基于关系模型的统一配置与恢复方法的可读存储介质，所述可读存储介质存储有计算机指令，所述计算机指令运行时执行上述的基于关系模型的统一配置与恢复方法。
54.以一具体实例说明本方案各步骤，如附图4所示，基于http的设备配置下发流程具体实施过程如下：
55.1、进入http分发服务的初始化；
56.2、添加统一配置恢复构件；
57.3、注册应用服务模块模型；
58.4、注册路由信息；
59.5、执行初始化本构件；
60.6、进入监听，等待用户输入；
61.7、接收来自web或者console的hmi输入；
62.8、由本构件判断路由是否合法；
63.9、由本构件执行路由分发处理模块；
64.10、规则校验，当配置条目的合法性校验不通过时，不执行分发；
65.11、依赖校验，当配置条目的依赖性校验不通过时，不执行分发；
66.12、进入路由分发处理；
67.13、当应用服务模块配置成功时，由本构件执行配置保存，否则进入异常处理。
68.采用本方案，基于关系模型，使得用户能感知业务配置的依赖关系，而开发者无感知底层的模块之间的依赖性。与现有技术相比，本方案将复杂的业务配置依赖逻辑与业务处理逻辑分离，无需底层模块实现复杂的配置依赖。
69.同时，本方案基于关系模型进行动态定义配置，并通过比较配置表的差异进行属性扩展，生成新的配置表，使得新的配置表可以兼容旧配置表，从而解决现有技术中在数据结构修改后，无法适配旧配置表，只能删除旧表重新配置的情况。
70.除此之外，本方案将用户配置与系统配置融合，通过db_trigger模块的设置,使用户的“增删改”动作能触发对下级模块的配置，而“查”的动作既分发给库，也可分发给系统。很好地保持系统状态和用户配置状态的一致性。
71.以上所述的仅是本发明的实施例，方案中公知的具体结构及特性等常识在此未作过多描述，所属领域普通技术人员知晓申请日或者优先权日之前发明所属技术领域所有的普通技术知识，能够获知该领域中所有的现有技术，并且具有应用该日期之前常规实验手段的能力，所属领域普通技术人员可以在本技术给出的启示下，结合自身能力完善并实施本方案，一些典型的公知结构或者公知方法不应当成为所属领域普通技术人员实施本技术的障碍。应当指出，对于本领域的技术人员来说，在不脱离本发明结构的前提下，还可以作出若干变形和改进，这些也应该视为本发明的保护范围，这些都不会影响本发明实施的效果和专利的实用性。本技术要求的保护范围应当以其权利要求的内容为准，说明书中的具体实施方式等记载可以用于解释权利要求的内容。